大家好，我是小劉，開門見山，知名的開源項(xiàng)目 Apache Log4j 出事了！

2021 年 12 月 9 日，該項(xiàng)目被曝存在?嚴(yán)重安全漏洞?，攻擊者只需要向目標(biāo)機(jī)傳入一段特殊代碼，就能觸發(fā)漏洞，自由地在遠(yuǎn)程執(zhí)行任意代碼來控制目標(biāo)機(jī)器！

老實(shí)說，光聽到這個(gè)消息，我就覺得很可怕了。因?yàn)?Log4j 作為 Java 的知名日志記錄框架，憑借其靈活高效的日志生成能力，不僅被眾多自研項(xiàng)目所使用，還被很多明星項(xiàng)目作為了基礎(chǔ)框架使用，像 Redis、Kafka、Elasticsearch、Apache Flink、Apache Druid 等等?？梢韵胂筮@個(gè)漏洞的影響范圍有多大，甚至被很多媒體稱之為 “核彈級(jí)” 漏洞！

最近幾天大家都會(huì)被這么一條IT行業(yè)的新聞刷屏了：

那問題來了 Log4j2是什么呢？

Apache Log4j2 是一個(gè)基于Java的日志記錄工具，是 Log4j 的升級(jí)，在其前身Log4j 1.x基礎(chǔ)上提供了 Logback 中可用的很多優(yōu)化，同時(shí)修復(fù)了Logback架構(gòu)中的一些問題，是目前最優(yōu)秀的 Java日志框架之一。

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

這次的bug漏洞是：

Apache Log4j 2是一款優(yōu)秀的Java日志框架。該工具重寫了Log4j框架，并且引入了大量豐富的特性。該日志框架被大量用于業(yè)務(wù)系統(tǒng)開發(fā)，用來記錄日志信息。由于Apache Log4j 2某些功能存在遞歸解析功能，攻擊者可直接構(gòu)造惡意請(qǐng)求，觸發(fā)遠(yuǎn)程代碼執(zhí)行漏洞。

此次 Apache Log4j2 漏洞觸發(fā)條件為只要外部用戶輸入的數(shù)據(jù)會(huì)被日志記錄，即可造成遠(yuǎn)程代碼執(zhí)行。

? ? ? ? ? ?

那怎么在項(xiàng)目中找到是否用到了log4j2呢？

那我來教程一波：

上面是在pom.xml的依賴

我們ctrl+shift+alt+u?：跳到idea的依賴圖譜

然后在ctrl+f?中搜索log4j就知道，項(xiàng)目中是否用到了它了。

說說：log4j2

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

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


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

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

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

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

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

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

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

JNDI

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

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

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

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

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

LDAP

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

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

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

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

bug漏洞的原理

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

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

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


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

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

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

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


接下來，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ù)，那也沒什么，但問題就出在還可以請(qǐng)求Java對(duì)象！

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

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

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

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

危險(xiǎn)在哪里？

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

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

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

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

JNDI 注入

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

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

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

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

影響規(guī)模

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

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

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

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

修復(fù)措施

建議排查Java應(yīng)用是否引入log4j-api , log4j-core 兩個(gè)jar，若存在使用，極大可能會(huì)受到影響，強(qiáng)烈建議受影響用戶盡快進(jìn)行防護(hù) 。

1. 升級(jí)Apache Log4j 2所有相關(guān)應(yīng)用到最新的 log4j-2.15.0-rc2 版本，地址：https://github.com/apache/logginglog4j2/releases/tag/log4j-2.15.0-rc2

2. 升級(jí)已知受影響的應(yīng)用及組件，如：

3. 
   

1. spring-boot-strater-log4j2

2. Apache Solr

3. Apache Flink

4. Apache Druid

緊急緩解措施：

如果還來不及更新版本修復(fù)，可通過下面的方法緊急緩解問題

（1） 修改jvm參數(shù)?-Dlog4j2.formatMsgNoLookups=true

（2） 修改配置：log4j2.formatMsgNoLookups=True

（3） 將系統(tǒng)環(huán)境變量?FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS?設(shè)置為 true

1、https://github.com/apache/logging-log4j2

2、https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

總結(jié)：

1.這log4j出現(xiàn)漏洞，影響了很多的知名項(xiàng)目像 Redis、Kafka、Elasticsearch、Apache Flink、Apache Druid 等等。

2.解決方案：

• 1.升級(jí)版本

  目前 Apache 官方已經(jīng)針對(duì)該漏洞發(fā)布了補(bǔ)丁版本?2.15.0-rc2，默認(rèn)禁用了 lookup 行為，在確保升級(jí)該版本不會(huì)對(duì)項(xiàng)目的其他依賴產(chǎn)生沖突的情況下，建議升級(jí)。

  該方案雖然比較簡單粗暴，但這個(gè)版本是否穩(wěn)定？是否沒有漏洞呢？這很難說。

• 2.修改參數(shù)

如果你不想升級(jí) log4j 的版本，擔(dān)心會(huì)和項(xiàng)目其他依賴產(chǎn)生沖突的話，可以采用 Apache 官方推薦的臨時(shí)解決方案 —— 修改參數(shù)。

如果你的 log4j 版本 >= 2.10，可以通過設(shè)置系統(tǒng)屬性?log4j2.formatMsgNoLookups?或者環(huán)境變量?LOG4J_FORMAT_MSG_NO_LOOKUPS?為?true?來禁用 lookup 行為；如果版本在 2.0-beta9 到 2.10.0 之間， 可以直接移除從 classpath 中移除 ?JndiLookup?類，用以下命令即可：

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class



這個(gè)方案相對(duì)不容易引發(fā)項(xiàng)目的沖突，如果項(xiàng)目很緊急且重要，先用它處理吧。

• 3.換框架

最暴力、也是解決最徹底的方案就是干脆不用 log4j 了，用別的！

比如我自己很早之前就棄用 log4j，改用 logback 了，不說別的，logback 的測試更加充分，質(zhì)量相對(duì)有保障一些。畢竟日志框架作為一個(gè)項(xiàng)目必備的核心依賴，穩(wěn)定性是至關(guān)重要的。

當(dāng)然，這種方式對(duì)項(xiàng)目的影響可能會(huì)很大，如果一定要整體替換框架，建議進(jìn)行充分的測試（覆蓋率越高越好），可不是改幾行代碼那么簡單。

• 4.重新寫一個(gè)（這個(gè)不符合現(xiàn)實(shí)，只是口嗨，哈哈哈哈哈）

3.這個(gè)漏洞，讓我們知道了軟件開發(fā)中的?不信任原則?，沒有絕對(duì)可信、完全不出問題的服務(wù)，所以我們開發(fā)者要做的就是時(shí)刻多留一個(gè)心眼兒，盡量針對(duì)一些服務(wù)的不穩(wěn)定去設(shè)計(jì)一些保護(hù)或降級(jí)措施。比如假設(shè)分布式緩存會(huì)掛掉，可以再設(shè)計(jì)本地緩存繼續(xù)提供臨時(shí)服務(wù)，保障系統(tǒng)的可用性。

4.不過還行，這次漏洞沒怎么影響我，我那個(gè)項(xiàng)目才開始寫，既然出現(xiàn)了漏洞了，那我就把我的那個(gè)模塊的log4j刪除在引入其他的日志框架就行，問題不大。

5.我不知道，其他的小伙伴你們這個(gè)周末加班，修復(fù)漏洞了沒，躺槍了沒。

標(biāo)簽：