大家好，我是周杰倫。

相信大家這兩天應(yīng)該被這么一條新聞刷屏了：

這個(gè)漏洞到底是怎么回事？

核彈級(jí)，真的有那么厲害嗎？

怎么利用這個(gè)漏洞呢？

我看了很多技術(shù)分析文章，都太過(guò)專業(yè)，很多非Java技術(shù)?；蛘卟桓惆踩娜酥荒芸磦€(gè)一知半解，導(dǎo)致大家只能看個(gè)熱鬧，對(duì)這個(gè)漏洞的成因、原理、利用方式、影響面理解的不到位。

這篇文章，我嘗試讓所有技術(shù)相關(guān)的朋友都能看懂**：這個(gè)注定會(huì)載入網(wǎng)絡(luò)安全史冊(cè)上的漏洞，到底是怎么一回事！**

log4j2

不管是什么編程語(yǔ)言，不管是前端后端還是客戶端，對(duì)打日志都不會(huì)陌生。

通過(guò)日志，可以幫助我們了解程序的運(yùn)行情況，排查程序運(yùn)行中出現(xiàn)的問(wèn)題。

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

今天討論的主角就是log4j2。

我們經(jīng)常會(huì)在日志中輸出一些變量，比如：

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

現(xiàn)在思考一個(gè)問(wèn)題：

假如現(xiàn)在想要通過(guò)日志輸出一個(gè)Java對(duì)象，但這個(gè)對(duì)象不在程序中，而是在其他地方，比如可能在某個(gè)文件中，甚至可能在網(wǎng)絡(luò)上的某個(gè)地方，這種時(shí)候怎么辦呢？

log4j2的強(qiáng)大之處在于，除了可以輸出程序中的變量，它還提供了一個(gè)叫Lookup的東西，可以用來(lái)輸出更多內(nèi)容：

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

lookup相當(dāng)于是一個(gè)接口，具體去哪里查找，怎么查找，就需要編寫具體的模塊去實(shí)現(xiàn)了，類似于面向?qū)ο缶幊讨卸鄳B(tài)那意思。

好在，log4j2已經(jīng)幫我們把常見(jiàn)的查找途徑都進(jìn)行實(shí)現(xiàn)了：

具體每一個(gè)的意思，這里就不詳述了，這不是本文的重點(diǎn)。

JNDI

主要來(lái)看其中那個(gè)叫JNDI的東西：

JNDI即Java Naming and Directory Interface（JAVA命名和目錄接口），它提供一個(gè)目錄系統(tǒng)，并將服務(wù)名稱與對(duì)象關(guān)聯(lián)起來(lái)，從而使得開發(fā)人員在開發(fā)過(guò)程中可以使用名稱來(lái)訪問(wèn)對(duì)象。

看不懂？看不懂就對(duì)了！

簡(jiǎn)單粗暴理解：有一個(gè)類似于字典的數(shù)據(jù)源，你可以通過(guò)JNDI接口，傳一個(gè)name進(jìn)去，就能獲取到對(duì)象了。

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

LDAP

繼續(xù)把目光聚焦，咱們只看這個(gè)叫LDAP的東西。

LDAP即Lightweight Directory Access Protocol（輕量級(jí)目錄訪問(wèn)協(xié)議），目錄是一個(gè)為查詢、瀏覽和搜索而優(yōu)化的專業(yè)分布式數(shù)據(jù)庫(kù)，它呈樹狀結(jié)構(gòu)組織數(shù)據(jù)，就好象Linux/Unix系統(tǒng)中的文件目錄一樣。目錄數(shù)據(jù)庫(kù)和關(guān)系數(shù)據(jù)庫(kù)不同，它有優(yōu)異的讀性能，但寫性能差，并且沒(méi)有事務(wù)處理、回滾等復(fù)雜功能，不適于存儲(chǔ)修改頻繁的數(shù)據(jù)。所以目錄天生是用來(lái)查詢的，就好像它的名字一樣。

看不懂？看不懂就對(duì)了！

這個(gè)東西用在統(tǒng)一身份認(rèn)證領(lǐng)域比較多，但今天也不是這篇文章的重點(diǎn)。你只需要簡(jiǎn)單粗暴理解：有一個(gè)類似于字典的數(shù)據(jù)源，你可以通過(guò)LDAP協(xié)議，傳一個(gè)name進(jìn)去，就能獲取到數(shù)據(jù)。

漏洞原理

好了，有了以上的基礎(chǔ)，再來(lái)理解這個(gè)漏洞就很容易了。

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

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

網(wǎng)絡(luò)安全中有一個(gè)準(zhǔn)則：不要信任用戶輸入的任何信息。

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

假如有人發(fā)來(lái)了一個(gè)HTTP請(qǐng)求，他的User-Agent是這樣一個(gè)字符串：

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

接下來(lái)，log4j2將會(huì)對(duì)這行要輸出的字符串進(jìn)行解析。

首先，它發(fā)現(xiàn)了字符串中有?${}，知道這個(gè)里面包裹的內(nèi)容是要單獨(dú)處理的。

進(jìn)一步解析，發(fā)現(xiàn)是JNDI擴(kuò)展內(nèi)容。

再進(jìn)一步解析，發(fā)現(xiàn)了是LDAP協(xié)議，LDAP服務(wù)器在127.0.0.1，要查找的key是exploit。

最后，調(diào)用具體負(fù)責(zé)LDAP的模塊去請(qǐng)求對(duì)應(yīng)的數(shù)據(jù)。

如果只是請(qǐng)求普通的數(shù)據(jù)，那也沒(méi)什么，但問(wèn)題就出在還可以請(qǐng)求Java對(duì)象！

Java對(duì)象一般只存在于內(nèi)存中，但也可以通過(guò)序列化的方式將其存儲(chǔ)到文件中，或者通過(guò)網(wǎng)絡(luò)傳輸。

如果是自己定義的序列化方式也還好，但更危險(xiǎn)的在于：JNDI還支持一個(gè)叫命名引用（Naming References）的方式，可以通過(guò)遠(yuǎn)程下載一個(gè)class文件，然后下載后加載起來(lái)構(gòu)建對(duì)象。

PS：有時(shí)候Java對(duì)象比較大，直接通過(guò)LDAP這些存儲(chǔ)不方便，就整了個(gè)類似于二次跳轉(zhuǎn)的意思，不直接返回對(duì)象內(nèi)容，而是告訴你對(duì)象在哪個(gè)class里，讓你去那里找。

注意，這里就是核心問(wèn)題了：JNDI可以遠(yuǎn)程下載class文件來(lái)構(gòu)建對(duì)象！?。?/strong>。

危險(xiǎn)在哪里？

如果遠(yuǎn)程下載的URL指向的是一個(gè)黑客的服務(wù)器，并且下載的class文件里面藏有惡意代碼，那不就完?duì)僮恿藛幔?/p>

還沒(méi)看懂？沒(méi)關(guān)系，我畫了一張圖：

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

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

JNDI 注入

其實(shí)這種攻擊手法不是這一次出現(xiàn)了，早在2016的blackhat大會(huì)上，就有大佬披露了這種攻擊方式。

回過(guò)頭來(lái)看，問(wèn)題的核心在于：

Java允許通過(guò)JNDI遠(yuǎn)程去下載一個(gè)class文件來(lái)加載對(duì)象，如果這個(gè)遠(yuǎn)程地址是自己的服務(wù)器，那還好說(shuō)，如果是可以被外界來(lái)指定的地址，那就要出大問(wèn)題！

前面的例子中，一直用的127.0.0.1來(lái)代替LDAP服務(wù)器地址，那如果輸入的User-Agent字符串中不是這個(gè)地址，而是一個(gè)惡意服務(wù)器地址呢？

影響規(guī)模

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

一方面現(xiàn)在Java技術(shù)棧在Web、后端開發(fā)、大數(shù)據(jù)等領(lǐng)域應(yīng)用非常廣泛，國(guó)內(nèi)除了阿里巴巴、京東、美團(tuán)等一大片以Java為主要技術(shù)棧的公司外，還有多如牛毛的中小企業(yè)選擇Java。

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

在上面這些開發(fā)過(guò)程中，大量使用了log4j2作為日志輸出。只要一個(gè)不留神，輸出的日志有外部輸入混進(jìn)來(lái)，那直接就是遠(yuǎn)程代碼執(zhí)行RCE，滅頂之災(zāi)！

修復(fù)

新版的log4j2已經(jīng)修復(fù)了這個(gè)問(wèn)題，大家趕緊升級(jí)。

下面是log4j2官網(wǎng)中關(guān)于JNDI lookup的說(shuō)明：

我通過(guò)搜索引擎找到了緩存的12月10號(hào)前的快照，大家對(duì)比一下，比起下面這個(gè)緩存，上面那一版多了哪些東西？答案是：修復(fù)后的log4j2在JNDI lookup中增加了很多的限制：

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

默認(rèn)不再支持二次跳轉(zhuǎn)（也就是命名引用）的方式獲取對(duì)象 只有在log4j2.allowedLdapClasses列表中指定的class才能獲取。 只有遠(yuǎn)程地址是本地地址或者在log4j2.allowedLdapHosts列表中指定的地址才能獲取

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

最后，手機(jī)前的各位Java小伙伴兒們，你們寫的程序中有用到log4j2嗎，有沒(méi)有某個(gè)地方的輸出，有外部的參數(shù)混進(jìn)來(lái)呢？

趕緊檢查檢查哦！ 另外有想自己復(fù)現(xiàn)這個(gè)漏洞的同學(xué)可以領(lǐng)取一份漏洞復(fù)現(xiàn)，修復(fù)資料，代碼工具的資料

點(diǎn)擊下方傳送門即可免費(fèi)領(lǐng)取

【漏洞復(fù)現(xiàn)，修復(fù)資料，代碼工具】

大家弄懂這個(gè)漏洞了嗎？如果覺(jué)得寫得還不錯(cuò)，歡迎分享轉(zhuǎn)發(fā)，順便給俺點(diǎn)個(gè)贊，感謝大家的閱讀。