.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
SugarCRM 零日身份驗證繞過和遠程代碼執行漏洞（CVE-2023-22952）像是一個典型的漏洞。因為它是一個web應用程序，如果沒有正確配置或保護，幕後的基礎設施可以允許攻擊者增加其影響。當攻擊者了解雲服務提供商使用的底層技術時，如果他們能夠獲得對具有正確權限的憑證的訪問權限，就可以進行大量的操作。
在過去的一年中，Unit 42發現SugarCRM漏洞CVE-2023-22952是一個初始攻擊向量，允許攻擊者訪問AWS賬戶。這不是由於AWS中的漏洞造成的，它可能發生在任何云環境中。初始攻擊後，攻擊者利用錯誤的配置擴大了他們的訪問權限。
本文根據MITRE ATTCK Matrix框架列出了針對AWS環境的各種攻擊，並總結了組織可以設置的多種預防機制來保護自己。其中一些保護措施包括利用AWS提供的控制和服務、雲最佳實踐，以及確保足夠的數據保留以應對全面攻擊。
這些攻擊的複雜性表明，設置日誌記錄和監控以檢測任何未經授權的AWS API調用是多麼重要，即使它們看起來無害。如果允許攻擊者獲得一個攻擊立足點，這可能導致更可怕的活動，而這些活動並不總是可追踪的。
MITRE ATTCK MatrixMITRE ATTCK Matrix由14種不同的策略組成，這些策略描述了網絡安全攻擊的不同組成部分。
初始訪問：CVE-2023-22952這些AWS賬戶洩露的最初攻擊載體是零日SugarCRM漏洞CVE-2023-22952。 Sugar是一個價格合理並且容易使用的企業級CRM，Sugar的設計初衷是為了幫助您的企業於千載客戶溝通，共享銷售信息，促成交易以及保持客戶開心。
CVE-2023-22952由NIST國家漏洞數據庫於2023年1月11日發布，得分為8.8。由於缺少輸入驗證，此漏洞允許攻擊者通過SugarCRM電子郵件模板模塊注入自定義PHP代碼。
要理解攻擊者為什麼針對SugarCRM進行這些攻擊，了解SugarCRM客戶數據庫中存在大量敏感數據（如電子郵件地址、聯繫信息和帳戶信息）是很有幫助的。如果它被洩露，攻擊者要么選擇直接出售這些信息，要么勒索受害者以獲得更多經濟利益。
通過利用SugarCRM中的此漏洞，攻擊者可以通過該漏洞的遠程執行組件直接訪問運行此應用程序的底層服務器。在發現的示例中，這些服務器是Amazon Elastic Cloud Compute (EC2)實例，主機上存儲有長期的AWS訪問密鑰，允許攻擊者擴展其訪問權限。由於這些組織將其基礎設施託管在雲中，因此與本地託管相比，它為攻擊者提供了不同的攻擊載體。
憑證訪問一旦攻擊者獲得了對EC2實例的訪問權限，他們就成功地盜取了主機上存在的長期AWS訪問密鑰。無論計算機是位於本地還是雲中，如果用戶使用AWS命令行界面（CLI），他們都可以選擇將用於身份驗證的臨時或永久憑證存儲在存儲在主機上的憑證文件中，具體如下圖所示，其中包括文件路徑。
在我們觀察到的情況下，這些明文憑證存在於受攻擊的主機上，這允許攻擊者竊取它們並開始使用訪問密鑰開始攻擊活動。
憑證文件位置的文件路徑
發現過程在攻擊者執行任何掃描活動之前，他們首先運行命令GetCallerIdentity。 GetCallerIdentity是AWS版本的whoami。它返回關於執行調用目標的各種信息，例如與用於簽署請求的憑證相關聯的
的用戶ID、帳戶和Amazon Resource Name (ARN)，如下圖所示。用戶ID是執行調用的實體的唯一標識符，帳戶是憑證所屬的AWS帳戶的唯一12位標識符，ARN包括執行調用的目標帳戶ID和人類可讀的名稱。
GetCallerIdentity響應
一旦攻擊者竊取了足夠多的憑證，他們就開始了掃描活動。他們利用Pacu和Scout Suite工具來更好地了解AWS賬戶中存在哪些資源。 Pacu是一個開源的AWS開發框架，它被設計成雲中的Metasploit。 Scout Suite是一個用於雲環境安全狀態評估的安全審計工具。
根據檢測結果，Pacu已經存在於主機上。雖然Scout Suite並不是我們看到下載到受感染的EC2實例上的工具，但我們知道它是基於與攻擊者活動相關的用戶代理使用的。這兩種工具都為攻擊者提供了大量信息，以了解他們所破壞的AWS賬戶的情況。
在本文的示例中，這些工具掃描了各種傳統服務，例如：
EC2
IAM
RDS
S3
SNS
SES
Lambda
攻擊者還對服務(例如Organizations服務和Cost and Usage服務)執行其他發現調用，這些服務不一定會為攻擊者提供有用的信息。
AWS組織為公司提供了一個集中的場所來管理多個AWS帳戶和資源。在查看CloudTrail日誌中的攻擊者活動時，有三個組織API調用非常突出。第一個調用是ListOrganizationalUnitsForParent，它列出了所有的組織單元(OU)。
這樣，攻擊者就可以運行ListAccounts，它返回與每個ou關聯的所有帳戶id，並向攻擊者提供最有用信息的最後一個調用是descripbeorganization API調用。此事件返回主帳戶ID以及與該帳戶關聯的主帳戶電子郵件地址。有了這些信息，攻擊者就有足夠的能力嘗試以Root用戶的身份登錄目標帳戶。最後一個感興趣的發現調用涉及成本和使用服務。如下圖所示，攻擊者執行各種GetCostandUsage調用，響應返回關於受攻擊帳戶中的一般成本的信息。
防御者需要意識到，攻擊者可以通過了解雲帳戶內的成本來確定帳戶的活躍程度。如果一個帳戶的總成本很大，他們可能更容易在不被發現的情況下增加新資源，因為成本可能不會突出。
另一方面，如果帳戶中的支出很少，一些新資源可能會更加突出。支出較少的帳戶所有者可能也有更嚴格的成本通知，這可能會在攻擊者創建新資源時觸發警報。
GetCostandUsage請求參數示例
GetCostandUsage響應示例
通過使用這些看似無害的API調用，攻擊者獲得了大量關於賬戶結構和使用情況的信息，而無需執行大量可能觸發警報的可疑活動。
橫向移動、執行、滲透在我們觀察到的事件中，一旦攻擊者完成了對環境的掃描，他們就有足夠的信息來縮小他們的活動範圍，從發現整個帳戶到對從關係數據庫服務(RDS)開始的各種服務採取行動。攻擊者從受攻擊的SugarCRM EC2實例橫向移動到RDS服務，並開始執行命令，從各種SugarCRM RDS數據庫創建新的RDS快照。創建這些快照不會導致原始RDS數據庫停機。
這樣，攻擊者就修改了已經允許SSH入站的預先存在的安全組規則，並為MySQL流量添加了端口3306。然後，攻擊者開始進行滲透，從快照中創建全新的數據庫，將其公開，並附加修改後的安全組。最後，他們通過更改主用戶密碼修改了新創建的RDS數據庫，這將允許他們登錄數據庫。
為了了解是否發生了任何數據洩露，在啟用了虛擬私有云(VPC)流日誌的情況下，我們可以使用日誌查看有多少字節的數據離開了環境。在沒有啟用VPC流日誌的情況下，我們發現的數據洩露受到限制。
橫向移動/執行在RDS活動之後，攻擊者再次橫向移動回EC2服務並進行了一些更改。攻擊者做的第一件事是從正在運行的SugarCRM EC2實例中創建新的Amazon Machine Images（AMI），然後從那裡運行ImportKeyPair命令導入他們使用第三方工具創建的公鑰對。完成這些任務後，攻擊者繼續創建新的EC2實例。攻擊者還將現有的安全組附加到允許從任何IP地址訪問入站端口22的EC2實例，如下圖所示。
允許端口22訪問的安全組示例
攻擊者在組織用於其正常基礎設施的其餘部分的相同區域中創建了EC2實例。他們還將區域切換到地理上的新區域，並創建了一個新的安全組，允許來自任何IP地址的端口22 SSH流量。然後，攻擊者導入另一個密鑰對。由於攻擊者切換到不同的區域，即使密鑰對與其他區域使用的密鑰對相同，也必須重新導入該密鑰對。
完成設置後，攻擊者們創建了一個新的EC2實例，但這次他們使用了AWS Marketplace上的公共AMI。此EC2實例活動顯示了在所有區域啟用GuardDuty等安全服務的重要性，以便能夠查看AWS帳戶內發生的所有事情。為了增加主動防禦，組織也可以禁用未使用的區域。
權限升級對於這些攻擊的權限升級部分，攻擊者並沒有像我們在其他情況下看到的那樣試圖創建新的IAM用戶。相反，他們選擇嘗試以Root用戶身份登錄。儘管使用了他們在發現階段從組織調用中獲得的信息，攻擊者仍然未能成功地以Root用戶登錄。 Root登錄嘗試非常嘈雜，因此這些失敗的Root登錄在CloudTrail日誌中非常突出，如下圖所示。
從CloudTrail日誌中查看Root登錄失敗
持久性除了嘗試使用Root帳戶登錄之外，攻擊者並沒有嘗試太多持久性。最明顯的持久性嘗試是在不同的區域創建EC2實例，而不是通常用於託管其基礎設施的組織。與Root登錄嘗試類似，這些新的EC2實例在CloudTrail日誌中很突出。然而，在檢查控制台中的資源時很容易遺漏一些內容，因為隨著雲環境變得更大，切換區域和跟踪所有創建的資源非常耗時。
逃避檢測一旦攻擊者攻擊了AWS賬戶，在賬戶所有者發現問題之前，他們只有有限的時間來逃避。為了不被發現，攻擊者在非標準地區部署了資源。但是，他們還在環境中打開和關閉了EC2實例。
攻擊者這樣做有幾個原因。第一個原因是降低他們的可見度。在AWS控制台中EC2實例頁面上，它默認只顯示正在運行的EC2實例。除非用戶積極地嘗試查看未運行的EC2實例，否則，一旦將攻擊者創建的新EC2實例處於停止狀態，用戶就不可能檢測到他們。
第二個原因是，停止這些資源也可以避免在組織帳戶中產生額外的成本。如果組織對成本有嚴格的通知，攻擊者停止他們創建的資源可以最大限度地降低成本，並有助於防止觸發成本警報，這是他們逃避檢測的另一種方式。除了在不同區域創建資源並停止他們創建的資源外，攻擊者沒有嘗試其他防禦規避技術，例如停止CloudTrail日誌記錄或禁用GuardDuty。
通過訪問密鑰進行緩解組織可以採取四種主要的補救措施來保護自己在未來免受這類型的攻擊。第一個是關於訪問密鑰的，對於組織來說，保護他們的訪問密鑰是至關重要的，因為我們經常看到它們是AWS被攻擊的根本原因。
在EC2實例上使用長期訪問密鑰從來都不是一個好的理由。相反，應該使用實例元數據服務(IMDS)中的EC2角色和臨時憑證。另外，請確保只使用IMDSv2，它可以防止服務器端請求偽造(SSRF)攻擊。
我們建議為存儲在主機憑證文件中的任何長期訪問密鑰創建一個清理過程。這可以通過要求用戶在完成工作後清理這些文件來實現，或者通過創建一個流程來自動清理這些文件。
我們還建議定期輪換和刪除訪問密鑰。訪問密鑰的壽命越長，它被洩露的可能性就越大。持續地輪換它們並主動刪除未使用的密鑰可以保護AWS帳戶。整個過程可以自動化，並有助於檢查訪問密鑰的安全性。
最低權限IAM策略攻擊者能夠完成攻擊唯一原因是，組織在SugarCRM主機上給予IAM用戶主體廣泛的權限。這些主機上的IAM用戶需要一些AWS權限，但是這些權限應該被限定得很窄，只包括使用這些權限的應用程序所需要的權限。這些組織並不是唯一遇到這種情況的組織，99%的雲用戶、角色、服務和資源被授予了過多的權限，而這些權限沒有被使用。
建議組織可以使用AWS Access Analyzer檢查特定IAM主體對API的歷史使用情況，並自動生成訪問策略，將其訪問權限限制為僅在你選擇的時間段內使用過的API。
編寫過於寬鬆的策略可能更容易，但是編寫範圍狹窄的權限以更好地保護AWS帳戶肯定是值得的。
通過監控Root進行緩解還有一個預防措施是圍繞Root帳戶設置監控，此帳戶應該只用於需要Root的幾個帳戶管理任務的環境中，並進行精心維護。我們還建議始終在Root上啟用多因素身份驗證，並確保使用長密碼對其進行保護。
日誌記錄和監控最後一項防禦措施是確保它們配置了正確的日誌記錄。 CloudTrail和GuardDuty都應該在所有區域中啟用，並將日誌發送到集中位置。
當涉及到GuardDuty時，攻擊警報應該被發送到一個團隊，該團隊將根據警報的嚴重性做出響應。在本文的示例中，組織啟用了GuardDuty，我們看到GuardDuty在攻擊的早期就發現了這些訪問密鑰洩露。
我們還建議組織啟用VPC流量日誌，以幫助捕獲可能發生的任何數據洩露。這些日誌在解決網絡連接問題時非常有用。對於所有這些不同的服務，確保保留好操作記錄是很重要的。無論環境如何，任何地方都可能發生攻擊，確保日誌保留足夠長的時間對於捕獲完整的攻擊至關重要。
總結儘管攻擊者能夠在這些攻擊中完成很多任務，但我們發現組織可以採取一些很好的補救措施來更好地保護自己。由於訪問密鑰是最常見的初始攻擊向量，因此盡可能避免使用長期訪問密鑰。在AWS中，這意味著為開發人員工作站使用EC2角色、IAM Roles Anywhere或Identity Center集成。保護這些密鑰的另一個方式是設置異常使用監控。對於這些攻擊，攻擊者執行異常API調用，這些調用都可以通過日誌分析檢測到。
還必須進行基本的最低權限分析，以便在雲內部或外部運行的代碼只具有完成其工作所需的權限。
除了監控訪問密鑰外，還需要確保監控雲帳戶的異常活動。在AWS中，這看起來像是監控各種服務，如CloudTrail、VPC流程日誌和S3服務器訪問日誌。如果你的雲帳戶中的服務正在通過異常端口訪問新的和不尋常的IP地址，則需要確保監控配置可以發出警報。此外，如果組織在S3桶中有敏感數據，則監控S3服務器訪問日誌以記錄對存儲桶的異常調用有助於主動發現攻擊。