转载

自动售货机云端攻防

提示:本次为授权友情测试,在厂商确认修复完毕同意后才发表。

之前发了关于自动售货机越权和命令执行的文章,非常受大家欢迎。但是两篇文章都是有前提,就是需要拥有一个账号。所以有了这第三篇,从零渗透自动售货机云端。

前言

前两篇文章写得很简单,实际过程中还是遇到了很多问题,把那些曲折的故事都折叠了,所以最后的文章比较短,大家觉得看得很不过瘾。所以我这次对渗透售货机云端做一个详细的记录。

实际在写完两篇文章之前,我已经从零入侵过自动售货机云端了,打算再复现写文给大家看的。但是和运营商报告漏洞的时候,说漏嘴了,被缝补了那个漏洞。所以我又只有重新渗透,重新寻找。毕竟答应了大家的就一定要做到。

信息收集

首先通过域名得知,自动售货机的名字和主域名: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厂商愿意提供固件和有趣的硬件,可以私信我。

本文作者:西帅哥哥过来看看,   属于FreeBuf原创奖励计划,未经许可禁止转载

自动售货机云端攻防

精彩推荐

自动售货机云端攻防

自动售货机云端攻防

自动售货机云端攻防 自动售货机云端攻防 自动售货机云端攻防

自动售货机云端攻防

原文  http://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651088409&idx=2&sn=918c51ab8f4ab9ddb9e2b584b8b78c30
正文到此结束
Loading...