Cloudflare如何安全應(yīng)對Log4j 2漏洞？

在Cloudflare，當(dāng)我們得知一個(gè)新的安全漏洞時(shí)，我們會迅速召集各個(gè)團(tuán)隊(duì)，設(shè)法回答兩個(gè)不同的問題：(1)我們可以采取什么措施來確?？蛻舻幕A(chǔ)結(jié)構(gòu)受到保護(hù)，以及(2)我們可以采取什么措施來確保我們自己的環(huán)境是安全的。昨天，即2021年12月9日，熱門的基于Java的日志記錄程序包Log4j中的一個(gè)嚴(yán)重漏洞被公開披露，我們的安全團(tuán)隊(duì)迅速采取行動，幫助應(yīng)對第一個(gè)問題并回答第二個(gè)問題。本帖探討第二個(gè)問題。

總而言之，該漏洞使攻擊者能夠在遠(yuǎn)程服務(wù)器上執(zhí)行代碼。由于Java和Log4j被廣泛使用，這很可能是自Heartbleed和ShellShock以來互聯(lián)網(wǎng)上最嚴(yán)重的漏洞之一。該漏洞列示為CVE-2021-44228。CVE描述稱該漏洞會影響不高于2.14.1的Log4j2版本，而在2.15中已修補(bǔ)漏洞。該漏洞還會影響log4j 1.x的所有版本；但是，1.x已終止生命周期，還包含不會被修復(fù)的其他漏洞。推薦的操作是升級到2.15。

時(shí)間表

每當(dāng)應(yīng)對突發(fā)事件時(shí)，我們首先會做的一件事情就是，開始草擬我們需要在相關(guān)情況的背景下評估和了解事件的時(shí)間表。此處時(shí)間表中的一些示例包括：

·2021-12-09 16:57 UTC-收到關(guān)于developers.cloudflare.com上的Log4j RCE的Hackerone報(bào)告

·2021-12-10 09:56 UTC-第一條WAF規(guī)則已傳輸?shù)紺loudflare Specials規(guī)則集

·2021-12-10 10:00 UTC-被操縱INCIDENT正式打開，開始工作以識別需要修復(fù)Log4j的區(qū)域

·2021-12-10 10:33 UTC-Logstash部署了修復(fù)程序以緩解漏洞。

·2021-12-10 10:44 UTC-第二條WAF規(guī)則作為Cloudflare管理的規(guī)則的一部分上線

·2021-12-10 10:50 UTC-ElasticSearch重啟開始修復(fù)以緩解漏洞

·2021-12-10 11:05 UTC-ElasticSearch重啟結(jié)束，不再有漏洞

·2021-12-10 11:45 UTC-Bitbucket已修復(fù)，不再有漏洞

·2021-12-10 21:22 UTC-Hackerone報(bào)告在無法復(fù)制之后作為有用信息Informative關(guān)閉

解決內(nèi)部影響

處理任何軟件漏洞時(shí)的一個(gè)重要問題，也可能是每家公司在這種特定情況下需要回答的最困難問題：有漏洞的軟件實(shí)際上都在哪些地方運(yùn)行？

如果漏洞位于一家公司向全世界許可的某個(gè)專有軟件中，這個(gè)問題很容易回答-您只需找到那個(gè)軟件即可。但在這種情況下，問題困難得多。Log4j是廣泛使用的一個(gè)軟件，但Java開發(fā)人員之外的人群可能并不熟悉。我們的首要行動就是重新熟悉我們的基礎(chǔ)結(jié)構(gòu)中在JVM上運(yùn)行該軟件的所有地方，以便確定哪些軟件組件可能容易受到該問題影響。

我們能夠使用集中代碼存儲庫創(chuàng)建在JVM上運(yùn)行的所有軟件的清單。我們使用該信息來研究并確定我們擁有的每一個(gè)Java應(yīng)用程序，它是否包含Log4j，以及其中編譯了哪個(gè)版本的Log4j。

我們發(fā)現(xiàn)ElasticSearch、LogStash和Bitbucket包含了版本介于2.0到2.14.1之間的有漏洞Log4j程序包的實(shí)例。我們能夠使用官方Log4j安全性文檔中描述的緩解策略來修復(fù)該問題。對于Log4j的每個(gè)實(shí)例，我們要么從classpath中刪除了JndiLookup類：

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

要么在log4j配置中設(shè)置了起緩解作用的系統(tǒng)屬性：

log4j2.formatMsgNoLookups

我們能夠使用這些策略在這些程序包中迅速緩解該問題，同時(shí)等待程序包的新版本發(fā)布。

審查外部報(bào)告

早在我們完成有漏洞軟件運(yùn)行所在內(nèi)部位置的列表擬定工作之前，我們就開始查看外部報(bào)告-來自我們的漏洞獎勵程序HackerOne，以及GitHub中提示我們可能面臨風(fēng)險(xiǎn)的公開帖子。

我們識別到至少兩個(gè)報(bào)告，似乎指示Cloudflare有漏洞并遭到破壞。在其中一個(gè)報(bào)告中有如下屏幕截圖：

該示例針對的是在https://developer.cloudflare.com中托管的開發(fā)人員文檔。在右側(cè)，攻擊者展示了針對他發(fā)送到我們服務(wù)器的有效負(fù)載，收到了DNS查詢。但是，此處標(biāo)記的IP地址是173.194.95.134，屬于Google擁有的IPv4子網(wǎng)(173.194.94.0/23)。

Cloudflare的開發(fā)人員文檔作為Cloudflare Worker托管，僅提供靜態(tài)資產(chǎn)。存儲庫是公開的。該Worker依賴Google的分析庫，如此處所示，因此，我們假定攻擊者不是從Cloudflare接收請求，而是通過Google的服務(wù)器接收。

我們的后端服務(wù)器從Workers接收日志記錄，但在這種情況下也無法開展漏洞利用，因?yàn)槲覀兝脧?qiáng)大的Kubernetes出口策略來防止向外傳輸?shù)交ヂ?lián)網(wǎng)。唯一允許的通信是傳輸?shù)骄x的一組內(nèi)部服務(wù)。

我們在收集更多信息時(shí)收到漏洞披露程序中的類似報(bào)告時(shí)，研究人員無法重現(xiàn)該問題。這進(jìn)一步強(qiáng)化了我們關(guān)于問題源自第三方服務(wù)器的假定，他們可能已經(jīng)修復(fù)該問題。

Cloudflare是否遭到破壞？

當(dāng)我們運(yùn)行如上所述的軟件版本時(shí)，多虧了我們迅速應(yīng)對并采用縱深防御方法，我們認(rèn)為Cloudflare沒有遭到破壞。我們投入了大量精力來驗(yàn)證這一點(diǎn)，并將繼續(xù)開展這一工作，直至弄清楚該漏洞的全部細(xì)節(jié)。下面簡單介紹一下這部分工作。

隨著我們努力評估和隔離可能在運(yùn)行有漏洞軟件的所有場景并加以修復(fù)，我們也開始了一個(gè)單獨(dú)的工作流，以分析其中是否有任何情況已被漏洞利用。我們的檢測和應(yīng)對方法遵循行業(yè)標(biāo)準(zhǔn)事件響應(yīng)實(shí)踐，并進(jìn)行了徹底部署，以驗(yàn)證我們的資產(chǎn)是否確實(shí)遭到破壞。我們采用了下面描述的多管齊下方法。

審查內(nèi)部數(shù)據(jù)

利用資產(chǎn)清單和代碼掃描工具，我們可以識別依賴Apache Log4j的所有應(yīng)用程序和服務(wù)。在審查并工具需要升級這些應(yīng)用程序的同時(shí)，我們還對這些服務(wù)和主機(jī)執(zhí)行了徹底的掃描。具體來說，CVE-2021-44228的漏洞利用依賴日志消息和參數(shù)中的特定模式，例如${jndi:(ldap[s]?|rmi|dns):/[^n]+。對于每個(gè)潛在受影響的服務(wù)，我們執(zhí)行了日志分析，以暴露任何漏洞利用企圖。

審查網(wǎng)絡(luò)分析

利用網(wǎng)絡(luò)分析，我們可以識別可疑的網(wǎng)絡(luò)行為，這些行為可能表明有人企圖或?qū)嶋H對我們的基礎(chǔ)結(jié)構(gòu)進(jìn)行漏洞利用。我們仔細(xì)檢查了網(wǎng)絡(luò)數(shù)據(jù)，識別到以下情況：

1.可疑的入站和出站活動

通過分析可疑的入站和出站連接，我們能夠掃描我們的環(huán)境，并識別我們的系統(tǒng)是否表現(xiàn)出正在被破壞的跡象。

2.針對的系統(tǒng)和服務(wù)

通過利用針對我們網(wǎng)絡(luò)數(shù)據(jù)的模式分析，我們發(fā)現(xiàn)了威脅入侵者針對的系統(tǒng)和服務(wù)。這樣一來，我們可以針對資產(chǎn)清單執(zhí)行相關(guān)性搜索，并向下鉆取到每個(gè)主機(jī)以確定這些機(jī)器是否暴露于該漏洞或正在被漏洞利用。

3.網(wǎng)絡(luò)指標(biāo)

從上述分析中，我們洞察了各種威脅入侵者的基礎(chǔ)結(jié)構(gòu)，并識別到攻擊者企圖利用該漏洞時(shí)所采用的網(wǎng)絡(luò)指標(biāo)。在Cloudflare Gateway中阻止了對這些指標(biāo)的出站活動。

審查端點(diǎn)

我們能夠?qū)⑷罩痉治龊途W(wǎng)絡(luò)分析工作流程相關(guān)聯(lián)，以補(bǔ)充端點(diǎn)分析。從這兩種分析的發(fā)現(xiàn)結(jié)果中，我們能夠制定端點(diǎn)掃描標(biāo)準(zhǔn)，以識別任何額外的潛在受影響系統(tǒng)，并分析各個(gè)端點(diǎn)，找出正在被破壞的跡象。我們采用了以下方法：

基于簽名的掃描

我們正在部署自定義Yara檢測規(guī)則，以提醒漏洞利用情況。這些規(guī)則將部署到我們的全部基礎(chǔ)結(jié)構(gòu)和我們的集中安全信息與事件管理(SIEM)工具上運(yùn)行的端點(diǎn)檢測和響應(yīng)代理中。

異常進(jìn)程執(zhí)行和持久性分析

Cloudflare持續(xù)從我們的基礎(chǔ)結(jié)構(gòu)收集和分析端點(diǎn)進(jìn)程事件。我們使用這些事件來搜索了漏洞利用后方法，如下載第二階段漏洞利用、異常子進(jìn)程，等等。

使用所有這些方法，我們沒有發(fā)現(xiàn)遭到破壞的證據(jù)。

第三方風(fēng)險(xiǎn)

在上述分析中，我們關(guān)注的是審查我們自己生成的代碼和數(shù)據(jù)。但就像大多數(shù)公司那樣，我們也依賴我們從第三方獲得許可的軟件。當(dāng)我們開始調(diào)查這件事的時(shí)候，我們還與公司的信息技術(shù)團(tuán)隊(duì)合作，擬出了每一家主要第三方提供商和所有子處理者的列表，以便詢問他們是否受影響。我們正在從提供商接收答復(fù)并進(jìn)行審查。我們視為重要的任何提供商，只要受到該漏洞影響，都會被禁用和阻止，直至他們完全修復(fù)漏洞。

驗(yàn)證我們的縱深防御方法的效果

隨著我們應(yīng)對該突發(fā)事件，我們發(fā)現(xiàn)我們的縱深防御方法在幾個(gè)地方發(fā)揮了作用。

1.限制出站流量

限制呼叫服務(wù)器的能力是kill-chain的基本組成部分，可大幅提高利用漏洞的難度。如上所述，我們利用Kubernetes網(wǎng)絡(luò)策略在我們的部署上限制出口到互聯(lián)網(wǎng)。在本場景下，這可防止攻擊的后續(xù)階段，并且與攻擊者控制的資源網(wǎng)絡(luò)連接會斷開。

我們所有面向外部的服務(wù)都受到Cloudflare的保護(hù)。這些服務(wù)的源服務(wù)器是通過Authenticated Origin Pulls設(shè)置。這意味著，這些服務(wù)器均未直接暴露于互聯(lián)網(wǎng)。

2.使用Cloudflare保護(hù)Cloudflare

我們的所有內(nèi)部服務(wù)都受到我們的Zero-trust產(chǎn)品Cloudflare Access的保護(hù)。因此，一旦我們修補(bǔ)了我們所識別到的有限攻擊面，對Cloudflare系統(tǒng)或利用Access的客戶進(jìn)行任何漏洞利用企圖，都將需要攻擊者進(jìn)行身份驗(yàn)證。

由于我們部署了Cloudflare WAF產(chǎn)品，作為使用Cloudflare保護(hù)Cloudflare的工作的一部分，我們也受益于為保護(hù)客戶所做的所有工作。為防護(hù)該漏洞而編寫的所有新WAF規(guī)則已使用默認(rèn)操作BLOCK進(jìn)行了更新。就像部署了WAF的其他所有客戶一樣，我們現(xiàn)在無需采取任何行動也受到保護(hù)。

總結(jié)

隨著我們繼續(xù)應(yīng)對這一帶有挑戰(zhàn)性的情況，我們希望此保護(hù)說明能夠幫助大家防御漏洞。對于我們從Cloudflare內(nèi)部和外部獲得的所有支持，我們深表感激。

Evan Johnson、Anjum Ahuja、Sourov Zaman、David Haynes和Jackie Keith也為本博客做出了貢獻(xiàn)，謝謝你們！