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

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

正文:

前段时间峰哥发我一套DLL程序集文件,为某个hvv目标的靶标,通过迂回技战法,从同系统站点入手通过弱口令进入后台拿到了webshell,获取到了目标系统的源代码,但目标站点不存在弱口令账户等问题,通过审计发现新漏洞,实现组合利用。
URL: http://www.xxx.com/api/UploadFile/FileUploadImage.api
2022-11-09T12:53:45.png
通过抓包可以看出,该站点的请求路径后缀为.api


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

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

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

列如:  *.WebAPI       - - >  WebApiHandler     

只要任何后缀为WebApI的请求路径都交给WebApiHandler这个类去处理。
回到代码中: 因为有同系统站点的shell,那么我们有很多操作都可以进行验证不用盲打。
在web.config中看到
2022-11-09T12:53:50.png
只要请求路径为.api 或者.app 为结尾。那么这类请求都会交给ApiHandler类去处理。
2022-11-09T12:53:54.png
而ApiHandler继承于IHttpHandler.那么我们可以根据生命周期,先看ProcessRequest方法。
2022-11-09T12:53:58.png
这里的大概逻辑简单理解下,就是获取到context.Request.Url.OriginalString的值,然后进行一些截取判断后缀然后分配给不同的方法去处理。
这里的OriginalString,获取的URL路径包括参数值。先通过检索判断URL路径结尾是否为api,或者.app,设置指定的urlSuffix。
在根据/来对字符进行拆分,已最后一个/后内容为方法名的方式进行调用。
2022-11-09T12:54:05.png

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

后段自行拼接为-》XC.SJGL.Api.ApiHandler.FileApi ,并使用Assembly.Load("XC.SJGL.Api").CreateInstance实例化,调用ExecFunc方法。且此类必须继承为BaseApi类。
2022-11-09T12:54:08.png
请求过程中会进行一次身份验证,当会话中的UserId或者UserType为空时,则进入if判断,从数据库中获取配置信息AccessWithoutLoginMethodList的内容,此内容保存的是一些不需要登陆即可访问的路径,由于从同系统站点打入,因此从数据库中可以得到一个公开的APi类文件,BasicAPI

那么可以审计的内容也就变多了,BasicAPI中提供了大量功能接口,目前所需要的是一个可以获取到用户权限的功能。
通过审计发现一个ResetPassword 方法,为重置用户密码的功能。
2022-11-09T12:54:13.png
跟进方法ResetPassword的具体实现类,password的值是从系统配置文件中获取到的。
2022-11-09T12:54:17.png
从同系统站点的配置获取到的默认密码,进行重置后发现密码不对。那么该值应该不是默认,或者管理员后台进行了更改操作。
而在BasicAPI下面还有一个敏感方法ConfigListAllQueryForWeb ,具体内容为获取系统所有配置信息。
2022-11-09T12:54:20.png

实际请求过后,发现泄漏的信息中包含了重置后的密码
2022-11-09T12:54:24.png
结合之前的重制密码后,也就成功获取到admin管理员的权限。
后台文件上传也就更为直接,从获取到Files对象到SaveAs操作期间并没有任何的类型检测。
2022-11-09T12:54:28.png

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


第三方软件安全风险串联

不少看过我文章的人应该比较了解我的攻击手法
找源码->审计->RCE / 同系统->若口令->RCE-审计->未授权RCE
2022-11-09T15:43:28.png
常规思路无非就是利用同站点部署情况去获取目标系统源代码,这种方式需要少部分0day的存储,也会有撞到反代的概率,虽然可以进行指定服务商的筛选,以一些云主机为攻击目标来降低遇到反代的概率,但是再面对一些比较小众的系统时,云主机部署情况较少甚至没有,那么攻击路线就会越拉越长,耗费大量时间做一些没有确定的事情。不如提前做一些信息检索,扩大攻击面

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

以常见OA系统在公网上的部署信息为主要支撑,FOFa为例
2022-11-09T15:44:44.png

某OA系统,这里我们简称为A系统,在公网上独立Ip的部署为3885个。
其次在进行筛选其中的云主机数量,以腾讯云阿里云为主。
2022-11-09T15:44:51.png
该系统部署在云主机上的独立ip数为813个。
随机挑选一个云主机,查看云主机的应用部署情况
2022-11-09T15:44:58.png
发现其80端口下,还部署着一个ASP.NET应用,属于协同办公平台,也是类似于OA的一款系统(这里以B为代称),开发商未知,由于部署是在云服务器上,这两个系统应该是属于同一台服务器,也就是说,从OA系统打入服务器,也可以间接获取到ASP.NET应用B的权限以及源代码。

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

扩大资产收集面:
我们不妨再将B系统的指纹单独提取出来,继续筛选。
2022-11-09T15:45:19.png
B系统在公网上的云服务器部署只有99条。
随机挑选一个ip,获取其部署信息,发现在其8089端口下部署着一个项目管理云平台(代称为C)
2022-11-09T15:45:27.png
那么我们可以通过B应用的漏洞获取到C应用的源代码,也可以用C应用的漏洞获取到B的源代码(前提是必须拥有B或C的漏洞),相对来说这类第三方软件的安全性较低,审计起来难度并不高。少量系统可能内部规范了开发标准,漏洞较少。

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

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

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

本文链接:

https://websecuritys.cn/index.php/archives/622/
1 + 4 =
4 评论
    n1koChrome 107Windows 10
    2022年12月09日 回复

    tql

    路从今夜白Firefox Browser 107Windows 10
    2022年11月24日 回复

    师傅太强了,爱了

    ace.Chrome 107Windows 10
    2022年11月22日 回复

    好文章,感谢师傅分享!

    昨日像那东流水Chrome 102Windows 10
    2022年11月18日 回复

    远海太强了,我的偶像