记一次对某物联网云平台及Hadoop生态系统的渗透全过程
Part1 前言
大家好，我是ABC_123。本期分享一个之前做过的针对某物联网云平台的渗透测试案例，包括了对Hadoop生态系统的内网横向过程，由于内网很多都是Yarn、MapReduce、Spark、HDFS、Ambari、Hortonworks这些组件，平时很少遇到，由此开始了长达3个月的断断续续地一边学习，一边研究的历程。
在此期间，我基本上把网上公布的所有的Hadoop组件的漏洞都尝试了一遍，在不懈的努力下，最后还是取得了很多成果。今天就重新复习总结一下之前所学到的知识。
建议大家把公众号“希潭实验室”设为星标，否则可能就看不到啦！因为公众号现在只对常读和星标的公众号才能展示大图推送。操作方法：点击右上角的【...】，然后点击【设为星标】即可。
Part2 前置知识
首先介绍一下Hadoop生态系统，让大家先入个门，否则后面的文章可能看不懂。
Ambari：如果把Hadoop比作一个拥有多个建筑物和各种设施大型的科技园区，包含了大量的服务器、存储设备和数据处理组件，Ambari相当于园区的管理办公室。它提供了一个集中化的界面和工具，用于管理和监控 Hadoop 集群的各个方面，包括集群的配置和安装，服务的监控和资源使用，资源调度和分配，故障诊断和日志分析。
YARN：YARN是Hadoop的资源管理器，负责底层的资源管理和任务调度；而Ambari是一个集群管理工具，用于配置、部署和监控Hadoop集群及其相关服务。
KDC秘钥分发系统：可以比喻为一个类似于门禁系统的组件，在进入Hadoop园区之前，到达门禁处，你提供身份信息通过身份验证，门禁中心KDC会给你颁发一个访问令牌TGT，允许你在Hadoop园区访问各种设施和资源。在 Hadoop 集群中，KDC 充当门禁中心的角色，确保集群内部的安全通信和资源访问，类似于一个园区的门禁系统确保只有授权人员才能进入园区并访问各种设施。
HDFS：Hadoop Distributed File System，比作园区内的数据存储中心或数据仓库。
Spark：比作园区内的高性能计算中心或超级计算机。
MapReduce：将数据处理任务切分为多个并行执行的子任务，并将这些任务分配给集群中的不同节点进行计算。
HDFS、HIVE、Hbase之间的关系如下：
Pig、Impala、Shark组件关系如下：
总结起来，Pig适用于灵活的数据加工和转换；Impala专注于实时查询和分析结构化数据；而Shark/Spark SQL则结合了数据加工和实时查询的能力，并具备更好的性能和交互性。
MapReduce适用于离线批处理作业；Spark提供了广泛的数据处理功能和内存计算能力；Tez通过DAG执行模型和优化策略提供更高效的作业执行。它们各自在处理大规模数据时具有不同的特点和优势。
Part3 复盘过程
首先放出一张ABC_123绘制的关于此次项目的流程图，由于原图丢失，下面这张图是我“翻箱倒柜”找到的一张小图，然后经过AI图片处理软件放大后的，基本上只能处理到这个清晰程度了，后续有精力再重新画一张，接下来就把此次渗透工作的关键步骤给大家讲一讲。
这个图是上图的缩小版，不同的颜色代表不同的组件，这两个图都是用国外的maltego(情报分析)工具做的，一边渗透一边记录，但是现在这款工具基本上不用了。
外网打点过程
由于平时很少遇到对物联网云平台及Hadoop生态系统的渗透工作，很多系统都是第一次见到，外网资产非常少，所以外网打点过程异常艰难，最终在前两周，打了2个入口点。
1 Zeppelin后台反弹shell
Zeppelin是一个开源的数据分析和可视化平台，提供了一个交互式环境，让用户可以使用多种编程语言进行数据分析和处理，同时也提供了丰富的数据可视化功能，本次项目中，它与Hadoop生态系统的许多组件进行集成和使用。
首先通过github搜索该网站的各种子域名的源代码，无意中找到了一处java代码，直接写出了明文的Zeppelin用户名及密码（下图是效果图，非原图）。
接下来使用该用户名密码直接登录了Zeppelin的后台。
网上有很多的Zeppelin的后台执行系统命令的方法，一般执行命令的点都在如下图位置，但是我记得在本次渗透实战中，网上的各种方法都不好用。于是我看了Zeppelin的使用说明书，看了一天多，找到了另一处可以执行任意cmd命令代码的位置，这里暂时不提供，大家可以自己尝试看看。
这样就通过Zepplin后台执行命令，直接反弹了一个Linux的shell，并注入Socks5代理程序。
2 物联网云平台部署Docker存在网络隔离问题
这是在外网的另一个入口，普通用户都可以注册账号，登录后台之后可以部署Docker，用户可以自由选择Nginx、Httpd、Mysql、Nodejs等docker环境。于是我萌生了一个想法，docker的网络隔离会不会有问题呢？于是我挨个部署各种docker，均没有安全问题，在我即将放弃的时候，部署了nodejs的应用，在该应用的管理界面可执行cmd命令（以下是效果图，非原图）。
如下图所示，部署的docker应用，存在cmd命令操作接口，可以直接执行命令，并且带有回显，而且此docker可以连接外网，后续的渗透发现，该docker居然可以直接连通hadoop生态系统的一些组件，比如访问存在未授权访问的hadoop，访问Spark系统，访问zabbix等。
权限维持问题
这里面有个关键点，权限维持3个月是怎么做到的，大致做法如下：
1. Zeppelin应用由于是非docker环境，反弹的Socks5代理比较稳定，主要应对一些流量比较大的操作及耗费系统性能的内网漏洞扫描工作。
2. docker的socks5代理，主要用来做权限维持的备用方案。这个docker容器非常不稳定，代理流量一大就会断掉，一旦运行多线程扫描工具就会卡死。于是我申请了多个账号，在后台应用部署了多个docker应用，每个docker都做了一个socks5代理，并用了不同的socks5代理IP。
3. docker的socks5代理结合内网的zabbix权限。后续管理员经常会关停Zeppelin系统，好在内网的zabbix是有漏洞的，首先通过docker的socks5代理访问内网，然后在内网zabbix上运行扫描工具。一旦这个入口被关闭，我就有了备选方案。
归纳总结：留了多个socks5代理入口，用了不同的代理ip地址，然后全程基本上只用其中的一两个入口，保留一到两个从未使用的入口。
Hadoop生态系统的内网横向
1 Ambari管理员权限
这个系统的管理员密码最终被猜解到，比如说网站是www.xxx.com，Ambari的弱口令就是xxx@2022，也就是域名+@+年份组合。
2 KDC密钥分发系统漏洞
这个系统是在项目进行2个多月的时候拿下的，当时我几乎把所有类型的hadoop组件都看过一遍了，就剩下最重要的KDC秘钥分发系统的3个IP没看，起初我认为这个KDC秘钥分发系统是不太可能有重要漏洞的，结果大跌眼镜，没想到还真有重大收获。
对这3个IP全端口扫描之后，发现开放了389端口，猜想这是KDC秘钥分发系统的LDAP服务，用一个ldap连接工具尝试链接，起初是为了查询ldap服务的域名的，结果居然连上LDAP数据库了！当时记得特别清楚，还以为自己看花眼了，LDAP服务居然开放了匿名登录，这真是一个严重的漏洞。
于是接下来看了另外两个KDC系统的LDAP服务，有一个可以匿名登录，另一个不可以。最后在ldap服务里面翻了很长时间，基本上整个hadoop生态的各种密码都存放在里面，其中Spark系统的密码是明文的，有的组件好像是加密的，具体情况记不清了（以下截图为虚拟机测试环境截图）。
最终这个ldap匿名登录问题，导致了整个Hadoop生态系统的沦陷，是在内网中发现的最严重的安全问题。而且Spark系统的管理员密码，基本上是通用的，很多外网的系统都可以用这个账号密码进行登录。
外网应用的MQTT协议安全问题
MQTT（Message Queuing Telemetry Transport）是一种轻量级的通信协议，主要用于在物联网设备、传感器和应用程序之间进行实时消息传递，具体看下图解释。
如下图所示，利用上述获取到的Spark管理员的密码，可以登陆外网的一个Web应用系统，登录后台之后，发现了类似于如下图的功能，右键F12可以看到明文密码（以下是效果图，非原图）。
最终组合得到一个MQTT协议的连接字符串：mqtt://uusfwefwfewf:Twefewewfewfewff@mqtt.xxx.com.cn:8083/mqtt，接下来我就犯了难，怎么去使用它呢？查阅大量的资料，发现有一款工具HiveMQ可以操作，如下图所示，提示“connected”连接成功。
这里面存在的安全问题就是，mqtt的连接地址允许任意IP地址登录，没有做可信登录，导致任意攻击者可以针对物联网设备进行操控。
其它漏洞汇总
这些漏洞的利用过程就不过多介绍了，相信大家都耳熟能详。外网有一个mysql延迟注入漏洞，还有几个越权漏洞、逻辑漏洞；内网包括以下漏洞：zookeeper未授权访问漏洞、zabbix组件反弹shell漏洞、Spark系统代码执行漏洞、各种Hadoop未授权访问漏洞，有的可以直接下载日志文件、内网memchached未授权访问漏洞等等。
这里主要提到一点，针对Spark系统代码执行漏洞的利用，需要加载一个jar包，该漏洞的jar包编译最好在jdk1.6版本下，兼容性比较好，然后注意查看Spark系统的版本，选择相应的exp。
Part4 总结
1. Github源码泄露成了最重要的外网打点的突破口。
2. Docker容器的网络隔离没有做好，导致越权访问Hadoop集群的一些重要组件，造成大量日志文件泄露。
3. 内网最核心的KDC密钥分发系统的ldap服务允许匿名登录，造成了整个Hadoop生态系统的沦陷。
4. MQTT协议未设置白名单IP限制使用，也导致重要的安全问题。
5. 多留几个入口并借助正常的应用功能留后门，是权限维持的好办法。
公众号专注于网络安全技术分享，包括APT事件分析、红队攻防、蓝队分析、渗透测试、代码审计等，每周一篇，99%原创，敬请关注。
Contact me: 0day123abc#gmail.com(replace # with @)