攻擊者可以通過預先創建具有可預測名稱的S3存儲桶，從而訪問AWS賬戶或敏感數據，而這些存儲桶將被各種服務和工具自動使用。

研究人員發現了一種攻擊AWS服務或自動配置AWS S3存儲桶的第三方項目的新方法，這種被稱為“Shadow Resource”的新攻擊向量可能導致AWS賬戶被接管、遠程代碼執行或敏感數據泄露。

安全公司Aqua Security的研究人員發現，六種AWS服務會創建具有可預測名稱的S3存儲桶，這些存儲桶易受新劫持技術的攻擊，他們在本周的Black Hat USA安全會議上展示了他們的研究成果。

“Shadow Resource”攻擊涉及攻擊者在其他AWS區域提前創建存儲桶，然后等待目標用戶在這些區域啟用易受攻擊的服務，從而導致敏感文件和配置被存儲在由攻擊者控制的存儲桶中。

Aqua確定易受此技術攻擊的AWS服務包括CloudFormation、Glue、EMR、SageMaker、ServiceCatalog和CodeStar。亞馬遜已經修復了這些服務中的問題，并正在調查過去是否曾被利用過，其他表現出類似S3存儲桶配置行為的AWS服務和第三方工具可能仍然存在漏洞。

具有后門潛力的影子存儲桶

Aqua的研究人員在注意到AWS CloudFormation每次在新的AWS地理區域啟用時，都會在后臺創建一個S3存儲桶后，開始了他們的調查。這個S3存儲桶用于存儲用戶創建的CloudFormation模板，其名稱格式為[固定前綴]-[唯一哈希值]-[AWS區域名稱]，例如cf-templates-123abcdefghi-us-east-1。

S3存儲桶名稱在整個AWS基礎設施中是唯一的，因此研究人員想知道，如果攻擊者提前在用戶可能稍后啟用的不同區域中注冊了CloudFormation預期會創建的存儲桶名稱，會發生什么。

存儲桶名稱的前綴和哈希部分在各區域之間保持不變——只有區域部分會改變。因此，如果攻擊者確定了哈希值，他們可以在用戶尚未使用的區域中預先注冊該存儲桶。盡管猜測哈希值是不可能的，但Aqua研究人員設法在GitHub的公共倉庫或公開的錯誤票中找到了這些哈希值。

接下來他們想知道，當用戶在某個區域部署服務時，CloudFormation是否會使用攻擊者創建的現有存儲桶，還是會在嘗試創建存儲桶時出現錯誤。他們發現，CloudFormation確實會響應一個錯誤——但只有在存儲桶未配置為公共訪問時才會如此，這是因為它無法向存儲桶寫入文件。

因此，如果攻擊者配置了非常寬松的策略以允許服務所需的操作，并啟用了公共訪問，CloudFormation將直接使用這個惡意存儲桶。

問題的影響取決于易受攻擊服務在存儲桶中存儲的內容。對于CloudFormation(一個基礎設施即代碼工具)來說，存儲在存儲桶中的模板用于自動部署由用戶定義的基礎設施堆棧。

這些模板可能包含敏感信息，如環境變量、憑據等，但問題更嚴重的是，攻擊者可以在存儲桶中保存的模板中注入后門代碼，這些代碼將在用戶的賬戶中執行。例如，攻擊者可以在模板中注入一個惡意的Lambda函數，該函數可以在賬戶中創建一個新的管理員角色，供攻擊者使用。

使用賬戶ID生成可預測的S3存儲桶名稱

CloudFormation攻擊依賴于服務為用戶在某個區域創建的現有S3存儲桶名稱被泄露在代碼倉庫中，但其他自動創建S3存儲桶的AWS服務使用了更為可預測的命名模式。例如，AWS EMR(Elastic MapReduce)生成的S3存儲桶名稱為aws-emr-studio-[account-ID]-[region]，而AWS SageMaker則使用sagemaker-[region]-[account-ID]。

根據AWS文檔，AWS賬戶ID不被視為機密或敏感信息。因此，它比由特定服務生成的唯一哈希值更有可能在多個地方被暴露。

AWS EMR是一項服務，用戶可以使用Apache Hadoop、Apache Spark、Apache Hive和Jupyter Notebook等框架處理和分析大數據集。由EMR Studio創建的S3存儲桶用于存儲敏感的配置文件，同樣易受此類攻擊。

例如，攻擊者可以在受害者的EMR服務存儲的Jupyter Notebook文件(.ipynb)中注入惡意函數，導致Jupyter Notebook界面中出現跨站腳本(XSS)漏洞。研究人員表示，這種漏洞可用于將用戶重定向到偽造的AWS登錄頁面，從而竊取他們的憑據。

AWS SageMaker是一個用于構建、訓練和部署機器學習模型的服務，也存在類似的漏洞，因為SageMaker Canvas會自動設置一個可預測的S3存儲桶。如果攻擊者預先注冊了這個存儲桶，他們可以訪問敏感的模型訓練數據，甚至可以污染數據集，從而創建不準確的模型。

研究人員還警告說，許多組織用于在其AWS環境中部署資源的開源工具也會創建具有可預測名稱的S3存儲桶，這些名稱通常依賴于AWS賬戶ID、固定前綴和區域名稱，這些工具是否易受攻擊取決于它們在存儲桶已存在的情況下是否會報錯，或者它們是否會繼續使用現有存儲桶(該存儲桶可能是由攻擊者擁有的)。影響還取決于存儲在這些存儲桶中的文件和資源類型。

研究人員在GitHub上搜索AWS賬戶ID模式，得到了將近160,000個結果。此外，還有其他人建立的包含AWS賬戶ID的列表，以及可能包含賬戶ID的S3存儲桶名稱列表。AWS賬戶ID還可以通過已知技術從AWS訪問密鑰ID中推導出來。

桶壟斷攻擊及其緩解措施

為了最大化攻擊成功的可能性，攻擊者可以使用可預測的命名模式在組織尚未使用的所有AWS區域中創建影子S3存儲桶。AWS目前有33個區域，而一個組織不太可能使用其中的所有區域。研究人員將這種攻擊稱為“桶壟斷攻擊”。

首先，攻擊者找到一個基于AWS賬戶ID生成具有可預測名稱的S3存儲桶的服務或開源工具。然后，他們識別出使用該服務或工具的組織，并找到其賬戶ID。確定這些組織尚未使用哪些區域來部署服務或工具并不困難，因為存儲桶名稱在整個服務中是唯一的，容易檢查它們是否已存在。

Aqua Security的研究人員提出的一種緩解措施是，組織可以為其使用的服務或工具所使用或假定的角色定義一個范圍化的策略，并在策略中包含`aws:ResourceAccount`條件元素，這可以用于檢查擁有資源(如S3存儲桶)的AWS賬戶ID是否與條件中提供的用戶自身的AWS賬戶ID匹配。

想要檢查某些服務的存儲桶是否遵循可預測名稱模式且由自己擁有的組織，可以使用以下命令：`aws s3api list-objects-v2 --bucket --expected-bucket-owner `。如果回復為“訪問被拒絕(Access Denied)”，則表示盡管存儲桶名稱中包含您的賬戶ID，但該存儲桶并不屬于您的賬戶。

那些基于AWS賬戶ID并使用可預測模式自動生成存儲桶名稱的工具應轉向使用唯一的哈希值和隨機標識符來為每個區域生成存儲桶名稱。