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

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

正文:

前段时间峰哥发我一套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://www.websecuritys.cn/index.php/archives/622/
1 + 1 =
5 评论
    XYFAEChrome 125Windows 10
    5月28日 回复

    牛蛙牛蛙,学到东西了

    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日 回复

    远海太强了,我的偶像