[[439901]]

大家好，我是軒轅。

相信大家這兩天應該被這么一條新聞刷屏了：

這個漏洞到底是怎么回事?

核彈級，真的有那么厲害嗎?

怎么利用這個漏洞呢?

我看了很多技術分析文章，都太過專業，很多非Java技術棧或者不搞安全的人只能看個一知半解，導致大家只能看個熱鬧，對這個漏洞的成因、原理、利用方式、影響面理解的不到位。

這篇文章，我嘗試讓所有技術相關的朋友都能看懂：這個注定會載入網絡安全史冊上的漏洞，到底是怎么一回事!

log4j2

不管是什么編程語言，不管是前端后端還是客戶端，對打日志都不會陌生。

通過日志，可以幫助我們了解程序的運行情況，排查程序運行中出現的問題。

在Java技術棧中，用的比較多的日志輸出框架主要是log4j2和logback。

今天討論的主角就是log4j2。

我們經常會在日志中輸出一些變量，比如：

logger.info("client ip: {}", clientIp) 

現在思考一個問題：

假如現在想要通過日志輸出一個Java對象，但這個對象不在程序中，而是在其他地方，比如可能在某個文件中，甚至可能在網絡上的某個地方，這種時候怎么辦呢?

log4j2的強大之處在于，除了可以輸出程序中的變量，它還提供了一個叫Lookup的東西，可以用來輸出更多內容：

lookup，顧名思義就是查找、搜索的意思，那在log4j2中，就是允許在輸出日志的時候，通過某種方式去查找要輸出的內容。

lookup相當于是一個接口，具體去哪里查找，怎么查找，就需要編寫具體的模塊去實現了，類似于面向對象編程中多態那意思。

好在，log4j2已經幫我們把常見的查找途徑都進行實現了：

具體每一個的意思，這里就不詳述了，這不是本文的重點。

JNDI

主要來看其中那個叫JNDI的東西：

JNDI即Java Naming and Directory Interface(JAVA命名和目錄接口)，它提供一個目錄系統，并將服務名稱與對象關聯起來，從而使得開發人員在開發過程中可以使用名稱來訪問對象。

看不懂?看不懂就對了!

簡單粗暴理解：有一個類似于字典的數據源，你可以通過JNDI接口，傳一個name進去，就能獲取到對象了。

那不同的數據源肯定有不同的查找方式，所以JNDI也只是一個上層封裝，在它下面也支持很多種具體的數據源。

LDAP

繼續把目光聚焦，咱們只看這個叫LDAP的東西。

LDAP即Lightweight Directory Access Protocol(輕量級目錄訪問協議)，目錄是一個為查詢、瀏覽和搜索而優化的專業分布式數據庫，它呈樹狀結構組織數據，就好象Linux/Unix系統中的文件目錄一樣。目錄數據庫和關系數據庫不同，它有優異的讀性能，但寫性能差，并且沒有事務處理、回滾等復雜功能，不適于存儲修改頻繁的數據。所以目錄天生是用來查詢的，就好像它的名字一樣。

看不懂?看不懂就對了!

這個東西用在統一身份認證領域比較多，但今天也不是這篇文章的重點。你只需要簡單粗暴理解：有一個類似于字典的數據源，你可以通過LDAP協議，傳一個name進去，就能獲取到數據。

漏洞原理

好了，有了以上的基礎，再來理解這個漏洞就很容易了。

假如某一個Java程序中，將瀏覽器的類型記錄到了日志中：

String userAgent = request.getHeader("User-Agent"); 
 
logger.info(userAgent); 

網絡安全中有一個準則：不要信任用戶輸入的任何信息。

這其中，User-Agent就屬于外界輸入的信息，而不是自己程序里定義出來的。只要是外界輸入的，就有可能存在惡意的內容。

假如有人發來了一個HTTP請求，他的User-Agent是這樣一個字符串：

${jndi:ldap://127.0.0.1/exploit} 

接下來，log4j2將會對這行要輸出的字符串進行解析。

首先，它發現了字符串中有 ${}，知道這個里面包裹的內容是要單獨處理的。

進一步解析，發現是JNDI擴展內容。

再進一步解析，發現了是LDAP協議，LDAP服務器在127.0.0.1，要查找的key是exploit。

最后，調用具體負責LDAP的模塊去請求對應的數據。

如果只是請求普通的數據，那也沒什么，但問題就出在還可以請求Java對象!

Java對象一般只存在于內存中，但也可以通過序列化的方式將其存儲到文件中，或者通過網絡傳輸。

如果是自己定義的序列化方式也還好，但更危險的在于：JNDI還支持一個叫命名引用(Naming References)的方式，可以通過遠程下載一個class文件，然后下載后加載起來構建對象。

PS：有時候Java對象比較大，直接通過LDAP這些存儲不方便，就整了個類似于二次跳轉的意思，不直接返回對象內容，而是告訴你對象在哪個class里，讓你去那里找。

注意，這里就是核心問題了：JNDI可以遠程下載class文件來構建對象!!!。

危險在哪里?

如果遠程下載的URL指向的是一個黑客的服務器，并且下載的class文件里面藏有惡意代碼，那不就完犢子了嗎?

還沒看懂?沒關系，我畫了一張圖：

這就是鼎鼎大名的JNDI注入攻擊!

其實除了LDAP，還有RMI的方式，有興趣的可以了解下。

JNDI 注入

其實這種攻擊手法不是這一次出現了，早在2016的blackhat大會上，就有大佬披露了這種攻擊方式。

回過頭來看，問題的核心在于：

Java允許通過JNDI遠程去下載一個class文件來加載對象，如果這個遠程地址是自己的服務器，那還好說，如果是可以被外界來指定的地址，那就要出大問題!

前面的例子中，一直用的127.0.0.1來代替LDAP服務器地址，那如果輸入的User-Agent字符串中不是這個地址，而是一個惡意服務器地址呢?

影響規模

這一次漏洞的影響面之所以如此之大，主要還是log4j2的使用面實在是太廣了。

一方面現在Java技術棧在Web、后端開發、大數據等領域應用非常廣泛，國內除了阿里巴巴、京東、美團等一大片以Java為主要技術棧的公司外，還有多如牛毛的中小企業選擇Java。

另一方面，還有好多像kafka、elasticsearch、flink這樣的大量中間件都是用Java語言開發的。

在上面這些開發過程中，大量使用了log4j2作為日志輸出。只要一個不留神，輸出的日志有外部輸入混進來，那直接就是遠程代碼執行RCE，滅頂之災!

修復

新版的log4j2已經修復了這個問題，大家趕緊升級。

下面是log4j2官網中關于JNDI lookup的說明：

我通過搜索引擎找到了緩存的12月10號前的快照，大家對比一下，比起下面這個緩存，上面那一版多了哪些東西?

答案是：修復后的log4j2在JNDI lookup中增加了很多的限制：

默認不再支持二次跳轉(也就是命名引用)的方式獲取對象

只有在log4j2.allowedLdapClasses列表中指定的class才能獲取。

只有遠程地址是本地地址或者在log4j2.allowedLdapHosts列表中指定的地址才能獲取

以上幾道限制，算是徹底封鎖了通過打印日志去遠程加載class的這條路了。

最后，手機前的各位Java小伙伴兒們，你們寫的程序中有用到log4j2嗎，有沒有某個地方的輸出，有外部的參數混進來呢?

 

趕緊檢查檢查哦!