Cloudflare如何安全應對Log4j 2漏洞？

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

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

時間表

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

·2021-12-09 16:57 UTC-收到關于developers.cloudflare.com上的Log4j RCE的Hackerone報告

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

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

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

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

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

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

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

·2021-12-10 21:22 UTC-Hackerone報告在無法復制之后作為有用信息Informative關閉

解決內部影響

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

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

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

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

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

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

log4j2.formatMsgNoLookups

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

審查外部報告

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

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

該示例針對的是在https://developer.cloudflare.com中托管的開發(fā)人員文檔。在右側，攻擊者展示了針對他發(fā)送到我們服務器的有效負載，收到了DNS查詢。但是，此處標記的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的服務器接收。

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

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

Cloudflare是否遭到破壞？

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

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

審查內部數(shù)據(jù)

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

審查網(wǎng)絡分析

利用網(wǎng)絡分析，我們可以識別可疑的網(wǎng)絡行為，這些行為可能表明有人企圖或實際對我們的基礎結構進行漏洞利用。我們仔細檢查了網(wǎng)絡數(shù)據(jù)，識別到以下情況：

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

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

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

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

3.網(wǎng)絡指標

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

審查端點

我們能夠將日志分析和網(wǎng)絡分析工作流程相關聯(lián)，以補充端點分析。從這兩種分析的發(fā)現(xiàn)結果中，我們能夠制定端點掃描標準，以識別任何額外的潛在受影響系統(tǒng)，并分析各個端點，找出正在被破壞的跡象。我們采用了以下方法：

基于簽名的掃描

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

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

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

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

第三方風險

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

驗證我們的縱深防御方法的效果

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

1.限制出站流量

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

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

2.使用Cloudflare保護Cloudflare

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

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

總結

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

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