云上攻防｜打穿某地区智慧停车小程序

云上攻防｜打穿某地区智慧停车小程序 

背景

某次攻防演习，指挥部分配xx地区智慧停车系统小程序为我方靶标。

那基本可以确定，需要拿下的权限可能有以下几个：

1、小程序的secretkey

2、智慧停车系统数据库权限

3、智慧停车系统web后台

0x01 信息收集

1、查看小程序注册信息、微信小程序抓包，获取当前小程序绑定域名parking.com（文章中使用的域名为虚假域名）。

2、针对获取到的域名parking.com进行子域名收集，发现部分子域名ziyu.parking.com、test.parking.com，并且解析的IP地址处在同一C段（假设为33.33.33.1/24），且IP归属地为xx地区，因此判断存在本地数据中心机房。

3、针对获取到的IP信息，对同一C段IP进行资产测绘，发现多个C段内IP存在web标题类似“xx停车”、“任务调度”的字样，因此判断C段内部分IP也属于靶标“智慧停车小程序”的资产。

结合信息收集的内容，目前已经对靶标小程序有了基本判断：机房部署在本地、拥有多个本地相邻IP地址。

0x02 打偏目标，百思不得其解

nacos

首先针对parking.com及其对应IP的C段进行渗透，成功在C段内找到一个nacos系统，使用公开poc给nacos添加用户，成功登录进入nacos后台。

这个nacos里存放了很多yaml格式的配置文件，逐一查看后，发现有阿里云的ak、华为云的ak、还有部分内网资产服务密码。

这里重点关注云服务厂商的ak、sk。

oss: endpoint: oss-cn-hangzhou.aliyuncs.com access-key-id: LTAxxxxxxxx access-key-secret: fJxxxxxxxxxxxxxxxxxxxxxxx bucket-name: xxxxxxxxxxx pickey: xxxxxxxx/ base-url: http://xxxxxxxxxx.oss-cn-hangzhou.aliyuncs.com/   endpoint: http://oss-cn-hangzhou.aliyuncs.com accesskey: LTxxxxxxxxx secret: g7xxxxxxxxxxxxxxxxxxxxxxxx bucket: xxxx prefix: dev/ss

阿里云AK泄露

首先尝试连接oss存储桶，使用阿里云官方的oss浏览器连接成功。

可以看到多个过车截图，时间也是最新的，可以确定这就是当前智慧停车小程序用于存放过车图片的OSS存储桶。

再尝试用ak做更多的操作，使用cf工具，发现当前ak只有存储桶oss的权限。

CF工具github（目前已经不对外公开）：https://github.com/Phuong39/cf

好在又重新翻了一遍nacos里的配置文件，发现了另一个阿里云ak，这个ak具有全部的权限。

此时经常打阿里云的服务器的rt们肯定已经发现问题了，目前阿里云控制台已经具备了ak泄露异常利用的告警功能，使用老版本cf是会触发告警的。

这里推荐一个新的工具：云资产管理工具.exe

https://github.com/dark-kingA/cloudTools

这个工具具备告警处理功能，这里可以看到刚刚我用cf工具遍历ak权限产生的告警。

所以在遇到阿里云ak泄露时，建议先用这个工具将此类告警“云产品威胁检测”加入白名单，设置成“仅站内通知”，即可避免刚拿到ak就掉权限的情况。

后续成功接管阿里云控制台，发现parking.com域名注册在阿里云上，相当于我们已经接管了域名的解析权限。

再看阿里云控制台当前控制的云服务器，这个阿里云账号下面有4台云服务器，其中一台的ip地址正是parking.com域名解析的IP地址。

通过ak命令执行逐一登录云服务器，查找服务器内存放的配置文件，想要找到数据库的连接凭据，不过最终没有找到。

find / -name "*properties" find / -name "*.yaml"k

口令复用

想到之前nacos中收集到了一些内网服务、资产的密码，将收集到的密码整理成密码本，针对33.33.33.1/24这个IP C段展开密码口令复用测试。结果成功发现该C段多个mysql、ssh服务使用密码本中的密码。

众多mysql中找到了一个数据库，很明显是靶标停车系统的后台数据库，但是仔细查看后发现，数据库里面的数据时效性不足，都是半年前的数据，因此判断这是个老的数据库，目前已经不记录新数据，一定还有一个新使用的数据库。

在多个ssh中继续尝试寻找配置文件，同样没有找到期望的配置文件，但是在一个ssh服务器中的web目录找到了一个jar包

用jadx将jar包反编译后，发现了硬编码的密钥，测试后发现该密钥是当前服务器web服务的后台密码。

成功登录web后台后发现为开发公司的流程审批系统，也不是我们想要找的智慧停车靶标后台系统。

小程序渗透

C段旁站渗透无果后，开始针对小程序展开渗透，挂上代理对小程序进行抓包，顺利在二级路径下找到了spring actuator接口泄露。路径类似：http://www.parking.com/wx-app/actuator/heapdump

成功从heapdump数据中提取出redis密码、微信appId和appSecret

>> spring.rabbitmq.host -> 192.168.1.x >> spring.rabbitmq.username -> admin >> spring.rabbitmq.password -> xxxxxxxx  >> spring.redis.host -> 192.168.1.x >> spring.redis.password -> parkxxxxxxx  >> applet.wechat-appSecret -> 9a0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >> applet.wechat-appId -> wxf1xxxxxxxxxxxxx

使用工具API-Explorer，通过微信的appId和appSecret获取AccessToken，再利用Accesstoken调用接口，获取到小程序绑定的域名列表。

此时发现小程序绑定的域名，除了已知的parking.com，还有一个tingche.com,于是此时转战开始渗透tingche.com域名相关资产。

将新收集到的域名tingche.com放在资产测绘平台下查看，发现多个网页标题含有“智慧停车”、“停车场”关键字的站点。

通过历史收集到的一些密码信息（heapdump、nacos泄露等等），整理成密码本，对tingche.com域名下的资产进行爆破，成功拿下几个ssh、redis、mysql权限，不过仍然没有突破性进展。

0x03 深入复盘，打穿靶标

此时已经拿下了oss存储桶权限、阿里云控制台权限、华为云控制台权限、部分web后台权限、部分ssh/redis/mysql权限，几乎都打穿了，怎么还没有摸到智慧停车的新数据库？？！！

为了找到连接数据库的配置文件，翻了oss里面的文件、阿里云接管服务器里面的配置文件、多个ssh里面的配置文件。。。都没有找到！

终于，渗透过程中的反编译jar包操作提醒了我，这个开发公司喜欢用jar包启动web服务，数据库连接凭据很可能不是单独存放在服务器内的一个配置文件，而是硬编码在jar包中。那么我苦苦寻找配置文件未果的思路行不通也有了解释。

最终在阿里云控制的一台云服务器中，发现了大量类似智慧停车相关的jar包，将jar包下载到本地后，逐个反编译审计，找到了我想要的新数据库连接凭据，新数据库的表结构和先前老数据库是一样的，同时也有当天的数据。

至此，靶标系统的小程序权限、数据库权限均被拿下。

0x04 总结

本次拿下靶标的过程，有几个值得分享的总结经验：

1、nacos、spring的heapdump文件都是泄露云厂商ak的高发区，值得重点关注。

2、部分有渗透价值的接口藏在二级目录下，例如本次的http://www.parking.com/wx-app/actuator/heapdump，需要在渗透时更加细致认真。

3、拿到小程序ak、sk后，调用官方接口查询绑定域名，从而发现新资产，是一个比较新颖的思路。

4、通过工具调用阿里云ak会触发控制台告警，需要先用工具将告警规则修改。

5、后渗透不仅要关注配置文件，还要关注jar包。如果判断web服务是通过jar包开启的，那jar包反编译会让你有所收获。

文章来源：HACK之道