使用亞馬遜雲科技安全服務防禦、檢測和響應 Log4j 漏洞

概述

在本文中，我們將為針對最近披露的 Log4j 漏洞所影響的客戶提供一些指導意見。內容包括如何限制漏洞的風險，如何嘗試識別是否易受此問題影響，以及如何使用適當的補丁更新基礎架構。

Log4j 漏洞（CVE-2021-44228、CVE-2021-45046）是無處不在的日誌平臺 Apache Log4j 中的一個關鍵漏洞（CVSS 3.1基本分數為10.0）。此漏洞允許攻擊者在易受攻擊的平臺上執行遠端程式碼。介於版本2.0-beta-9和2.15.0之間的 Log4j 版本2受影響。

該漏洞使用Java命名和目錄介面（JNDI），Java程式使用該介面查詢資料，通常通過目錄查詢資料，在出現此漏洞的情況下通常通過 LDAP 目錄查詢資料。

下面圖1重點介紹了 Log4j JNDI 攻擊流程。

圖1、Log4j 攻擊程式。資料來源：GovCERT.ch，瑞士政府計算機應急響應小組（GovCERT）

本篇內容作為一個即時響應，希望您關注這個設計用於使用任何 Log4j 2.0+ 對正在執行的 JVM 進行熱補丁的工具。亞馬遜雲科技的首席資訊保安官史蒂夫·施密特（Steve Schmidt）也探討了這個熱補丁。

防禦

客戶可以使用多個亞馬遜雲科技提供的服務來幫助限制來自 Log4j 漏洞所帶來的風險/暴露。客戶可以建立分層控制方法，並/或選擇以下確定的控制方法，以幫助限制他們的風險。

Amazon WAF

客戶可以使用 Amazon WAF，遵循其相應的託管規則，以幫助保護其 Amazon CloudFront 分佈、Amazon API Gateway REST API、Amazon ALB 或 Amazon AppSync GraphQL API 資源。

AWSManagedRulesKnownBadInputsRuleSet esp.：Log4JRCE 規則，有助於檢查請求中是否存在Log4j漏洞。示例模式包括${jndi:ldap://example.com/}。
AWSManagedRulesAnonymousIpList esp.：AnonymousIPList 規則，該規則有助於檢查匿名化客戶端資訊的已知源的 IP 地址。
AWSManagedRulesCommonRuleSet esp.：SizeRestrictions_BODY 規則，用於驗證請求正文大小是否最多為8 KB（8192位元組）。

對於使用 Amazon WAF Classic 的客戶，您需要遷移到 Amazon WAF 或建立自定義正規表示式匹配條件。

擁有多個帳戶的客戶可以按照說明使用 Amazon Firewall Manager 跨 Amazon Organization 集中部署 Amazon WAF規則。

Amazon Network Firewall

客戶可以在 Amazon Network Firewall 中使用與 Suricata 相容的 IDS/IPS 規則來部署基於網路的檢測和防護。可從 corelight、NCC Group、ET Labs 和 CrowdStrike 獲得解決 Log4j 的開源 Suricata 規則。這些規則有助於識別 Log4j 漏洞的掃描和攻擊後活動。由於目前存在大量良性掃描，我們建議客戶首先關注潛在的攻擊後活動，例如從其 VPC 向不受信任的網際網路目的地的傳送出站 LDAP 流量。

我們還建議客戶考慮實施出站埠/協議執行規則，以監控或防止諸如 LDAP 之類的例項使用53、80、123和443等非標準 LDAP 埠。對於監控或防止使用埠1389出站，會有助於識別由網際網路掃描器觸發進行出站命令和控制呼叫的系統。我們還建議，對於沒有合法業務需要向網際網路發起網路呼叫的系統，在預設情況下不應被賦予該功能。出站網路流量過濾和監控不僅對 Log4j 非常有用，而且對其他型別的漏洞也非常有用。

使用 IMDSv2

在 log4j 漏洞出現的早期，研究人員注意到，一旦主機受到初始 JDNI 漏洞的危害，攻擊者有時會嘗試從主機獲取憑據，並通過 LDAP、HTTP 或 DNS 查詢等機制傳送這些憑據。我們建議客戶使用 IAM 角色而非使用長期訪問金鑰，並且不要將憑據等敏感資訊儲存在環境變數中。客戶還可以利用 Amazon Secrets Manager 來儲存和自動輪換資料庫憑證，而不是在主機的環境變數中儲存長期資料庫憑證。

為了在可能使用 Amazon EC2 角色時，幫助 Amazon Web Services 防範此類攻擊以及幫助保持所有 IMDS 資料的私密性，客戶應該考慮需要使用例項後設資料服務版本2（IMDSv2）。由於預設情況下啟用了 IMDSv2，因此可以通過禁用 IMDSv1（預設情況下是啟用的）來要求使用IMDSv2。使用 IMDSv2，請求受到初始互動的保護，在初始互動中，呼叫程式必須首先使用 HTTP PUT 獲取會話令牌，而且後續請求必須在 HTTP 頭中包含該令牌。這使得攻擊者更難從 IMDS 獲取憑據或任何其他資料。雖然所有最新的 Amazon SDK 和工具都支援 IMDSv2，但與任何可能非向後相容的更改一樣，在廣泛部署之前，請在代表性系統上測試此更改。

檢測

這篇文章介紹瞭如何潛在地限制攻擊此漏洞的能力。接下來，我們將著重介紹哪些亞馬遜雲科技服務可以幫助檢測您環境中是否存在此漏洞。

Amazon Inspector

如圖2所示，Amazon Inspector 團隊建立了一個覆蓋範圍，用於在Amazon EC2例項和Amazon Elastic Container Registry Images (Amazon ECR)（Amazon ECR）中識別此漏洞的存在。利用新的 Amazon Inspector，掃描是自動化且持續的掃描。持續掃描受釋出的新軟體包、新例項和新的通用漏洞披露（CVE）等事件驅動。

例如，一旦 Inspector 團隊增加了對 Log4j 漏洞的支援（CVE-2021-44228和CVE-2021-45046），Inspector 立即開始在所有受支援的 Amazon Systems Manager 託管例項中查詢此漏洞，其中 Log4j 通過作業系統包管理器安裝，並且此包存在於與 Maven 相容的 Amazon ECR 容器映像中。如果存在此漏洞，將開始顯示發現結果，而無需任何手動操作。如果您使用的是 Inspector Classic，則需要確保針對所有 Amazon EC2 例項執行評估。您可以遵循文件，以確保為所有 Amazon EC2 例項建立評估目標。

GuardDuty

除了通過 Inspector 發現存在此漏洞外，Amazon GuardDuty 團隊還開始新增與攻擊 Log4j 漏洞相關的危害指標，並將繼續這樣做。GuardDuty 將監控試圖訪問已知錯誤IP地址或 DNS 條目的行為，還可以通過基於異常的行為結果來發現攻擊後的活動。例如，如果 Amazon EC2 例項開始在異常埠上通訊，GuardDuty 將檢測此活動並建立查詢行為：EC2/NetworkPortUnusual。不過，此活動並不限於NetworkPortUnusual結果。GuardDuty 有許多與攻擊後活動相關的不同結果，這些結果可能是對受損亞馬遜雲科技資源的響應。

Security Hub

今天，許多客戶還使用與 Inspector 和 GuardDuty 整合的 Amazon Security Hub 聚合警報並啟用自動修復和響應。從短期來看，我們建議您使用 Amazon Security Hub 通過 Amazon Chatbot、Amazon Simple Notification Service 或票務系統設定警報，以便在 Inspector 在您的環境中發現此漏洞時進行檢視。從長遠來看，我們建議您在適當的時候使用安全中心來啟用安全警報的自動修復和響應。這裡是關於如何使用安全中心設定自動修復和響應的一些想法。

VPC flow logs

客戶可以使用 Athena 或 CloudWatch Logs Insights queries 對其 VPC 流量日誌進行查詢，以幫助識別與 log4j 攻擊後出站網路活動相關的 VPC 資源。VPC 流量日誌的 Version 5 特別有用，因為它包含“流向”欄位。我們建議客戶首先特別注意使用目標埠1389的出站網路呼叫，因為該埠的出站使用在合法應用程式中不太常見。客戶還應調查使用目標埠389向不受信任的網際網路目標IP地址傳送的出站網路呼叫。免費套餐IP聲譽服務，如 VirusTotal、GreyNoise、NOC.org 和 pinfo.io，可以提供與記錄的活動中找到的公共 IP 地址相關的有用見解。

注意：如果在查詢的捕獲的 VPC flow logs中有Microsoft Active Directory 環境，則可能會由於使用埠389而出現誤報。

響應

前兩部分討論了幫助防止潛在的攻擊企圖的方法，以及如何檢測存在漏洞和潛在的攻擊企圖。在本部分中，我們將重點介紹您可以採取哪些步驟來緩解此漏洞。正如我們在概述中指出的，建議立即響應部落格，並使用旨在用於使用任何 Log4j 2.0+對正在執行的 JVM 進行熱補丁的工具。亞馬遜雲科技的首席資訊保安官史蒂夫·施密特（Steve Schmidt）也探討了這個熱補丁。

Amazon Patch Manager

如果您使用 Amazon Systems Manager Patch Manager，並且已將關鍵補丁設定為立即安裝在補丁基線中，則您的 Amazon EC2 例項將已經具有該補丁。值得注意的是，這一步您還沒有完成。接下來，您需要在應用程式程式碼中使用庫的任何位置更新類路徑，以確保使用的是最新版本。

容器緩解

為了將概述中提到的熱補丁安裝到 Amazon EKS 叢集工作節點上，亞馬遜雲科技開發了一個執行 JVM 級別熱補丁的 RPM，該熱補丁禁用來自 Log4j2庫的 JNDI 查詢。ApacheLog4J2節點代理是亞馬遜雲科技的 Kubernetes 團隊構建的一個開源專案。

一旦確定，Amazon ECR 容器映像將需要更新以使用 Log4j 2.16.0版本。在下游，您需要確保使用易受攻擊的 Amazon ECR 容器映像構建的所有容器都已更新，以便儘快使用新映像。這可能會有所不同，具體取決於您用於部署這些映像的服務。例如，如果您使用的是 Amazon Elastic Container Service (Amazon ECS),您可能希望更新該服務以強制進行新部署，這將使用新的 Log4j 版本毀壞映像。檢查支援您用於部署容器的方法的文件。

我們建議客戶在打補丁後立即提供新的應用程式憑據並撤銷現有憑據。

無法升級時的緩解策略

如果您無法升級到2.16.0版，該版本預設情況下禁用對 JDNI 的訪問，或者如果您仍在確定為您的環境打補丁的策略，則可以通過更改您的 Log4j 配置來緩解此漏洞。要在>=2.10版本中實施此緩解措施，您需要從 classpath 中刪除 JndiLookup 類：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class