前言：

这两天朋友圈都被某通的产品被勒索的信息给刷屏了。说句实在话，我应该也算是第一手接触应急场景的，只可惜当时没分析出来到底是怎么被拿下权限的。最后才看到绿盟的博客讲到攻击的流程，才发现原来自己还是太年轻了。正好找朋友要到了存在漏洞的安装包，本地安装之后开始分析。

分析：

根据网上爆出来的poc

看到相关的文件以及参数，根据我的历史经验，aspx文件只是前端显示，业务逻辑处理还是在dll里面。

使用ILSpy查看dll里面的内容，根据路径去进行搜索

直接看到里面处理http请求的函数，ProcessRequest()。

这个函数是调用父类的方法，所以直接查看CommonPage_SetupAccount_Upload类的page_load方法(asp.net网站都是从ProcessRequest方法里面生成page_load方法)

可以看到是直接写入，并没有做目录校验。但是当我进行复现的时候，却发现要登录

这个时候就注意到之前没注意到的参数preload参数，我猜测这个参数就和开关一样，所以代码里面肯定有校验，但是很不巧，搜索出来的东西太多了，没有办法判断。

此时和同事交流发现，之前一直被我忽略的东西，也是每一个asp.net网站做代码审计时都需要注意的文件：Global.asax

文件说明参考：https://www.cnblogs.com/supersnowyao/p/8159251.html

此时看到Application_PreRequestHandlerExecute方法的内容，终于看到了心心念念的preload

如果请求的是静态资源文件或者几个指定的aspx文件，就不需要这个参数也可以直接访问。Burp尝试的截图

至此真相大白，原来通过传递preload=1可以绕过认证校验。

扩散：

知道了如何进行认证，那接下来就好办了很多。先查看几个白名单文件是否存在漏洞，随机挑选了sm/upload/testuploadspeed.aspx进行查看，可以看到同样存在文件上传，但是会立刻进行删除。

本地尝试使用条件竞争进行漏洞复现。(因为可以进行文件删除，所以我们戏称至少拒绝服务有了J)

再接着查看web.config文件，发现了还存在api

同样跟进查看代码Ufida.T.EAP.Rest.RestHandlerFactory,Ufida.T.EAP.Rest可以发现根据不同的url进入不同的分支

先随手输入到burp中进行查看，返回报错

接着分析具体怎么调用

先解析，再调用

需要Method参数，接着查看发现是从services.xml中读取可以调用的类和方法

发现了一个可以执行自定义SQL的方法

去查看实现

此处遇到一个坑，一直以为代码不全，但是实际上是我没找全(脑子糊涂了)。后来在appserver目录下找到了dll文件，以ExecuteCustonSql为例

可以发现直接带入到数据库中进行执行，所以自己拼接了一下http请求包

POST /tplus/api/xxx?dl&Method=Ufida.T.EAP.Interface.IDataService.xxxx&cmd=select%20*%20from%20UFTSystem.dbo.EAP_Account%20waitfor%20delay%20'0:0:5' HTTP/1.1
Host: 10.211.55.6
Connection: close

但是挺神奇的是。。没执行。。

写在最后：

默认sql server账号：TPlusDBAdmin

默认sql server密码：tplus_12345

鸡肋福利一：

鸡肋福利二：

FOFA dork：icon_hash="-2067519629”

本文作者：白帽100安全攻防实验室

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/186800.html