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