文档 下载安装 问答 主机

从零渗透自动售货机云端

概要

此本文本将被隐藏

前言

之前发了关于自动售货机越权命令执行的文章,非常受大家欢迎。两篇阅读量都直逼十万。
但是两篇文章都是有前提,就是需要拥有一个账号。所以有了这第三篇,从零渗透自动售货机云端。
前两篇文章写得很简单,实际过程中还是遇到了很多问题,把那些曲折的故事都折叠了,所以最后的文章比较短,大家觉得看得很不过瘾。所以我这次对渗透售货机云端做一个详细的记录。
实际在写完两片文章之前,我已经从零入侵过自动售货机云端了。但是和运营商报告漏洞的时候,说漏嘴了,被缝补了那个漏洞。所以我又只有重新渗透,重新寻找。毕竟答应了大家的就一定要做到。

信息收集

首先通过域名得知,自动售货机的名字和主域名A.com
然后通过搜索名字,得到该自动售货机的小程序,然后分析小程序得到第二个域名B.com


首先尝试了正面渗透,但是生产服务器也统一只开了443和80端口,并对其进行了常规渗透,未找到突破口,

寻找可利用点

正面突破毫无办法之后,我把所有收集到的IP进行整理。统一丢到了fofa进行逐个查看。
其中发现test.A.com域名估计存在利用价值。


估计存在利用价值是因为该服务器暴露的服务比较多,切存在子域名test。所以把目标锁定到这台机器。(实际上第一次拿到服务器权限就是通过该机器,但是漏洞后面被开发封堵了)
通过fofa结果,过滤无法利用的端口,开始对逐个http端口进行分析。

Jenkins

Jenkins 的前身是 Hudson 是一个可扩展的持续集成引擎。Jenkins 是一款开源 CI&CD 软件,用于自动化各种任务,包括构建、测试和部署软件。Jenkins 支持各种运行方式,可通过系统包、Docker 或者通过一个独立的 Java 程序。

由于有明显的title,遂即对该服务进行测试。拜读了Jenkins RCE漏洞分析汇总之后进行测试,发现使用的是高版本的Jenkins,所有已知的漏洞无法利用。遂即进行下一个测试。

ActiveMQ

ActiveMQ 是Apache出品,最流行的,能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,尽管JMS规范出台已经是很久的事情了,但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。

发现了该服务,遂即搜索相关漏洞。然后通过弱口令进入了ActiveMQ页面。


因为提示有版本,对比版本后发现5.15.2对已知漏洞免疫,遂即查找其他利用价值。
经过仔细查找发现了一台新的服务器:

估计这就是新的利用点了。
然后把该IP丢到fofa找到:

然后继续每个端口进行查找,但是依旧一无所获。。不甘心啊。肯定有漏洞存在的,我给自己催眠着说。
然后把IP丢到了masscan进行扫描,发现新的开放端口,并使用nmap进行端口服务识别。果然出来了几个新的端口,看来不能完全相信fofa啊。
image
逐个对新端口进行测试,通过扫描发现新的服务:druid

druid

Druid是一个阿里巴巴出品的JDBC组件。

通过浏览器直接进入druid页面(druid未授权访问漏洞):


逛了一圈,发现有价值的只有rds服务名和一些sql语句和数据库名,字段,其他毫无价值。
url和session页面都为空,看来这两项这个druid并不管理。如果存在session的话,说不定可以伪造登陆。
又犯难了,毫无切入点啊。。。:( 答应大家的一定要做到啊,又强忍着,继续推倒重新渗透。

既然强攻不行,我就暴力破解吧。因为还有几个ssh,mysql,mongodb端口。暴力了一番,然后人工利用已经掌握到的信息进行了一番猜解,依然毫无办法。

既然fofa不靠谱,我就从第一台服务器开始重新使用masscan+nmap进行扫描。
然后发现了三个新端口。。。又燃起了我内心的希望。。
新端口逐个分析。其中又有一个是druid未授权漏洞,但是依然没有办法利用。
然后继续拿出我的大杀器dirsearch,发现一枚actuator未授权访问漏洞。

actuator

Actuator它是springboot提供对应用自身监控,以及对应用系统配置查看等功能。
实际上之前也发现了其他的actuator服务,但是都是未授权。


发现的这一枚居然可以访问env配置文件。

其中发现了一个访问密钥micro.service.access.secrets
然后把这个密钥拿着又论坛测试了一遍暴露的ssh,mysql,mongodb.redis等服务
结果并不意外,全部以失败告终。
然后我测试起了actuator本身的漏洞,经过搜索对已知的几个漏洞进行了测试,例如 Jolokia端点利用,xxe等漏洞进行了测试也都不存在利用点。
这个时候已经过去一天半了,我有点想放弃了。但是答应了读者的啊,必须做到!!!!!
然后对整个信息收集做了一个总结,重新分析重新寻找薄弱点。

信息收集总结

通过自己的收寻和查找,基本可以确定,该售后机云端为纯Java构建的微服务,技术栈为:

  • Linux 未知发行版,核心为3.10
  • SpringCloud 作为微服务框架
  • JKD java运行时,版本为1.8
  • jetty web容器
  • mysql 作为数据库,已知数据库版本为5.6,且已知用户名
  • Jenkins CI持续集成
  • actuator 应用监控
  • Druid 数据库监控
  • ActiveMQ 消息列队
  • mqtt iot服务发现
  • redis 缓存服务
  • mongodb 目前未知作用
  • NACOS 服务配置服务

发现可利用点

就在整理已知信息的时候突然发现好之前忽略的一个端口的actuator配置:
image
这是什么???这是曙光啊!!!
遂即进行测试:
image
当当当当!!!!!!!
已经拿到redis权限。密码这么复杂,怪不得之前爆破未成功。

上报售货机运营商

既然已经拿到redis权限,接下来就可以常规redis getshell了。但是由于是友情渗透测试。
所以并未继续。。。直接上报。

修复建议

做好测试环境防御,不要随便对外暴露服务和端口。不要在配置文件中使用硬编密码。
不要对测试环境绑定域名,可以本机绑定hosts的方式。必须要暴露等情况下,使用IP白名单的方式。
做好权限工作,保证java,mysql,redis,mongodb等中间件不要运行在root权限下。

总结

渗透过程中一定要做好信息收集工作,不能盲目相信fofa之类的api。话说买了fofa api很后悔,哪里可以退钱??
渗透过程中一定要不断联系各个信息点,不断总结梳理,发现可利用价值信息。不断测试,推测。

BTW

此次渗透测试记录是在厂商修复完毕后才发表的。至此,云端基本渗透测试完毕,我也不想再继续了。
之后如果还有IOT相关的,我希望是固件和硬件相关的,以前也没接触过这方面,也想挑战一下自己。
如果有IOT厂商愿意提供固件和硬件,可以私信我。