实网攻防-第三方软件风险串联

先看一篇没有什么技术含量的实网渗透文章

正文:

前段时间峰哥发我一套DLL程序集文件，为某个hvv目标的靶标，通过迂回技战法，从同系统站点入手通过弱口令进入后台拿到了webshell，获取到了目标系统的源代码，但目标站点不存在弱口令账户等问题，通过审计发现新漏洞，实现组合利用。
URL: http://www.xxx.com/api/UploadFile/FileUploadImage.api

通过抓包可以看出，该站点的请求路径后缀为.api

在面对常规的.NET系统，可能大多数见到的还是.aspx,.ashx,.asmx这类Web Froms等窗体文件，或者是不带任何后缀的MVC路由形式。

那么针对这类比较特殊的后缀可以看Web.config中的httphandler。

何为Handler？这里白话文说一下就是类似于Java中的Servlet，可以为一些特定路径，或者说符合匹配规则的路由定义单独的处理方法。

列如:  *.WebAPI       - - >  WebApiHandler     

只要任何后缀为WebApI的请求路径都交给WebApiHandler这个类去处理。
回到代码中: 因为有同系统站点的shell，那么我们有很多操作都可以进行验证不用盲打。
在web.config中看到

只要请求路径为.api 或者.app 为结尾。那么这类请求都会交给ApiHandler类去处理。

而ApiHandler继承于IHttpHandler.那么我们可以根据生命周期，先看ProcessRequest方法。

这里的大概逻辑简单理解下，就是获取到context.Request.Url.OriginalString的值，然后进行一些截取判断后缀然后分配给不同的方法去处理。
这里的OriginalString，获取的URL路径包括参数值。先通过检索判断URL路径结尾是否为api,或者.app,设置指定的urlSuffix。
在根据/来对字符进行拆分，已最后一个/后内容为方法名的方式进行调用。

如:/api/File/UploadImage.app => 截取后，File为Api类文件名，UploadImage为类方法。

后段自行拼接为-》XC.SJGL.Api.ApiHandler.FileApi ,并使用Assembly.Load("XC.SJGL.Api").CreateInstance实例化，调用ExecFunc方法。且此类必须继承为BaseApi类。

请求过程中会进行一次身份验证，当会话中的UserId或者UserType为空时，则进入if判断，从数据库中获取配置信息AccessWithoutLoginMethodList的内容，此内容保存的是一些不需要登陆即可访问的路径，由于从同系统站点打入，因此从数据库中可以得到一个公开的APi类文件，BasicAPI。

那么可以审计的内容也就变多了，BasicAPI中提供了大量功能接口，目前所需要的是一个可以获取到用户权限的功能。
通过审计发现一个ResetPassword 方法，为重置用户密码的功能。

跟进方法ResetPassword的具体实现类，password的值是从系统配置文件中获取到的。

从同系统站点的配置获取到的默认密码，进行重置后发现密码不对。那么该值应该不是默认，或者管理员后台进行了更改操作。
而在BasicAPI下面还有一个敏感方法ConfigListAllQueryForWeb ，具体内容为获取系统所有配置信息。

实际请求过后，发现泄漏的信息中包含了重置后的密码

结合之前的重制密码后，也就成功获取到admin管理员的权限。
后台文件上传也就更为直接，从获取到Files对象到SaveAs操作期间并没有任何的类型检测。

最终导致文件上传漏洞，致使拿下目标。

第三方软件安全风险串联

不少看过我文章的人应该比较了解我的攻击手法
找源码->审计->RCE / 同系统->若口令->RCE-审计->未授权RCE

常规思路无非就是利用同站点部署情况去获取目标系统源代码，这种方式需要少部分0day的存储，也会有撞到反代的概率，虽然可以进行指定服务商的筛选,以一些云主机为攻击目标来降低遇到反代的概率,但是再面对一些比较小众的系统时，云主机部署情况较少甚至没有，那么攻击路线就会越拉越长,耗费大量时间做一些没有确定的事情。不如提前做一些信息检索，扩大攻击面

虽说是扩大"攻击面"，其实是扩大"信息检索的深度",建立一个庞大的第三方软件部署信息平台。

以常见OA系统在公网上的部署信息为主要支撑，FOFa为例

某OA系统，这里我们简称为A系统，在公网上独立Ip的部署为3885个。
其次在进行筛选其中的云主机数量，以腾讯云和阿里云为主。

该系统部署在云主机上的独立ip数为813个。
随机挑选一个云主机，查看云主机的应用部署情况

发现其80端口下，还部署着一个ASP.NET应用,属于协同办公平台，也是类似于OA的一款系统(这里以B为代称)，开发商未知，由于部署是在云服务器上，这两个系统应该是属于同一台服务器，也就是说，从OA系统打入服务器，也可以间接获取到ASP.NET应用B的权限以及源代码。

攻破A系统=攻破B系统，因为两系统在同一台服务器上
及 A -> B ,=(相反B也可以到A), B -> A

扩大资产收集面:
我们不妨再将B系统的指纹单独提取出来，继续筛选。

B系统在公网上的云服务器部署只有99条。
随机挑选一个ip，获取其部署信息，发现在其8089端口下部署着一个项目管理云平台(代称为C)

那么我们可以通过B应用的漏洞获取到C应用的源代码,也可以用C应用的漏洞获取到B的源代码（前提是必须拥有B或C的漏洞）,相对来说这类第三方软件的安全性较低，审计起来难度并不高。少量系统可能内部规范了开发标准，漏洞较少。

在实际攻防演练中，往往目标系统是C等小众应用，通过一系列的滚雪球操作，我们可以通过某OA系统的Nday或者0day漏洞不断扩大，最终获取到C的源代码。

A-> B -> C代码审计(挖掘到漏洞）-> C2(同服务器部署B2)
然后迂回
-> B2代码审计(挖掘到漏洞) -> A2(同服务器部署B2)->获取到系统A的源代码

实际过程中可能需要打很多层，但这种方式针对一些比较难的第三方软件有奇效，另禁止在未授权的情况下参考本方案！！！

本文链接：