當 Cloudflare 知曉發生新的安全性漏洞時，我們快速將團隊集合起來回答二個不同問題：(1) 我們可以做什麼以確保我們客戶的基礎結構受到保護，以及 (2) 我們可以做什麼以確保我們自身環境安全。昨天，也就是 2021 年 12 月 9 日，當基於 Java 常用記錄套件 Log4j 公開披露時，我們的安全團隊付諸行動，協助回應第一個問題和回答第二個問題。本貼文探索第二個問題。
我們在單獨的部落格貼文中詳述此漏洞的作用方式：Log4j2 漏洞 (CVE-2021-44228) 內部，總的來說，此漏洞允許攻擊者在遠端伺服器上執行代碼。由於 Java 和 Log4j 的廣泛使用，這可能是網際網路上自 Heartbleed 和 ShellShock 以來最嚴重的漏洞之一。漏洞列為 CVE-2021-44228。CVE 說明描述了漏洞影響 Log4j2 <=2.14.1 並在 2.15 獲得修補。漏洞還影響所有版本的 log4j 1.x。然而，該版本的生命週期已結束，而且有其他不會修復的安全漏洞。建議升級到 2.15。您也可以參閱本貼文中有關我們如何更新 WAF 規則以協助保護客戶的資訊：CVE-2021-44228 - Log4j RCE 0 天緩解
時間表
每次我們回應事件時，最先做的一件事就是繪製我們在情境中需要檢閱和瞭解的事件時間軸。在本次事件中，部分時間軸範例包括：
2021-12-09 16:57 UTC - 收到 developers.cloudflare.com 上有關 Log4j RCE 的 Hackerone 報告
2021-12-10 09:56 UTC - 第一個 WAF 規則傳輸到 Cloudflare Specials 規則集
2021-12-10 10:00 UTC - 開啟正式的工程「事件」並開始識別我們需要修補 Log4j 的區域
2021-12-10 10:33 UTC - Logstash 部署修補程式以緩解漏洞。
2021-12-10 10:44 UTC - 第二個 WAF 規則上線，作為 Cloudflare 受管理規則的一部份
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 報告無法複製後，以「資訊」的狀態關閉
解決內部影響
處理任何軟體漏洞時都有一個重要的問題，這實際上可能是每家公司需要回答的最困難的問題，在本次特定事件中，這個問題是：易受攻擊的軟體實際上都在什麼地方執行？
如果漏洞位於某家公司授權給全球其他人使用的軟體的專有部份內，那很容易回答，只要找到該軟體的該部份即可。但在本次事件中要困難得多。Log4j 是軟體中一個廣泛使用的部份，但非 Java 開發人員可能對該部份並不熟悉。我們的第一個動作是重新熟悉我們在 JVM 上執行軟體所在的基礎結構中的所有位置，以便判斷哪些軟體元件可能容易受到此問題的攻擊。
我們可以使用我們集中的代碼存放庫，建立在 JVM 上執行的所有軟體的詳細目錄。我們使用這些資訊研究和判斷我們所擁有的每一個獨立的 Java 應用程式，無論其是否包含 Log4j，以及無論其中編譯了哪個版本的 Log4j。
Wikipedia我們發現我們的 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 組態中設定緩解系統屬性：
log4j2.formatMsgNoLookups
我們可以等待發佈新版本套件期間，使用這些策略快速緩解這些套件中的這一問題。
檢閱外部報告
在我們完成製作易受攻擊軟體所執行之內部位置的清單前，我們就已從來自 HackerOne 的外部報告、我們的漏洞報告獎勵計劃和 GitHub 中的公開貼文中獲知，我們可能面臨風險。
我們找到至少兩份報告可能表明 Cloudflare 易受攻擊並己遭到入侵。其中一份報告即以下的螢幕擷取畫面：
此範例的目標是在 https://developer.cloudflare.com 中託管的開發人員說明文件。在右側，攻擊者展示收到針對他傳送給我們伺服器的負載的 DNS 查詢。但此處標示的 IP 位址是 173.194.95.134，這是 Google 所擁有的 IPv4 子網路 (173.194.94.0/23) 的成員。
Cloudflare 開發人員說明文件已託管作為一個 Cloudflare Worker 並僅向靜態資產提供服務。存放庫是公用的。如此處所見，Worker 依賴於 Google 的分析程式庫，因此，我們假設攻擊者未收到來自 Cloudflare 但經由 Google 的伺服器的請求。
我們的後端伺服器收到來自 Worker 的記錄，但在此執行個體中也無法進行入侵，因為我們已使用強大的 Kubernetes 輸出原則以防止向外呼叫網際網路。允許的唯一通訊是經過挑選的一組內部服務。
在我們從漏洞披露計畫中收到類似報告，同時收集到更多資訊後，研究人員仍無法重現問題。這進一步強化了我們的假設，即這是第三方伺服器，而且他們已修復了問題。
Cloudflare 是否遭到了入侵？
儘管我們正執行上述版本的軟體，但由於我們的快速回應和縱深防禦方法，我們不認為 Cloudflare 已遭到入侵。我們已作出大量努力來驗證此情況，我們將繼續致力於此，直到已瞭解關於此漏洞的一切為止。以下是我們所做的部份努力。
由於我們正致力於評估和分隔易受攻擊的軟體可能執行的環境並進行修復，我們已開始單獨的工作流來分析是否有任何執行個體已遭到攻擊。我們的偵測和回應方法遵照業界標準的「事件回應」做法並徹底部署，以驗證我們是否有任何資產真的遭到入侵。我們遵照後續方式，多管齊下。
檢閱內部資料
我們的資產詳細目錄和代碼掃描工具讓我們能夠識別依賴 Apache Log4j 的所有應用程式和服務。在視需要檢閱和升級這些應用程式時，我們徹底掃描這些服務和主機。尤其是，CVE-2021-44228 的攻擊依賴於記錄訊息和參數中的特定模式，例如 \$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+，對於每個可能受影響的服務，我們都執行記錄分析來呈現所有攻擊嘗試。
檢閱網路分析
我們的網路分析讓我們能夠找出可能表示嘗試或實際入侵我們基礎結構的可疑網路行為。我們詳閱我們的網路資料以識別以下情況：
可疑的輸入和輸出活動透過分析可疑的輸入和輸出連線，我們可以清理我們的環境，並識別我們的任何系統是否展示出正遭受入侵的跡象。
目標系統和服務透過利用針對我們網路資料的模式分析，我們發現了威脅執行者的目標系統和服務。這使得我們可以針對我們的資產詳細目錄執行相關搜尋，並深入鑽研每個主機以判斷是否有任何機器暴露在漏洞或主動攻擊下。
網路指標從前述的分析中，我們瞭解到不同威脅執行者的基礎結構，並且找出此漏洞的嘗試攻擊所運用的網路指標。到這些指標的輸出活動在 Cloudflare Gateway 中遭到封鎖。
檢閱端點
我們可以關聯我們的記錄分析和網路分析工作流程來補充我們的端點分析。從我們在這些分析的發現結果中，我們可以制訂端點掃描標準，以找出其他可能受影響的系統，並分析個別端點正遭受入侵的跡象。我們運用以下技術：
基於簽章的掃描
我們正在部署自訂 Yara 偵測規則，對漏洞利用發出警示。這些規則將部署在我們的所有基礎結構和集中的安全資訊與事件管理 (SIEM) 工具上執行的端點偵測和回應代理程式中。
異常程序執行和持續分析
Cloudflare 持續收集和分析來自我們基礎結構的端點程序事件。我們運用這些事件搜尋入侵後技術 ，例如第二階段攻擊的下載、異常的子程序等。
使用所有這些方式後，我們未發現有遭到入侵的證據。
第三方風險
在以上的分析中，我們著重檢閱我們自己產生的代碼和資料。但跟大多數的公司一樣，我們也依賴自第三方得到授權的軟體。當我們開始調查此事件時，我們也和公司的資訊技術團隊合作，擬出一份主要的第三方提供者和所有子處理器的名單，以詢問他們是否受到影響。我們正在接收和檢閱來自提供者的回應。任何受此漏洞影響的重要提供者都將停用並予以封鎖，直到完全修復為止。
驗證我們的縱深防禦方法確有成效
在我們對此事件做出回應的過程中，我們發現我們的縱深防禦方法確有成效的幾個方面。
限制輸出流量
限制 Call Home 的能力是_狙殺鏈_一個至關緊要的部份，能夠大幅增加漏洞攻擊難度。如上所述，我們在部署上利用 Kubernetes 網路原則以限制輸出到網際網路。在此環境中，這防止了下一個階段的攻擊，而且到攻擊者所控制資源的網路連線已中斷。
我們所有的對外服務都受到 Cloudflare 的保護。這些服務的原始伺服器都是透過已驗證的原始提取進行設定。這表示不會有任何伺服器直接與網路網路接觸。
2. 運用 Cloudflare 保護 Cloudflare 的安全
我們所有的內部服務都受到我們的 Zero Trust 產品 Cloudflare Access 的保護。因此，我們修補所識別的有限攻擊表面後，任何對使用 Access 的 Cloudflare 系統或客戶的攻擊嘗試都會要求攻擊者進行驗證。
而且，在使用 Cloudflare 保護 Cloudflare 的過程中，我們還部署了 Cloudflare WAF 產品，我們原本進行了諸多工作來保護我們的客戶，而如今，我們也從這些工作中受益。原本編寫用於防禦此漏洞的所有新 WAF 規則都已進行更新，新增了預設動作封鎖。跟每個已部署 WAF 的其他客戶一樣，我們無需再採取任何動作，目前就已受到保護。
結論
我們仍在繼續作出努力以回應此充滿挑戰性的情況，但我們希望本文中概述的現有措施能夠對他人有所幫助。我們感激從 Cloudflare 的內外收到的所有支援。
感謝 Evan Johnson、Anjum Ahuja、Sourov Zaman、David Haynes 和 Jackie Keith 對此部落格做出的貢獻。