[[404095]]

Amazon Virtual Private Cloud (Amazon VPC)允許你在已定義的虛擬網(wǎng)絡(luò)內(nèi)啟動(dòng)AWS資源。這個(gè)虛擬網(wǎng)絡(luò)與你在數(shù)據(jù)中心中運(yùn)行的傳統(tǒng)網(wǎng)絡(luò)極其相似，并會(huì)為你提供使用AWS的可擴(kuò)展基礎(chǔ)設(shè)施的優(yōu)勢。簡單來說，VPC就是一個(gè)AWS用來隔離你的網(wǎng)絡(luò)與其他客戶網(wǎng)絡(luò)的虛擬網(wǎng)絡(luò)服務(wù)。在一個(gè)VPC里面，用戶的數(shù)據(jù)會(huì)邏輯上地與其他AWS租戶分離，用以保障數(shù)據(jù)安全。可以簡單地理解為一個(gè)VPC就是一個(gè)虛擬的數(shù)據(jù)中心，在這個(gè)虛擬數(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有如下特點(diǎn)：

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

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

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

攻擊者控制CloudTrail SourceIP

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

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

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

技術(shù)分析

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

CloudTrail 日志有一個(gè)“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地址范圍和可對(duì)外路由的IP地址范圍?？晒_路由的IP塊只能通過虛擬專用網(wǎng)關(guān)訪問，不能通過Internet網(wǎng)關(guān)訪問。這允許攻擊者創(chuàng)建一個(gè)IP尋址方案，模仿受害者自己的網(wǎng)絡(luò)或信譽(yù)良好的外部服務(wù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.一個(gè)特殊的私有、保留、測試或僅用于文檔的 IPv4 子網(wǎng)塊：有 4-5 個(gè)子網(wǎng)被定義為用于臨時(shí)目的的“保留 IP”，使用其中一個(gè)還可以幫助規(guī)避信譽(yù)服務(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é)點(diǎn)訪問

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

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

需要注意的是：

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

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

3.僅根據(jù)記錄的 IP 無法將攻擊者識(shí)別為組織外部的攻擊者，也無法確定其真實(shí)來源。但是，可以確定所涉及的 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)(詳情點(diǎn)這里https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip)當(dāng) API 調(diào)用通過 VPC 終端完成時(shí)，aws:SourceIp 密鑰不可用(相反，aws:VpcSourceIp 可用)，因此該技術(shù)不能用于繞過此類 IAM 策略。

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

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

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

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

SQL 檢測查詢示例

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

最后，我們建議 AWS CloudTrail 用戶將他們的云事件與終端、本地、電子郵件、身份等上的其他傳感器進(jìn)行交叉引用。跨攻擊面的綜合自動(dòng)檢測是發(fā)現(xiàn)被忽略威脅的最有效方法。

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