原文鏈接： When a Zero Day and Access Keys Collide in the Cloud: Responding to the SugarCRM Zero-Day Vulnerability
譯者：知道創宇404實驗室翻譯組

摘要

本文討論了SugarCRM 0-day漏洞（CVE-2023-22952）的認證如何繞過遠程代碼執行，并總結出了防御者們應該注意的事項。由于該漏洞是一個Web應用程序，如果沒有進行正確配置或保護，一旦黑客了解了云服務提供商使用的基礎技術，并獲取了適當權限，可能會引發多次安全事件。

在過去的一年中，Unit 42響應了多起案例，其中 SugarCRM 漏洞 （CVE-2023-22952） 是主要的初始攻擊媒介，其允許黑客訪問AWS 賬戶。但這并不是因為AWS的漏洞，任何云環境都可能發生這種情況。相反，黑客后期利用錯誤配置來擴大他們的訪問權限。

本文參考 MITRE ATT&CK 框架對AWS環境遇到的各種攻擊事件進行分析，并總結了各個組織可以來保護自己的多種預防保護機制。這些保護措施包括利用AWS提供的控制和服務、云最佳實踐以及足夠多的數據來捕獲完整的攻擊過程。

這些攻擊的復雜性更加表明了設置日志記錄和監控對于檢測未經授權的AWS API調用的重要性。一旦黑客得以立足，那么可能會導致更加嚴重的威脅行為，而這些行為是不可被追溯的。云安全保護并非一刀切，這些攻擊暴露了需要重點關注的領域，而這樣也可以讓我們在面對攻擊時能做出更充分的準備。

MITRE ATT&CK 框架

本次事件中采用 MITRE ATT&CK 框架，該框架矩陣由十四個不同的戰術組成，以此描述了網絡安全攻擊的各個組成部分。在我們應對的各種案例中，其中有九個戰術描述了黑客的活動。這九個是初始訪問、憑證獲取、發現、橫向移動、執行、數據外泄、權限提升、持久化和防御規避。

事件概覽

CVE-2023-22952 初次訪問

這些AWS賬戶遭到入侵的初始攻擊媒介是0-day SugarCRM漏洞 CVE-2023-22952，SugarCRM是一個專注于跨團隊協作的客戶關系管理平臺，其應用較廣泛。

CVE-2023-22952于2023年1月11日被NIST國家漏洞數據庫發布，基礎評分為8.8。由于缺少輸入驗證，這個漏洞允許黑客通過SugarCRM 電子郵件模板注入自定義的PHP代碼。

要了解黑客為何將SugarCRM作為攻擊的目標，重點了解SugarCRM客戶數據庫中存在的大量敏感數據(如電子郵件地址、通信地址和帳戶信息)是很有幫助的。如果這些數據被泄露，黑客要么會選擇直接出售這些信息，要么會敲詐受害者以獲得更多的錢。

通過利用SugarCRM中的這個漏洞，黑客可以通過遠程執行組件直接訪問運行該應用程序的底層服務器。在我們響應的案例中，這些服務器是Amazon彈性云計算(EC2)實例，具有存儲在主機上的長期AWS訪問密鑰，黑客能夠擴大他們的訪問權限的作用。由于這些組織將他們的基礎架構托管在云端，與本地托管相比，黑客會面臨不同的攻擊向量。

訪問憑證

一旦黑客獲取EC2實例的訪問權限，他們就成功地破壞了存儲在主機上的AWS長期訪問密鑰。無論計算機部署在本地上還是云上，如果用戶使用AWS命令行界面（CLI），他們可以選擇將用于進行身份驗證的憑據存儲在主機的存儲憑據文件中(如下面的圖1所示，其中包括文件路徑)。

在我們觀察的案例中，這些明文憑據存儲在被入侵的主機上，使得黑客能夠竊取這些憑據并開始使用訪問密鑰進行訪問活動。

圖1:憑據文件的位置路徑

發現

在黑客執行任何掃描活動前，首先會運行GetCallerIdentity命令。GetCallerIdentity是AWS版本的whoami命令，它返回有關執行調用實體的各種信息，如用戶ID、賬戶、亞馬遜資源名稱(ARN)和用于簽署請求憑證相關的主體，如圖2所示。用戶ID是執行調用的唯一實體標識符，賬戶憑證是12位數字標識符，ARN包括執行調用主體的賬戶ID和可讀的名稱。

圖2:GetCallerIdentity命令的響應示例

在黑客對泄露的憑據有了更多的了解后，他們就會開始進行掃描活動。主要利用Pacu和Scout Suite這兩個工具來了解AWS客戶中存在哪些資源，Pacu是一個開源的AWS滲透測試框架，旨在成為云上Metasploit的等效工具。Scout Suite則是一種安全審計工具，主要用于云環境安全狀況評估。

在所響應的一些案例中，我們看到Pacu已經存在于之前用于滲透測試主機上。至于Scout Suite，我們沒有看到它被下載到被入侵的EC2實例中，但根據黑客活動相關的用戶代理，我們知道它被使用了。這兩個工具都為黑客提供了大量信息，以便他們了解他們所入侵的AWS賬戶的情況。

這些案例中，這些工具掃描了各種傳統服務，例如：

黑客還對其他服務執行了發現調用，這些服務可能并不需要向攻擊者提供有用的信息，如組織服務（Organizations service）和成本用途服務（Cost and Usage service）。

AWS Organizations為公司提供了集中管理多個AWS帳戶和資源的場所。在查看CloudTrail日志中的黑客活動時，有三個Organizations API調用引起了注意。第一個調用是ListOrganizationalUnitsForParent，它列出了所有的組織單元（OUs）。

在此之后，黑客運行了ListAccountsAPI調用，該調用返回與每個OU關聯的所有賬戶ID。提供給黑客最有用信息的最后一個調用是DescribeOrganization API調用。該事件返回了主賬戶ID以及與該賬戶關聯的主賬戶電子郵件地址。通過這些信息，黑客有足夠的理由嘗試以Root用戶身份登錄該賬戶。

最后一個有趣的發現是調用涉及到成本和使用情況服務（Cost and Usage service）。黑客執行了各種GetCostandUsage調用，并且響應返回了受攻擊賬戶內的一般成本信息。

防御者需要意識到黑客可以通過了解云賬戶中的費用情況來判斷賬戶的活躍程度。如果一個開戶的總費用較高，那么對于黑客來說，在未被察覺的情況下創建新的資源可能更容易，因為這樣的費用可能不會引起過多的關注。

另一方面，如果一個賬戶的開支很少，那么幾個新資源可能會更加顯眼。支出較少的賬戶所有者可能對費用情況有更嚴格的通知設置，這可能在黑客創建新資源時觸發警報。

圖3：GetCostandUsage 請求參數示例

圖4：GetCostandUsage 響應示例

組織（Organizations）和成本和使用情況（Cost and Usage）API調用都是展示云環境中攻擊面的好例子。通過使用這些看似無害的API調用，黑客獲得了大量關于賬戶結構和使用情況的信息，而無需執行過多可能觸發警報的可疑活動。

RDS 橫向移動、執行、滲透

在我們觀察到的事件中，一旦黑客完成對環境的掃描，就有足夠的信息來縮小他們的活動范圍，從發現整個帳戶到對從關系數據庫服務(RDS)。黑客通過遠程桌面服務遷移到受損的SugarCRM EC2實例，然后開始執行命令，從各個SugarCRM RDS數據庫創建新的RDS快照。這些快照的創建不會導致原始RDS數據庫的停機。

根據提供的信息，攻擊者通過修改已經允許SSH入站流量的安全組規則，并為MySQL流量添加了端口3306。然后黑客開始進行數據外泄，從快照創建全新的數據庫，將它們公開并附加修改后的安全組。最后修改了新創建的RDS數據庫的主用戶密碼，以便能夠登錄到這些數據庫中。

為了確定是否發生了數據外泄，在啟用了虛擬私有云（Virtual Private Cloud，VPC）流日志的情況下，我們可以使用日志來查看有多少字節的數據離開了環境。對于沒有啟用VPC流日志的情況，我們在發現數據外泄方面有限。

EC2橫向移動、執行

在攻擊者完成RDS活動后，他們再次橫向移動回到EC2服務并進行了一些更改。黑客首先創建了正在運行的SugarCRM EC2實例的新的Amazon Machine Images (AMIs)，然后使用第三方工具創建的公鑰對已運行ImportKeyPair命令的導入公鑰對。完成這些任務后，黑客會繼續創建新的EC2實例，并將現有的安全組附加到EC2實例上，允許來自任意IP地址的入站22端口訪問。

圖5：允許端口22訪問的安全組示例

黑客在組織用于正常基礎設施相同的區域中創建EC2實例。他們還切換到另一個新的地理區域，并創建了一個新的安全組，允許來自任意IP地址的22端口SSH流量。隨后，黑客導入了另一個密鑰對。由于黑客切換到了不同的區域，即使是相同的密鑰對也必須重新導入。

設置完成后，他們創建了一個新的EC2實例，但這次他們使用了AWS Marketplace上提供的公共AMI。這個EC2實例的活動顯示了所有地區啟用安全服務(如GuardDuty)的重要性，以便對AWS賬戶中發生的一切有所了解。作為一種主動措施，組織還可以禁用未使用的區域。

提權Root

在這種攻擊中，黑客并沒有嘗試創建新的IAM用戶，而是選擇嘗試以Root用戶身份登錄。盡管他們利用了在發現階段獲取的組織通話的信息，但黑客仍然無法以Root用戶身份登錄。Root登錄嘗試會有較大的動靜，所以在CloudTrail日志中很容易被察覺，如圖6所示。

圖6：CloudTrail日志中失敗的Root登錄示例

區域的持久性

除了嘗試使用Root賬號登錄之外，黑客在持久性方面并沒有做太多嘗試。最明顯的嘗試是在不同的區域創建EC2實例，而不是在組織通中來托管其基礎設施的區域。與Root登錄嘗試類似，這些新的EC2實例也在CloudTrail日志中會非常突出。然而，在審核控制臺中的資源時可能會錯過一些東西，因為隨著云環境變得越來越大，切換區域并跟蹤所有創建的資源是相當繁瑣的工作。

防御規避

一旦黑客入侵AWS賬戶后，在賬戶所有者發現問題之前，他們有短暫的時間進行攻擊。為了不被發現，黑客在非標準區域部署資源，并在一段時間內在環境中反復重啟EC2實例。

黑客選擇這樣做可能有以下有幾個原因：第一個是降低他們的知名度。在AWS控制臺的EC2實例頁面上，默認情況下僅顯示運行EC2實例。除非用戶主動嘗試查看未運行的EC2實例，否則當黑客創建的新EC2實例被置于停止狀態，它們將會被遺漏。

其次，停止這些資源還可以避免在組織賬戶中產生額外的費用。如果組織對費用設置了嚴格的通知機制，黑客停止他們創建的資源可以最大限度地降低成本，有助于防止觸發成本警報，這也是他們逃避防御的另一種方式。

除了在不同區域創建資源和停止所創建的資源之外，黑客暫未嘗試其他防御逃避技術，如停止CloudTrail日志記錄或禁用GuardDuty。

補救

訪問鍵

組織可以采取以下四個補救措施來保護自己免受此類攻擊。首先，關注訪問密鑰的安全。保護訪問密鑰非常重要，因為我們經常看到它們成為AWS被入侵的根本原因。

在EC2實例上使用長期訪問密鑰沒有任何好處。相反使用EC2角色和實例元數據服務（IMDS）中提供的臨時憑證，還要確保只使用IMDSv2，這樣它可以防止服務器端請求偽造（SSRF）攻擊。

我們建議為存儲在主機上憑據文件中的任何長期訪問密鑰都創建一個清理過程。這可以通過要求用戶在完成工作后清理這些文件，或者通過創建一個組織級別的流程來自動清理這些文件。

我們還建議按計劃定期輪換和刪除訪問密鑰。訪問密鑰存在的時間越長，被攻擊的風險就越大。定期輪換并刪除未使用的密鑰可以主動保護AWS賬戶。整個過程可以自動化，也有助于檢查確保訪問密鑰的安全性。

Least-Privileged IAM Policies

最低特權IAM策略

這些威黑客能夠完成他們在這些攻擊中所做一切的唯一原因是組織在SugarCRM主機上給予IAM用戶主體廣泛權限。主機上的這些IAM用戶確實需要一些AWS權限，但這些權限應該被嚴格限制到僅包括使用應用程序所需的準確權限。根據云安全威脅報告第6卷顯示：這些組織并不少——99%的云用戶、角色、服務和資源被授予了過多的權限，并且這些權限是閑置的。

可以使用AWS Access Analyzer來檢查特定IAM主體對API的歷史使用情況，并自動生成一個訪問策略，限制其只能訪問在您選擇的時間段內使用過的API。

編寫過于寬松的策略可能更容易，但為了更好地保護您的AWS帳戶，編寫狹窄范圍的權限無疑是值得的。

監控 Root

另一個我們建議這些組織采取的糾正措施是對Root賬戶進行監控。Root賬戶應該僅用于執行需要Root權限的一些賬戶管理任務，這樣它將此作為高保真警報來維護，其有助于保護最有價值的賬戶。我們還建議始終對Root啟用多因素身份驗證，并確保它受到長密碼的保護。

記錄和監控

我們建議這些組織采取的最后補救措施是確保他們配置了正確的日志記錄。在所有區域內啟用CloudTrail和GuardDuty，并將日志發送到一個集中的位置。

當涉及到GuardDuty時，警報應該發送給一個應急團隊。在我們觀察到已經啟用了GuardDuty的組織中，GuardDuty在攻擊的前期就成功地捕獲到了這些訪問密鑰的漏洞，而這也是保護賬戶的最簡單的辦法。

我們還建議組織啟用VPC流日志來幫助捕捉任何可能發生的數據泄漏。這些日志在排除網絡連接時非常用。對于不同的服務，確保數據有一個良好的保留期非常重要。無論環境如何，任何地方都可能發生危害，確保日志保留足夠長的時間以全面應對攻擊至關重要。

結論

盡管黑客能夠在這些攻擊中完成很多任務，但我們看到組織可以采取一些有效的補救措施來更好地保護自己。由于訪問密鑰是最常見的初始攻擊向量，盡可能避免使用長期訪問密鑰是明智的。在AWS中，這意味著使用EC2角色、IAM角色或Identity Center集成。保護這些密鑰的另一層是設置監控異常使用情況。在這些攻擊中，黑客執行了異常的API調用，這些都可以通過長尾日志分析檢測出來。

此外，進行基本的最小特權分析非常重要，以確保在云內外運行的代碼僅具有其所需的權限。

除了監控訪問密鑰外，始終確保對云賬戶進行異常活動監控也是至關重要的。在AWS中，這可以包括監控各種服務，如CloudTrail、VPC流日志和S3服務器訪問日志。如果云帳戶中的服務正通過異常端口被新的異常IP地址訪問，您需要確保監控配置能夠對此活動進行警報。此外，如果組織在S3存儲桶中有敏感數據，則監控S3服務器訪問日志以記錄對存儲桶的異常調用有助于主動發現攻擊。

最后，黑客能夠在這些情況中取得如此成果的原因之一是缺乏細粒度的權限。如果這些屬于IAM用戶的被破壞的訪問密鑰具有較少的權限，那么就可以阻止黑客的蹤跡。

Iocs

IPs:

User Agents:

  • Boto3/1.26.45 Python/3.9.2 Linux/6.0.0-2parrot1-amd64 Botocore/1.29.45

  • Boto3/1.7.61 Python/3.5.0 Windows/ Botocore/1.10.62

  • aws-cli/1.19.1 Python/3.9.2 Linux/6.0.0-2parrot1-amd64 botocore/1.29.58

  • aws-cli/1.18.69 Python/3.5.2 Linux/4.4.0-1128-aws botocore/1.16.19

  • Scout Suite/5.12.0 Python/3.9.2 Linux/6.0.0-2parrot1-amd64 Scout Suite/5.12.0

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/3006/