畅捷通T+ 漏洞分析

导读：https://www.ihonker.com/thread-31844-1-1.html

前言：

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

分析：

根据网上爆出来的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.1Host: 10.211.55.6Connection: close



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

写在最后：

默认sql server账号：TPlusDBAdmin

默认sql server密码：tplus_12345

鸡肋福利一：







鸡肋福利二：







FOFA dork：icon_hash="-2067519629”

紫月霄狼

感谢楼主分享，最近一个财务信息化的客户，确实有反馈T+被勒索中毒了，据说花的成本还不低，现在的网络信息安全，真是不容忽视。