小刻也能读懂的但待更——[NCTF 2023]EvilMQ
思路来源于前段时间的 ActiveMQ RCE CVE−2023−46604 , 后面 GitHub 全网搜了下 Apache 的其它项目发现这个 TubeMQ 也存在类似的问题, 不过这个是 Client 端 RCE, 需要自己构造一个 Evil Server
非常抱歉,由于作者对Java语言的不熟悉,复现和理解的时候出现了一些问题,这道题目需要等后续进一步的深入才研究。
前置知识
https://juejin.cn/post/6844903920209231886
MQ 能干什么
小明是一名程序员,他写了一个 A 模块(比如订单模块),这天,写了 B 模块(比如库存模块)的小林想让小明给他一个接口,让他根据订单减少库存
小明欣然答应,写了一个/reduceStock
,但是写了通知模块的小李也想要小明给他写一个接口 /sendNotification
,他想要根据订单给用户发通知。此外,写了统计模块的小红也想要小明给他写一个接口 /getOrders
,他想要根据订单统计数据。
小明有两种选择:
A.写三个接口
结局 A:小明要写很多接口,写的时候复杂,维护又很难,618 因为所有接口都被疯狂的调用,小明的系统挂了,于是,所有的系统都挂了…..用户无法购物,业绩直线下降,小明被开除了…
B.用消息中间件(Message Queue)
结局 B:小明使用了 MQ,当用户下单以后,订单模块把订单信息发送到消息队列,比如说:
1 | { |
这样写了库存模块的小林只需要订阅"items"
的消息,写了通知模块的小李只需要订阅他需要的消息,写了统计模块的小红只需要订阅 "total_amount"
的消息。
这样,即使小明的模块挂了,其他的模块照常工作,也不用去写很多的接口了。订单很多,但是有 MQ 分散了压力,没有挂,小明保住了工作。
MQ 里面有什么
MQ 是一个系统,我们这次要了解的是 Producer,Consumer 和 Broker。
谁发起请求,谁就是客户端;谁响应请求,谁就是服务端。
👉 所以 TubeMQ 中:
组件 | 作用 | 是客户端还是服务端 |
---|---|---|
Producer | 发送消息 | 客户端 |
Consumer | 订阅消费消息 | 客户端 |
Broker | 接收/中转/派发消息 | 服务端(Server) |
正常情况下,Producer 和 Consumer 向 Broker 发消息,请求响应。
作为黑客,我们这里伪造了一个Broker,当Producer 和 Consumer 连上Broker,Broker 就返回恶意构造的响应 。
ActiveMQ 是什么
ActiveMQ 是一个开源的消息中间件,支持 Java 消息服务规范(JMS,Java Message Service)。我们可以把 JMS 理解成“Java语言里对消息中间件的一种标准规定”。
JMS 规定了两种模型,也就是消息传递的“方式”:
1️⃣ 点对点模型(Point-to-Point,简称 P2P)
2️⃣ 发布/订阅模型(Publish/Subscribe,简称 Pub/Sub)
TubeMQ 是什么
TubeMQ 是腾讯在2013年自研的分布式消息中间件,专为大数据场景下海量数据的高性能传输和存储而设计。它具有高吞吐、低延迟、高可靠性等特点,并经过了腾讯内部大规模业务的验证,如微信支付、腾讯视频等。2019年,TubeMQ正式开源,并捐赠给Apache软件基金会。