0x00 前言
某次在公司项目渗透时，客户临时要求从去年的hw靶标中选一个作为现场演示攻击手法，我的天，去年的，人早都修了只能自己慢慢再去挖一下了。
0x01 黑盒测试
开局典型登陆框
Net的站点，收集一下同类型站点跑个备份
哈哈哈哈，啥也没有习惯了，只能慢慢的黑盒测了
通过翻阅Js发现存在密码找回接口，第二个接口让我感到非常疑惑重置密码数据包中只有一个xmm(新密码)，难道是有隐藏参数
通过构造相应的请求数据包，爆破存在的账户
最终发现了存在账户1，当时在这里卡了很久一直在试问题密保，半天搞不出来，后来索性直接去构造密码重置包
en，直接返回Ok，这难道是密码重置漏洞，猜测在后台程序处理查询到了用户名，然后将session写入到了当前的会话中，导致了任意密码重置的发生，也就是说先去第一个数据包查询账户，在去第二个数据包重置密码即可
成功登陆系统
</p>
翻了一下系统功能点，发现了一个好东西，这不会是源码吧，但是没有提供下载功能点，只能双击预览
在预览的过程中发现如下数据包，返回了文件路径，但是拼接访问显示404
应该还有个目录前缀继续看看文件中的其他文件发现
拼接过后直接下载了该压缩包
解压一看，好家伙还真是源码
0x02 转向灰盒测试
用dnspy直接反编译查看源码，先来到我们的入口，密码重置处查看一下相应的代码逻辑，果然和我们想的一样，这里先通过string ucode = base. Request. Form["yhm"]; 获取用户输入yhm，并传递给ucode，然后通过 DataTable peo = this. user. GetPeo(ucode) ; 来查询该用户名是否存在。之后进入if语句中，如果用户名不存在则直接返回不存在该用户名，存在则通过base. Session["yhm"] = peo. Rows[O]["UID"]. ToString() ; 设置会话session，而问题也恰恰出现在这里，这里并没有判断用户名和密保问题是否相匹配直接设置了session导致了任意账户密码重置漏洞的发生
</p>
跟进密码重置模块查看，获取用户输入 xmm，之后通过`this.user.UpPwd(xmm, base.Session["yhm"].ToString(), "1") 更新了账户密码，只要session存在即可触发该漏洞，而session只需要通过上面的找回密码第一个步骤即可获取
什么，你说还要爆破账户太麻烦了怎么办，没关系贴心的系统给你准备好了默认账户这套系统实在是太棒了，和我女朋友一样贴心温柔。
0x03 深入挖掘
0x31 任意文件上传
全局搜索Upload，在几处白名单后，终于让我看见一处没有做过滤的
向上追溯一下text = text. Insert(text.LastIndexOf('.'), "_" + text2); 给定的字符串 text 中，在最后一个句点（.）之前插入另一个字符串 text2 和下划线（_）并赋值给text，也就说后缀没有发生改变，继续向上跟踪text，全程后缀都可控，妥妥的文件上传
0x32 任意文件删除+SQL
简单粗暴的任意文件删除漏洞和SQL注入漏洞
删除一下测试文件
在测试测试SQL
发现存在着特殊字符过滤器CuustomFilter，过滤了如下[~<>$%\~\+\&\\\?\:\{(';=]
过滤了'不知道如何绕过，只能在找个没有经过该过滤器的请求,最终找到如下控制器
其中PjfcListByPages 获取四个参数，并直接在pageModel. strCondition = string.Concat(new string] {" FTimePC=", pe, " and BPjUID='", BPjUID, "" 拼接，导致注入发生
0x04 总结
至此通过任意账户密码重置—》缺省账户—》文件上传—》前台SQL—》前台任意文件删除—〉拿下这套系统还是很轻松的，如有问题欢迎各位师傅指正。.
文章来源：先知社区（AGONI）原文地址：https://xz.aliyun.com/t/12666