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