最近，一起和雲有關的大型數據洩露事件成了頭條新聞。美國的Capital One銀行由於“伺服器配置錯誤”，被某個駭客竊取了上億張信用卡數據以及十多萬社保號碼。現時，有關此次洩露事件中涉及的科技和駭客的各類分析報告都已出爐，讓我們看看到底是什麼原因導致了這起事件的發生。
危險一直在身旁
讓駭客有可乘之機的是一個常見的雲安全問題：雲上基礎設施資源的錯誤配寘使得未經許可權驗證的用戶非法提升自己的許可權，從而接觸到敏感檔案。在過去的2-3年裏，這種問題所導致的安全事件也頻頻見報，例如，近2億份選民記錄洩露，五角大樓Tb級機密檔案洩露，5億份Facebook個人資料洩露。
獲得立足點
根據12頁的政府起訴書（PDF），此次事件所涉及的具體漏洞是Capital One在其AWS帳戶中的服務器會執行任意用戶所發起請求。起訴書雖然沒有詳細說明具體漏洞，但大多數迹象表明這是一個針對伺服器端的SSRF攻擊。SSRF攻擊可讓攻擊者借助放置在公網上的服務器去非法訪問內網中的服務器，造成命令執行、數據洩露等危害。
AWS中繼資料服務
由於目標伺服器託管在AWS中，所以它可以訪問一個被稱為中繼資料服務的網站，地址為http://169.254.169.254。通常，這個URL通過HTTP介面為使用者提供各類節點資訊，例如節點的IP地址、在AWS網絡中的位置和主機名。對於AWS中應用程序的開發人員來說，這是一個非常有用的服務。
http://169.254.169.254
而這個服務的一個特別重要的功能就是提供臨時憑證。根據實例的IAM角色中定義的許可權策略，為節點提供對其他AWS服務的訪問權。IAM角色是一種新型的授權管理方案，用於替代傳統的用戶訪問金鑰；應用程序不需要將固定的訪問金鑰硬編碼到配寘中，只需定期從中繼資料服務請求臨時憑據。AWS的所有SDK都通過一系列檢查自動處理請求，檢查在環境變數、設定檔、本地應用程序程式碼或中繼資料服務中是否存在憑據。
許可權獲取
通過早期摸索，攻擊者知曉了某臺AWS EC2服務器的SSRF漏洞，並且這臺服務器很可能具有中繼資料服務發佈的臨時憑證。於是攻擊者便利用（通過SSRF）這臺服務器發出以下請求：
http://169.254.169.254/iam/security-credentials
以上請求會返回一個角色名稱，起訴書中將其標為*****-WAF-Role，這意味著存在缺陷的服務器可能是Capital One網絡中的一個web應用防火牆。
*****-WAF-Role
有了角色名，攻擊者就可以進行下一步査詢：
http://169.254.169.254/iam/security-credentials/*****-WAF-Role
以上査詢返回了一組最初分配給EC2實例的臨時憑證：
{
AccessKeyId: "<access key>",
SecretAccessKey: "<secret key>",
}
以上是標準的AWS憑證，可用於通過AWS命令列或任何SDK訪問AWS的API。此外，IAM角色也沒有額外限制，封锁在Capital One網絡之外使用這些憑證。囙此，世界上任何人都可以使用這些憑證對自己的API請求進行簽名，就像它們是Capital One網絡內的EC2實例發出的一般。
危害
根據起訴書，一旦攻擊者獲得了這些憑證，她就運行了AWS S3中的ListBuckets命令。要成功實現這一點，需要IAM角色策略中設定允許此API被調用。起訴書中雖然沒有明確列出關於這點的許可權控制，但是我們可以猜測在許可權管理策略中是這個API是允許被調用的，相關策略可能如下：
ListBuckets
{
"Effect": "Allow",
"Actions": [
"s3:ListBuckets",
"s3:Sync"
],
"Resource": "*"
}
在運行了s3:ListBuckets之後，帳戶中的所有AWS S3 bucket將完整列出。
s3:ListBuckets
$ aws s3 ls
2019-08-01 11:01:10 bucketone
2019-08-01 12:00:23 buckettwo
起訴書中還提到，這個命令被運行了好幾次。接著攻擊者再使用AWS s3:Sync命令將這些存儲桶中的數據複製到攻擊者的本地機器上，最終導致這一數據洩露事件。
AWS s3:Sync
$ aws s3 sync s3://bucketone .
問題到底在哪裡？
總而言之，此次事件是由一個漏洞和一個錯誤配寘所導致的。其中SSRF漏洞是一切的開端，讓攻擊者找到了突破口，得以窺視內部的網路服務；隨後，一個錯誤配寘讓攻擊者獲得了大量的敏感資訊。
安全可以說是一個洋葱，攻擊者一層一層地攻破防護，最終抵達中心。當攻擊者獲得目標的IAM憑證時，就意味著她已掌握大量S3存儲桶的詳細資訊和存取權限。
我們當然可以很容易的將此次洩漏事件歸咎於Capital One的開發人員，但事實上，幾乎每個AWS帳戶都或多或少存在IAM角色配寘缺陷。很少有開發人員會花時間仔細研究其中涉及的每個許可權；他們通常會在很多配寘處直接使用萬用字元，給攻擊者可乘之機。
此外，根據起訴書的說法，我們可以推測得知Cloudtrail日誌記錄是啟用的（用於監控），這其中也記錄了有外部角色正訪問內部服務，理應能讓管理員及時止損。
此次事件和以往的AWS安全事件不同的是，Capital One確實啟用了監控，它們的存儲桶也並沒有授權問題，但攻擊者還是通過一個外部漏洞成功進行了攻擊。
安全建議
確保每個應用、EC2實例等都有自己的IAM角色。不要在不相關的應用之間共亯角色。
確保每個內網中角色僅能訪問所需的資源。不要讓WAF能訪問到S3存儲桶。
確保所有區域和所有服務都啟用了AWS Cloudtrail。如果你在S3中存儲了特別敏感的數據（例如社會保險號碼），需確保記錄下S3存儲桶的每次讀取行為。
時刻檢查應用中的傳統web漏洞，拒絕給攻擊者提供內網落腳點。
結論
雲中的安全管理一直都非常具有挑戰性。正如我們在過去幾年中所看到的那樣，一條策略的缺陷，就有可能導致上億條數據的洩露。只有持續的安全稽核和監控，才是對抗安全風險的根本手段。
本文由白帽汇整理并翻译，不代表白帽汇任何观点和立场
来源：https://blog.cloudsploit.com/a-technical-analysis-of-the-capital-one-hack-a9b43d7c8aea