[[404095]]

Amazon Virtual Private Cloud (Amazon VPC)允許你在已定義的虛擬網(wǎng)絡(luò)內(nèi)啟動AWS資源。這個虛擬網(wǎng)絡(luò)與你在數(shù)據(jù)中心中運行的傳統(tǒng)網(wǎng)絡(luò)極其相似，并會為你提供使用AWS的可擴展基礎(chǔ)設(shè)施的優(yōu)勢。簡單來說，VPC就是一個AWS用來隔離你的網(wǎng)絡(luò)與其他客戶網(wǎng)絡(luò)的虛擬網(wǎng)絡(luò)服務(wù)。在一個VPC里面，用戶的數(shù)據(jù)會邏輯上地與其他AWS租戶分離，用以保障數(shù)據(jù)安全。可以簡單地理解為一個VPC就是一個虛擬的數(shù)據(jù)中心，在這個虛擬數(shù)據(jù)中心內(nèi)我們可以創(chuàng)建不同的子網(wǎng)(公有網(wǎng)絡(luò)和私有網(wǎng)絡(luò))，搭建我們的網(wǎng)頁服務(wù)器、應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器等等服務(wù)。VPC有如下特點：

•  VPC內(nèi)可以創(chuàng)建多個子網(wǎng);
•  可以在選擇的子網(wǎng)上啟動EC2實例;
•  在每一個子網(wǎng)上分配自己規(guī)劃的IP地址;
•  每一個子網(wǎng)配置自己的路由表;
• 創(chuàng)建一個Internet Gateway并且綁定到VPC上，讓EC2實例可以訪問互聯(lián)網(wǎng);
•  VPC對你的AWS資源有更安全的保護;
• ……

AWS VPC努力在整個企業(yè)中識別和檢測攻擊者的技術(shù);在終端、本地和云上，Hunters 團隊研究了一種使用 VPC 功能的技術(shù)，允許客戶控制他們的 IP 地址。攻擊者可以使用它來控制在訪問受感染賬戶時寫入 AWS CloudTrail 日志的 IP 地址。這可能使攻擊者能夠欺騙依賴 Cloudtrail 日志的各種安全保護措施，例如 SIEM 和云安全工具。其中包括但不限于 GuardDuty、Rapid7 和 Lacework。此外，尋找攻擊證據(jù)的分析師可能會忽略它。

這篇文章回顧了混淆處理技術(shù)的技術(shù)細(xì)節(jié)，并提供了可行的措施建議。

攻擊者控制CloudTrail SourceIP

通過控制他們的源 IP 地址，攻擊者可以隱藏起來，從而可能繞過完全依賴于 AWS CloudTrail 的安全措施。

因此，通過使惡意行為看起來好像是由合法對象執(zhí)行的，這就可以使惡意行為看起來是無害的，并且很難檢測攻擊痕跡并將入侵歸因于特定的來源。

如果你的安全工具僅依賴 AWS CloudTrail 日志中的 sourceIP 字段，緩解措施如下。

技術(shù)分析

為了成功執(zhí)行這種技術(shù)，攻擊者需要從受害者賬戶獲得合法 AWS 憑證的訪問權(quán)限，然后創(chuàng)建 VPC 終端，該功能允許你的 VPC 中的 EC2 實例和 AWS 服務(wù)在他們自己的賬戶內(nèi)進行直接通信。創(chuàng)建一個IP范圍的VPC，當(dāng)他們使用被破壞的憑證時，可以混淆他們的流量。以下是我們需要描述的關(guān)鍵功能，以解釋如何使用該技術(shù)：

CloudTrail 日志有一個“sourceIPAddress”字段。該字段包含攻擊者的 IP 地址，在大多數(shù)情況下是公共 IPv4 地址。

但是，如果攻擊者在AWS VPC內(nèi)通過VPC的終端發(fā)出AWS API請求，則CloudTrail日志中登錄的IP地址就是VPC中“內(nèi)部”EC2的IP地址，即攻擊者能夠控制的IP地址。

用戶可以在VPC內(nèi)設(shè)置任意IPv4地址范圍，包括rfc1918地址范圍和可對外路由的IP地址范圍。可公開路由的IP塊只能通過虛擬專用網(wǎng)關(guān)訪問，不能通過Internet網(wǎng)關(guān)訪問。這允許攻擊者創(chuàng)建一個IP尋址方案，模仿受害者自己的網(wǎng)絡(luò)或信譽良好的外部服務(wù)。

另一個重要的事實是，登錄到CloudTrail中的userAgent字段顯示了攻擊者的userAgent字符串，它完全由進行API調(diào)用的攻擊者控制。然而，這并不是該技術(shù)的直接組成部分，當(dāng)使用它時，它可以幫助進一步使模擬過程看起來合法。

在私有 AWS 賬戶(攻擊者賬戶“A”)中創(chuàng)建了一個帶有我們選擇的私有 IP CIDR 塊 (12.34.56.0/24) 的 VPC。

然后，我們在這個 VPC 中創(chuàng)建了一個 EC2 實例，并選擇了它的私有 IPv4 地址為 12.34.56.78。

帶有“外部”私有IPv4地址的攻擊者設(shè)備

我們在受害者的帳戶(“B”)中生成了 API 憑據(jù)，作為在使用該技術(shù)之前被攻擊者破壞的憑據(jù)。

然后，我們在攻擊者 EC2 實例上的 ~/.aws/credentials 文件中配置了這些“被盜”憑證，以便從攻擊者控制的賬戶 A 中的實例發(fā)出的 AWS CLI 調(diào)用將使用它們。

接下來，我們在攻擊者帳戶中為我們打算進行 API 調(diào)用的服務(wù)創(chuàng)建了 VPC 終端。

我們從可以創(chuàng)建VPC終端的125個AWS服務(wù)中選擇了44個最重要服務(wù)的子集，并且為每個服務(wù)選擇了一個不需要任何特定參數(shù)的API調(diào)用。

為了驗證該技術(shù)，我們進行了測試。為了進行比較，我們首先從 EC2 實例對服務(wù)執(zhí)行 API 調(diào)用，而不是通過 VPC 終端進行隧道傳輸。這些調(diào)用以實例的公共 IP 地址作為源 IP 顯示在 CloudTrail 日志中。

在下一步中，我們?yōu)樯鲜龇?wù)創(chuàng)建了 VPC 終端節(jié)點，并在每個服務(wù)中重新運行 AWS CLI 命令，這次是通過 VPC 終端節(jié)點。

測試成功，在 CloudTrail 日志中顯示了攻擊者選擇的“內(nèi)部”IP 地址作為源 IP。

攻擊者可以出于許多不同的目的混淆他們的 IP 地址，以下是一些示例：

1.“組織”公共 IP 地址：如果攻擊者收集有關(guān)受害組織的公共 Internet 基礎(chǔ)設(shè)施的信息，則攻擊者可以使用與其公共基礎(chǔ)設(shè)施的某些部分相對應(yīng)的公共 IP。比如公司的外部 VPN IP 地址。

2.員工“家庭”外部 IP 地址：如果攻擊者獲得有關(guān)員工在離開辦公室時使用的外部 IP 地址的情報，他們可以選擇該 IP，從而錯誤地將任何調(diào)查指向“無辜”員工。比如云 IT 管理員的家庭 IP 地址。

3.第三方服務(wù)提供商的公共IP地址：攻擊者可以在 AWS 客戶環(huán)境中使用屬于第三方服務(wù)提供商的已知公共 IP 地址，從而增加逃避威脅情報和信譽服務(wù)的機會。由于有時這些 IP 可能被 AWS 客戶列入白名單，攻擊者甚至可以執(zhí)行更大量的敏感 API 調(diào)用。

示例 1：使用屬于企業(yè)云安全產(chǎn)品的 IP 地址(最好是受害組織使用的 IP 地址)。

示例 2：使用 198.20.69.74，流行的互聯(lián)網(wǎng)掃描 Shodan 從中掃描整個互聯(lián)網(wǎng)。

4.一個特殊的私有、保留、測試或僅用于文檔的 IPv4 子網(wǎng)塊：有 4-5 個子網(wǎng)被定義為用于臨時目的的“保留 IP”，使用其中一個還可以幫助規(guī)避信譽服務(wù)，完整列表可在此處獲得。

示例：使用 TEST-NET 子網(wǎng)中的 IP 地址(192.0.2.0/24、198.51.100.0/24 或 203.0.113.0/24)。

哪些 AWS 服務(wù)支持 VPC 終端節(jié)點訪問

此技術(shù)只能用于對可以為其創(chuàng)建 VPC 終端節(jié)點的 AWS 服務(wù)進行 API 調(diào)用。但是，截至 2021 年 5 月，可以為 125 種不同的 AWS 服務(wù)創(chuàng)建 VPC 終端節(jié)點，包括大多數(shù)著名的 AWS 服務(wù)(例如 EC2、S3、Lambda、STS、DynamoDB、Secrets Manager 等)，唯一重要的例外是我們已經(jīng)看到是 IAM。

此外，AWS 正在不斷擴展 VPC 終端支持的服務(wù)列表。可以在 AWS 門戶中查看受支持服務(wù)的完整列表。

需要注意的是：

1.該技術(shù)不會影響攻擊者在使用受害者已泄露的 AWS API 憑證時擁有的實際 IAM 權(quán)限，他們只能進行被盜憑證具有 IAM 權(quán)限的 API 調(diào)用。

2.使用此技術(shù)時，攻擊者控制的源 IP 是在 AWS 管理控制臺中查看 CloudTrail 服務(wù)中的 CloudTrail 事件歷史記錄以及 CloudTrail 以 JSON 文件寫入 S3 的事件中記錄的源 IP。

3.僅根據(jù)記錄的 IP 無法將攻擊者識別為組織外部的攻擊者，也無法確定其真實來源。但是，可以確定所涉及的 VPC 不屬于該組織。

這可以用于繞過基于 IP 的 IAM 策略嗎

我們測試了是否可以使用此技術(shù)繞過基于 IAM 源 IP 的策略(使用 aws:SourceIp 密鑰)。該測試假設(shè)，在某些情況下，組織配置此類策略，只允許來自特定子網(wǎng)的某些敏感 AWS 操作。

在這種假設(shè)下，我們測試了在這種情況下，如果攻擊者使用相應(yīng)的“內(nèi)部”IPv4 CIDR 塊創(chuàng)建 VPC 并使用 VPC 終端，他們是否可以成功調(diào)用敏感的 AWS API，從而“繞過”此類策略。

我們發(fā)現(xiàn)(詳情點這里https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip)當(dāng) API 調(diào)用通過 VPC 終端完成時，aws:SourceIp 密鑰不可用(相反，aws:VpcSourceIp 可用)，因此該技術(shù)不能用于繞過此類 IAM 策略。

如何在你的運行環(huán)境中檢測此類活動：

通常，當(dāng) AWS API 調(diào)用通過 VPC 終端節(jié)點完成時，可選的 vpcEndpointID CloudTrail 字段會被填充(使用 VPC 終端節(jié)點的 ID)，與所有其他調(diào)用不同，這些調(diào)用不填充該字段。這是該技術(shù)在日志中唯一的殘留用法。

鑒于此，我們的第一個建議是查看 vpcEndpointID 字段。

檢測使用不在你在 VPC 中使用的任何私有 IP 范圍內(nèi)的 IP 地址的攻擊者相對容易，這可以通過查找通過 VPC 終端節(jié)點(帶有填充的 vpcEndpointId 字段)和不在你的 VPC 中使用的私有 IP 范圍內(nèi)的源 IP 地址執(zhí)行的任何 AWS API 調(diào)用來完成。

SQL 檢測查詢示例

但是，檢測攻擊者使用的IP地址在你的任何vpc中都是有效的私有IP地址，這是非常困難的。這是因為當(dāng)你在環(huán)境中使用VPC終端時，攻擊者的合法行為和攻擊者的行為產(chǎn)生的日志唯一的區(qū)別就是記錄的特定 VPC 終端節(jié)點 ID。我們建議使用更多基于異常的檢測邏輯來解決這個用例，檢測組織中從未見過的新 VPC 終端節(jié)點 ID 的使用情況

最后，我們建議 AWS CloudTrail 用戶將他們的云事件與終端、本地、電子郵件、身份等上的其他傳感器進行交叉引用?？绻裘娴木C合自動檢測是發(fā)現(xiàn)被忽略威脅的最有效方法。

本文翻譯自：https://www.hunters.ai/blog/hunters-research-detecting-obfuscated-attacker-ip-in-aws如若轉(zhuǎn)載，請注明原文地址。