亞馬遜 S3 存儲桶勒索軟體攻防詳解（下）

S3勒索軟體概述

正如本博文的第一部分所闡述的，S3勒索軟體是一種可以對公司造成極大影響的攻擊。S3勒索軟體是指攻擊者能夠訪問受害者的 S3 存儲桶，然後用自身的新副本替換每個對象，但用攻擊者的 KMS 密鑰進行加密。受害者將不再能夠訪問他們自己的 S3對象，需要服從攻擊者的要求才能獲得這些對象(或者花費額外的時間成本冒著去當局或 AWS 進行事件響應的風險)。

方法# 3:在你的賬戶中記錄和監控活動

你應該始終在你的帳戶中啟用 AWS CloudTrail。理想情況下，CloudTrail 應該覆蓋所有賬戶的所有區域，記錄讀寫管理事件，記錄 S3 存儲桶 和 Lambda 函數的數據事件，啟用日誌文件加密，並啟用日誌文件驗證。

根據你的預算，記錄帳戶中每個存儲桶的數據事件可能並不總是有意義的，因為如果經常訪問這些事件，那麼它們可能會變得相當耗費資金成本。如果你沒有為每個存儲桶記錄數據事件，那麼記錄的存儲桶包含敏感內容是非常重要的。通過這種方式，你可以查看誰在訪問你的數據、他們如何訪問數據以及他們從哪裡訪問數據的細粒度詳細信息。

Cloudtrail 中的日誌文件驗證可以幫助確保你的日誌文件在讀取之前不會被修改，因此你可以100% 信任正在查看的內容。啟用驗證是非常重要的，但是要確保實際驗證的確是你的日誌(使用類似於"aws cloudtrail validate-logs"之類的命令) ，因為即使啟用了設置，你也不會收到日誌修改的警告。

除了 CloudTrail 之外，還應該啟用像 AWS GuardDuty 這樣的工具來監視帳戶內的惡意活動。這些警報以及你的 CloudTrail 日誌應該被導出到外部的 SIEM，以便進一步檢查和監視。

如果你使用 AWS 組織，你應該在組織級別啟用 CloudTrail 和 GuardDuty 並將它們應用於你的子帳戶。這樣，子帳戶中的攻擊者就不能修改或禁用任何重要設置。

根據你的預算和其他因素，可以考慮為其他資源啟用其他類型的日誌和監視工具。這可能包括像彈性負載均衡器（Elastic Load Balancer）訪問日誌或基於主機的 EC2實例日誌之類的東西，或者可能啟用像 AWS Inspector 或 AWS Config 之類的東西。

方法# 4: S3對象版本控制和MFA刪除

這可能是針對 S3勒索軟體防禦的最重要的方法，但可能非常昂貴的防禦方法。S3 對象版本控制允許 S3對象被"版本化"，這意味著如果一個文件被修改，那麼兩個副本都作為一種"歷史"保存在存儲桶中。如果上傳的文件與存儲桶中已經存在的文件名相同，也會發生同樣的情況。這裡的一個示例場景是一個存儲 CloudTrail 日誌的存儲桶版本。如果攻擊者修改了一個日誌文件以刪除他們活動的痕迹，那麼防禦者可以比較文件的舊版本和當前版本，以確切地看到攻擊者刪除了什麼。

S3對象版本控制本身是不夠的，因為理論上，攻擊者可以禁用版本控制並覆蓋或刪除存儲桶中的任何現有版本，而不用擔心會創建新的版本。為了解決這個問題，AWS 提供了 S3 存儲桶中的雙重身份驗證刪除功能。啟用 MFA 刪除功能將迫使 MFA 被用來做以下兩件事中的一件:

1. 更改指定 S3存儲桶的版本控制狀態(即禁用版本控制)。

2. 永久刪除對象版本。

如果版本控制和 MFA 刪除都在存儲桶上啟用，那就意味著攻擊者需要拿到 root 用戶及其 MFA 設備來禁用版本控制和 MFA 刪除。這在理論上是可能的，但在實踐中是不太可能的。

方法# 5:存儲桶策略和ACL

眼下的當務之急是不要讓公眾接觸到你的存儲桶。可以通過各種不同的方式公開訪問存儲桶及存儲桶中的對象，造成這種風險最常見的罪魁禍首是存儲桶 ACL 或存儲桶策略。

在大多數情況下，你應該完全避免使用存儲桶 ACL，但有時由於幾個不同的原因，這是不可能的。這是一種管理訪問存儲桶的舊的"託管"方式，它不允許細粒度的訪問控制。如果你授權某人訪問 ACL 中的"List 對象"，他們可以在單個 API 調用中獲得 存儲桶 中所有對象的列表，並可以讀取這些文件中的任何文件。如果你授予某人訪問 ACL 中的"寫對象"的許可權，這意味著他們可以在存儲桶中創建、覆蓋和刪除對象。這兩點足以成為避免使用 ACL 的理由。

你應該使用存儲桶策略而不是 ACL，因為它允許最細粒度的許可權管理。你可以只授予 ACL 中的兩個許可權中的一個，而不是授予用戶列表和讀許可權。你甚至可以實施進一步的限制，例如只對存儲桶中的少數對象進行讀訪問。例如，如果你的網站直接從你的 存儲桶 中讀取 S3對象，那麼它不需要列出 存儲桶 中的每個對象的許可權，因為它應該已經知道它正在取什麼。在這種情況下，你可以在 存儲桶 策略中授予它"s3: GetObject"，而不是在列表中授予它，並在 ACL 中讀取它。與通過 ACL 授予創建或覆蓋和刪除對象許可權不同，你可以授予其中一個許可權並施加進一步的限制，如上所述。

S3 存儲桶 策略的另一個特性是，它們能夠實施特定類型的加密。這方面的例子是強制所有上傳的文件使用 AES256進行加密，或者強制所有上傳的文件使用特定的 AWS KMS 密鑰進行加密。這可以用來防止 S3勒索軟體，因為理想情況下，攻擊者無權修改存儲桶的策略。

你可以設置你的存儲桶策略，只允許上傳使用你的特定 KMS 秘鑰加密的對象。在這種情況下，攻擊者將不能使用你在策略中沒有指定的另一個 KMS 密鑰，這對於勒索該存儲桶是必要的。然後他們會得到一個拒絕訪問的錯誤消息，最終防止了攻擊。

下面是一個 S3 存儲桶 策略的例子，它強制必須使用一個特定的 KMS 密鑰對文件進行加密後才能上傳:

{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Principal":"*","Action":"s3:PutObject","Resource":["arn:aws:s3:::my-bucket-name/*","arn:aws:s3:::my-bucket-name"],"Condition":{"StringNotEquals":{"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:REGION:ACCOUNT-ID:key/KEY-ID"}}}]}

關於 S3操作、資源和條件密鑰的更多信息可以在這裡找到。

方法# 6:帳戶範圍內的S3公共訪問設置

如果你擔心你的開發人員可能會向你的存儲桶提供公共可訪問性，那麼你可以利用帳戶範圍的選項來阻止公共 ACL 和公共策略生效。請注意，這適用於你帳戶中的每個存儲桶，如果你依賴於對帳戶中特定存儲桶的跨帳戶或公共訪問，則可能會導致問題。

如果你可以驗證針對你的所有存儲桶的公共訪問的阻止配置是正確的，那麼你應該考慮為你的帳戶啟用帳戶範圍的 S3公共訪問設置。

上面的屏幕截圖顯示了 AWS Web 控制台中某個示例帳戶的公共訪問設置。在本例中，所有現有的公共存儲桶 ACL 和所有現有的公共存儲桶策略都將被阻止，這意味著由於這個更高層級的公共訪問設置，它們實際上不會授予公共訪問許可權。此外，新的 ACL 和授予公共訪問許可權的策略也將被阻止。

方法# 7:備份

最後，當然，你需要備份你的數據！無論是使用 MFA 版本化的存儲桶、跨存儲桶或帳戶複製數據，還是甚至是本地複製數據，這都是非常重要的事情。有了充分備份的數據，你就可以忽略攻擊者(當然是在事件響應計劃付諸實施之後) ，並恢復備份，然後就像從未得到勒索攻擊一樣。

從一次成功的勒索軟體攻擊中恢複數據

如果你已經成為 S3勒索軟體攻擊的目標，你如何應對很可能取決於幾個不同的因素。AWS 安全部門意識到了這種攻擊載體的風險，但尚不確定他們在幫助你的過程中能發揮什麼作用——如果有幫助的話。如果你能接受這些額外的時間成本，那麼最好的辦法就是聯繫有關部門，儘管這樣的拖延對你的公司來說可能成本太高了。出於這個原因，最好是能夠對這種攻擊實施強有力的防禦，這樣你就不會陷入需要權衡你的潛在選擇和面臨的風險的局面。

事件響應計劃

如果你已經成為攻擊目標，那麼第一步就是制定你的事件響應計劃。這樣做可以降低攻擊者的「爆炸半徑」，讓他們遠離你的環境，並確定他們已經獲得的數據和攻擊影響。這就是為什麼在AWS 環境中配置日誌記錄和監視是必不可少的原因之一。了解攻擊者訪問了什麼，將有助於你確定下一步需要做什麼。

檢查存儲桶配置的腳本

我們編寫了一個腳本，可以檢查 AWS 帳戶中所有存儲桶的重要設置。這包括檢查每個存儲桶上的對象版本控制和 MFA 刪除。你可以在我們的 GitHub 上找到這個腳本。它還有一個選項，可以為任何尚未啟用它的存儲桶啟用對象版本控制。

這個屏幕截圖顯示了針對一個易受攻擊的 AWS 帳戶運行腳本的一些示例輸出。

當打開輸出結果的 CSV 文件時，你將看到類似下面的屏幕截圖(S3存儲桶名稱已被打碼) :

在運行這個腳本時需要注意一些參數:

-p 或 --profile: 用於 AWS 身份認證的 AWS CLI 配置文件 (~/.aws/credentials).

-b 或 --buckets: 要檢查的以逗號分隔的 S3存儲桶列表。這些存儲桶應是你擁有或至少可公開訪問。如果未提供此參數，則將檢查帳戶中的所有存儲桶。-e 或 --enable-versioning: 如果傳遞了該參數，腳本會將嘗試啟用狀態為禁用或掛起（disabled 或 suspended）的存儲桶的版本控制。注意，腳本將不會嘗試啟用 MFA 刪除功能，因此該操作需要 AWS root 用戶許可權能啟用。

下面的屏幕截圖顯示了激活版本控制參數的使用情況(S3 存儲桶名稱再次被打碼)。

CSV 文件的結果會顯示任何已成功啟用其版本控制的 存儲桶。如果腳本無法啟用版本控制(例如因為許可權錯誤之類的原因) ，它將移動到下一個存儲桶，並用其原始版本控制的設置選項("Disabled"或"Suspended")對檢查失敗的存儲桶進行標記。

總結

S3勒索軟體對於攻擊者來說可以相當直接且簡單地執行，但是防禦者可以設置各種簡單和困難的防禦機制。在最低級別上，對於防禦者來說，在一個 S3存儲桶上啟用版本控制和刪除 MFA 是很簡單的方法，這在大多數情況下可以有效地防止勒索軟體。

在 AWS 環境和敏感的 S3存儲桶中實現防禦機制非常重要。雖然可能沒有必要執行上面講到的每個方法，但必須確定哪些攻擊載體和入口點最容易受到影響，因此需要進行防護。

雖然上面講到的方法在幫助防止用戶被 S3勒索軟體攻擊方面非常有用，但總是還有更多的防禦或檢測方法。我們鼓勵任何讀者與我們聯繫，討論其他的想法，這樣我們可以把他們的想法添加到這篇文章中(這歸功於你) ，並與其他人分享他們試圖保護自己的環境。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！