概要
此本文本将被隐藏
前言
之前发了关于自动售货机越权和命令执行的文章，非常受大家欢迎。两篇阅读量都直逼十万。
但是两篇文章都是有前提，就是需要拥有一个账号。所以有了这第三篇，从零渗透自动售货机云端。
前两篇文章写得很简单，实际过程中还是遇到了很多问题，把那些曲折的故事都折叠了，所以最后的文章比较短，大家觉得看得很不过瘾。所以我这次对渗透售货机云端做一个详细的记录。
实际在写完两片文章之前，我已经从零入侵过自动售货机云端了。但是和运营商报告漏洞的时候，说漏嘴了，被缝补了那个漏洞。所以我又只有重新渗透，重新寻找。毕竟答应了大家的就一定要做到。
信息收集
首先通过域名得知，自动售货机的名字和主域名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啊。
逐个对新端口进行测试，通过扫描发现新的服务：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配置：
这是什么？？？这是曙光啊！！！
遂即进行测试：
当当当当！！！！！！！
已经拿到redis权限。密码这么复杂，怪不得之前爆破未成功。
上报售货机运营商
既然已经拿到redis权限，接下来就可以常规redis getshell了。但是由于是友情渗透测试。
所以并未继续。。。直接上报。
修复建议
做好测试环境防御，不要随便对外暴露服务和端口。不要在配置文件中使用硬编密码。
不要对测试环境绑定域名，可以本机绑定hosts的方式。必须要暴露等情况下，使用IP白名单的方式。
做好权限工作，保证java，mysql，redis，mongodb等中间件不要运行在root权限下。
总结
渗透过程中一定要做好信息收集工作，不能盲目相信fofa之类的api。话说买了fofa api很后悔，哪里可以退钱？？
渗透过程中一定要不断联系各个信息点，不断总结梳理，发现可利用价值信息。不断测试，推测。
BTW
此次渗透测试记录是在厂商修复完毕后才发表的。至此，云端基本渗透测试完毕，我也不想再继续了。
之后如果还有IOT相关的，我希望是固件和硬件相关的，以前也没接触过这方面，也想挑战一下自己。
如果有IOT厂商愿意提供固件和硬件，可以私信我。