寫在前面的話
在安全防御端的研究中，或者作為安全防御端研究人員，我們常常都會站在攻擊者的角度或攻擊向量切入點來思考安全防御問題，這些攻擊者一般來說都是來自信任區域之外的威脅行為者。但是，如果攻擊者已經成功進入了我們的信任區域，并且想要獲取我們的數據，此時該怎么辦呢？
這就是我們常說的外部威脅轉變成內部威脅之后的場景，隨著云服務的使用和覆蓋越來越廣泛，攻擊者也開始利用云服務來實現自己的目標。在這篇文章中，我們將深入分析威脅行為者如何使用AWS服務來實現滲透和數據竊取。
關于Amazon S3
Amazon Simple Storage Service（Amazon S3）是一種對象存儲，它具有簡單的 Web 服務接口，可用于在Web上的任何位置存儲和檢索任意數量的數據。S3的數據存儲結構非常簡單，就是一個扁平化的兩層結構：一層是存儲桶（Bucket，又稱存儲段），另一層是存儲對象（Object，又稱數據元）。存儲桶是S3中用來歸類數據的一個方式，它是數據存儲的容器，每一個存儲對象都需要存儲在某一個存儲桶中。
本文主要以Amazon S3為例，并探索針對Amazon S3的威脅模型和滲透用例。
下圖顯示的是常見的Amazon S3系統架構圖：
從企業網絡內部發出的請求將首先到達出口代理、防火墻或 CASB，而這些功能可以是連續的、單一的或一體化的解決方案。但這些功能往往尋求實現的結果是相同的，即數據泄露防護。
CASB應防止威脅行為者登錄除目標企業帳戶之外的其他云服務提供商帳戶。
防火墻或出口代理應防止威脅行為者建立與任意或其他已知惡意域的連接。
在企業內部網絡中，威脅行為者可以做到以下兩件事情：
1、使用組織AWS帳戶訪問S3，可能沒有權限或僅使用s3:GetObject；
2、匿名訪問 S3，即可以使用curl獲取S3資源；
當然了，還有第三條路徑，即把目標用戶的賬號憑證帶入企業內部網絡中，不過這超出了本文的討論范疇。
需要注意的是，本文討論的場景中我們是沒有任何權限的，或者說我們最多就只有一個s3:GetObject。
研究計劃
下圖顯示的是本文使用S3作為數據提取機制的流程圖：
我們先看看下面這個場景：
此時，威脅行為者可以控制目標用戶中的RoleA，而RoleA的權限中明確規定了不允許對目標環境執行任何操作或資源訪問。那么在這種情況下，威脅行為者是否能夠成功利用RoleA實現數據泄露，并將數據提取到不同賬戶中的AttackerBucket呢？
當然了，在執行操作時，RoleA肯定會收到AccessDenied的提示，這是無法繞過的。另外，威脅行為者要做的是獲取一個對象，而不是執行寫入操作。看起來挺難的吧？與此同時大家可別忘了，我們還有代理、防火墻和CASB來阻止請求到達威脅行為者的S3 Bucket。
但S3又一個非常棒的功能，即“服務器訪問日志”，S3的服務器會將所有針對目標S3 Bucket發出的請求詳細記錄到日志中。
它的行為方式和常見的Web服務器日志記錄行為類似，但此時并不是直接在服務器/var/log下傳遞請求日志，而是需要配置另一個Bucket，即一個日志Bucket。
如果你使用過這個功能的話，你可能會見過如下所示的來自內部AWS服務（例如 IAM 訪問分析器）的請求日志信息：
attackerbucket [19/Oct/2023:12:48:23 +0000] 54.229.101.202 arn:aws:sts::123456789012:assumed-role/AWSServiceRoleForAccessAnalyzer/access-analyzer [..] - "GET /?location HTTP/1.1" 200 - 137 - 28 - "-" "aws-sdk-java/2.20.162 Linux/4.14.255-318-256.530.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/25.382-b05 Java/1.8.0_382 vendor/Amazon.com_Inc. md/internal exec-env/AWS_Lambda_java8.al2 io/sync http/Apache cfg/retry-mode/legacy" – [..] SHA256 AuthHeader attackerbucket.s3.eu-west-1.amazonaws.com TLSv1.2 - -
你可以在日志中看到請求所使用的角色、來源和用戶代理信息。上述日志中，我們可以看出 IAM 訪問分析器正在Java8運行時中的Lambda上運行。
當VPC終端節點策略拒絕時，Amazon S3不支持將服務器訪問日志發送給VPC終端節點請求的請求者或Bucket所有者。
這是否意味著，當我們位于VPC外部（使用公司防火墻）或VPC沒有限制性終端節點策略時，Amazon S3就支持發送服務器訪問日志了呢？是的，沒錯！
分析執行
下圖顯示的是威脅行為者的配置圖（一個日志Bucket）：
威脅行為者可以啟動S3服務器的訪問日志記錄功能，并將其轉儲到另一個他們可以控制的Bucket中，然后在沒有權限的情況下，繞過IAM條件設置的數據邊界，使用目標用戶的身份從目標組織網絡內竊取數據。同樣的遠離也適用于向“AttackerBucket”發送GET請求，但不同之處就在于目標網絡的代理、防火墻或CASB如何去處理這些請求了。如果你僅允許使用AWS組織的憑證進行身份驗證的請求，那么威脅行為者仍然可以使用此技術并訪問S3服務和數據資源。
如果威脅行為者位于VPC內部時，會發生什么呢？VPC策略首先需要允許請求抵達S3服務：
在一個VPC內，威脅行為者需要一個泄露的VPC節點，例如一個允許將請求轉發到S3服務器的節點。這樣一來，威脅行為者不需要其 IAM 角色的任何權限即可請求訪問 S3 服務和數據資源。
下面給出的是服務器訪問日志記錄的工作原理序列圖：
S3 服務將接收并評估請求，并根據情況返回對應的響應信息。然后它會記錄請求，收集日志，并將它們發送到日志Bucket中，同時請求者沒有IAM訪問權限的這一事實也會被記錄下來。
當VPC節點位于威脅行為者和S3服務之間時，整體情況將完全取決于S3服務對來自VPC節點的請求評估結果了。如果請求從未到達S3服務，則不會生成和發送任何日志，比如說你的Bucket使用了資源限制條件屏蔽了外部資源訪問等等。
威脅行為者接收到的日志信息格式大致如下：
[..] attackerbucket […] 31.94.19.179 – […] REST.GET.OBJECT PIIorOtherDataToExfilGoesHere "GET / PIIorOtherDataToExfilGoesHere HTTP/1.1" 403 AccessDenied 243 - 18 - "-" "UserAgentAlsoHasData " – […
其中的“PIIorOtherDataToExfilGoesHere”是我們從S3請求的對象密鑰，“UserAgentAlsoHasData”是我們為該請求設置的用戶代理。
威脅行為者可以使用“Key”、“User-Agent”或其他S3 GetObject請求參數并在這些請求中包含任意數據。生成的“拒絕訪問”服務器日志條目中將包含威脅行為者控制的數據，這些數據最終可以在威脅行為者的日志Bucket中捕捉到。
可怕的是，每個請求都包含有一個1024字節長的密鑰（“Key”），這足以泄露大量的數據了。
總結
總而言之，單獨使用 AWS IAM 并不是有效的數據邊界，如果沒有額外的網絡邊界控制，服務器訪問日志可以通過提供可攜帶任意數據的請求信息來用作竊取數據的機制。
參考資料
https://www.optiv.com/explore-optiv-insights/blog/escape-and-evasion-egressing-restricted-networks
https://aws.amazon.com/blogs/networking-and-content-delivery/continually-enhancing-domain-security-on-amazon-cloudfront/
https://www.youtube.com/watch?v=sc3J4McebHE
https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html#how-logs-delivered
https://github.com/aws-samples/data-perimeter-policy-examples/blob/main/vpc_endpoint_policies/s3_endpoint_policy.json
https://docs.aws.amazon.com/AmazonS3/latest/userguide/LogFormat.html
參考鏈接
https://airwalkreply.com/cloud-services-as-exfiltration-mechanisms?utm_source=cloudseclist.com&utm_medium=referral&utm_campaign=CloudSecList-issue-218?
安全俠
RacentYY
RacentYY
RacentYY
X0_0X
尚思卓越
RacentYY
FreeBuf
