实战 | 记一次通过供应链拿到目标后台权限的过程

漫长的探索

当点击这些功能并抓包的时候，令我看到奇怪的是所有的请求都指向了a.test.com这个域名，如下图，原谅我的厚码...

test.com这个域名经过查找后发现是一家提供医疗信息系统的本地公司,但不解的是为什么医院的系统会放到供应商公司去呢？他们是如何进行数据同步的呢？带着这些问题我开始了对a.test.com这个域名的测试。

看到这个熟悉的页面，确定了此系统大概是由sping boot开发的，经过一系列常规操作后，只发现了一个swagger-ui页面。

由于我们的目标是拿权限，所以重点对此页面的接口进行了sql注入和越权等测试，无果，也没有任何的文件上传接口,开始卡到这里了。

访问test.com,打开的是供应商公司的官网。

对test.com的域名做信息收集后发现了几个子域均解析致某云服务器，但是ip不同。

首先git.test.com这个域名引起了我的注意，打开后是一个gitlab服务。

gitlab历史上是由几个漏洞的：

但不幸的是此系统版本较高，漏洞均以修复。

果不然，群文件中有一份表格，记录了员工的详细信息

柳岸花明又一村

我开始把希望寄托在了这些可公开访问的仓库上，仔细翻看这些仓库，大多数都是一些接口文档，对本次渗透没有啥用。

在前面的信息收集过程中，已经发现了x.test.com这个子域名对应的ip地址开放了oracle数据库端口，我迅速连接了此数据库发现用户名密码正确，可以连接。

然后就是添加用户登录拿下了这台oracle数据库的服务器。

在mysql数据库中成功获取了供应商官网test.com后台的用户名和密码。

当我满怀欣喜的去登录时，发现确实可以登录，但登陆后的后台功能都已废弃，只有一个大大的thinkphp错误。

怎么办，原想的通过后台getshell的想法也落空了。（也尝试过使用Thinkphp3的漏洞利用，但也全部失败了）

绝处逢生

使用这两个表名构造了以下绝对路径

c:\hs_webc:\hswebd:\hs_webd:\hsweb

当尝试到c:\hs_web时，webshell提示已经写入成功了。


使用蚁剑连接成功：


由于当前用户权限较小，使用potato成功提权：


添加用户成功登录远程桌面：


在服务端的nginx配置文件中发现了代理规则，涉及到几十家医院：


原来这些医院的微信公众号业务都是先访问test.com这台服务器，然后再由这台服务器上的nginx转到到各个医院的真实服务器上。那这样也太不安全了吧，一旦供应商的这台服务器宕机、他们的业务也得跟着丢。
然后在这台服务器上发现了微信公众号后台源码，丢给同伴审计了一波，发现了后台登录绕过漏洞，可以直接登录后台。


然后就是随意改信息啦。
至此本次渗透就结束了，其实拿到医院的真实ip后也可以更深入的进行测试。


推荐阅读
干货 ｜GitHUB安全搬运工 九

实战｜应急响应之某公司的粗心导致网站被恶意篡改

实战 | 记一次攻防演练

实战 | 记一次诡异的网站篡改应急响应

点赞 在看 转发



原文始发于微信公众号（HACK学习呀）：实战 | 记一次通过供应链拿到目标后台权限的过程