資安事件與漏洞
Capital One 資料外洩事件（2019）— SSRF 如何導致 1 億人資訊外洩及防禦之道
2019 年，美國大型銀行 Capital One 約 1 億 600 萬人的申請資料遭到外洩。入口只是一個 SSRF（伺服器端請求偽造）。攻擊者藉此抵達雲端的中繼資料服務端點，奪取了權限過大的 IAM 臨時憑證，進而把 S3 儲存空間一次性整體複製走。本文把這條攻擊鏈拆解為一張防禦地圖，僅依據公開記錄的事實，講清如何在你的環境中避免重蹈覆轍（IMDSv2、最小權限、出站目標白名單）。
我們解讀真實發生過的公開事故，但視角不是新聞的重播，而是 「在你的環境裡該如何防住」。本文是 基於公開記錄（主管機關、報導、學術分析、官方公告）的解讀。出處在文末註明。
- 對象
- Capital One（美國大型銀行）
- 公布
- 2019 年 7 月 29 日（察覺 7 月 19 日／入侵 3 月）
- 手法分類
- 以 SSRF 為起點，竊取雲端憑證並向外帶出
- 影響規模
- 美·加約 1 億 600 萬人的申請資料（含 SSN 約 14 萬、關聯銀行帳號 約 8 萬）
- 根本原因
- SSRF 缺陷 ＋ 中繼資料服務端點不設防 ＋ IAM 角色權限過大，多層接連崩塌
- 正解對策
- 出站目標白名單、IMDSv2、IAM 最小權限構成的多層防禦
發生了什麼（用大白話講）
Capital One 把部分申請處理跑在雲上。在其前端、本應屬於防禦方的一個元件（以反向代理／WAF 身分運行）存在 SSRF 缺陷——能讓伺服器自身向外部指定的目標發起請求。
雲端的虛擬機有一個特殊目標，叫 只能從內部存取的「中繼資料服務端點」，向它查詢就會回傳分配給該機器的權限所對應的 臨時憑證。攻擊者用 SSRF 抵達這個內部目標，拿到了憑證。而該憑證所繫結的 IAM 角色（公開記錄中報導為 ISRM-WAF-Role）擁有 可大範圍讀取儲存空間的過大權限，於是他們把約 700 個儲存區域（S3 儲存貯體）的內容 原樣複製 後帶走。
「只能從內部看到」——一旦有 SSRF，外部就成了「內部」
中繼資料服務端點的防護建立在「外部無法抵達」這一前提之上。然而 SSRF 是一種讓伺服器自身代為存取的攻擊，它會打破這一前提。「因為限定內部所以安全」的設計，只要入口處有一個 SSRF 就會崩潰。
攻擊鏈同時也是「防禦地圖」
關鍵在於：這是一條 四跳 的連鎖，而 每一跳都本有攔截點。請不要把它讀成攻擊步驟，而要讀成 在哪裡本可被切斷。
① 入口：SSRF
讓伺服器代為向任意目標發起請求的缺陷。
⊘ 攔截點：把出站目標改為白名單方式
② 抵達內部的中繼資料服務端點
本應限定內部的目標，卻被經由 SSRF 抵達。
⊘ 攔截點：IMDSv2（強制權杖＋跳數限制）
③ 取得 IAM 臨時憑證
掛在機器上的角色的臨時憑證被回傳。
⊘ 攔截點：把角色權限最小化（禁止整體讀取儲存空間）
④ 把儲存空間(S3)一次性整體複製
把約 700 個區域的內容原樣向外帶出。
⊘ 攔截點：出站(egress)管控＋偵測異常的大量讀取
已公布的時間軸
2019-03
雲端環境遭到非法存取（後來才查明）。2019-07-17
外部舉報（GitHub 上的貼文）指出異常。2019-07-19
Capital One 透過內部調查確認遭入侵。2019-07-29
對外公布。一名前 AWS 工程師的嫌疑人被 FBI 逮捕。2019-11
AWS 發布 IMDSv2，作為針對 SSRF 的多層防禦。2020-08
美國 OCC 處以約 8,000 萬美元罰款，指出其在遷移上雲之前的風險評估存在缺失。
根本原因不是「一處失誤」，而是層層崩塌
把這起事故歸結為「SSRF 的錯」，就會重演。實際上其本質是 三層接連崩塌。
崩塌的構成（事故當時）
- 入口處不檢核出站目標（可向任意目標代為發起請求）
- 中繼資料服務端點無需權杖就回傳憑證（舊方式）
- 機器的 IAM 角色擁有可大範圍讀取儲存空間的過大權限
守住的構成（杜絕重演）
- 把出站目標限定為白名單方式，拒絕對內部位址的代為存取
- 中繼資料採用 IMDSv2：強制工作階段權杖＋跳數限制，阻斷代為抵達
- IAM 角色採用最小權限：只給所需儲存貯體上所需的操作
「責任共擔」的分界線
雲端一方負責底層基礎設施的安全，但修復 SSRF、設計 IAM 權限、保護中繼資料是使用方的責任。這起事故被處罰的理由也是「遷移上雲之前的風險評估存在缺失」。乘上便利的基礎設施本身並無問題，能否把分界線屬於自己的那一側徹底設計到位，才是分水嶺。
在你的環境中杜絕重演
以下是無論規模大小都奏效、按優先順序排列的對策。只要你有哪怕一個「接收 URL 並去抓取」「代為取得 Webhook 或圖片」的功能，這就是你自己的事。
把出站目標改為「白名單方式」（在入口處封堵 SSRF）
對於伺服器代為存取使用者提供的 URL 的處理，要限定為僅限已許可的目標。對內部位址（中繼資料服務端點或私有網路）的抵達預設拒絕。SSRF 詞條裡彙總了檢核時容易漏掉的坑（跟隨重新導向、DNS 重新解析等）。
對中繼資料強制使用 IMDSv2
把雲端的中繼資料服務端點限定為強制權杖、帶跳數限制的新方式（AWS 上即 IMDSv2）。僅此一項，就能讓從 SSRF 竊取憑證的難度大幅提升。要點是停用舊方式。
把 IAM 角色設為最小權限（縮小波及範圍）
為了在憑證萬一外洩時把損失關進籠子，給機器或服務掛載的權限要收緊到只給所需對象上所需的操作。「先一股腦給儲存空間全權限」會把一次入侵變成全量資料外洩。
準備好出口(egress)管控與異常偵測
把外向通訊限定到必要的目標，並能偵測出諸如短時間內大量讀取之類的異常。即便在入口處沒能完全防住，也要留下一層能在帶出階段察覺的防線。
與本站設計理念相通之處
本站自身在處理使用者 URL 的功能上，也以 僅限已驗證網域 為前提來設計（SSRF-safe by design）。這起事故，最雄辯地說明了我們在產品中堅守的原則——入口檢核、最小權限、不依賴「內部」這一前提——為何必要。在便利的背後，分界線屬於自己的那一側要由自己徹底設計到位。這是無論對當事者還是對公開事故都共通的結論。
出處（公開記錄）
本文的事實依據以下公開資訊。我們不涉及攻擊的重現步驟或酬載，只聚焦於 防禦的教訓。
- Krebs on Security「What We Can Learn from the Capital One Hack」(2019) — krebsonsecurity.com
- ACM Transactions on Privacy and Security「A Systematic Analysis of the Capital One Data Breach」— dl.acm.org
- CyberScoop「US financial regulator fines Capital One $80 million over data breach」(2020) — cyberscoop.com
- Capital One 官方新聞稿（向 SEC 提交的 8-K, 2019） — sec.gov
接下來閱讀
- 術語：什麼是 SSRF（含本事故的入口與檢核的坑）
- 事故：一個被放任的 CVSS 10.0 終被利用的故事（個人開發的案例）
- 對策：把最小權限與機器監控納入日常維運
FAQ
QCapital One 事故的根本原因是什麼？
並非單一原因，而是多層防禦接連失守。入口是一個 SSRF 缺陷——能讓伺服器代為向任意目標發起請求。攻擊者藉此抵達雲端的中繼資料服務端點，而其後掛載的 IAM 角色又擁有過大權限，因此用臨時憑證就能讀出整個儲存空間。只要其中任意一層正確閉合，損失就會被止住。
Q我自己的小型服務也會受影響嗎？
會。SSRF 往往誕生於「接收一個 URL 並去抓取」「代為取得圖片或 Webhook」這類司空見慣的功能。只要你跑在雲上，從中繼資料服務端點竊取憑證這件事，不分規模都可能發生。本文的三項對策（IMDSv2、IAM 最小權限、出站目標白名單）對個人開發同樣有效。
Q只要部署了 WAF（Web 應用程式防火牆）就能防住嗎？
不能。在這起事故裡，恰恰是充當 WAF 角色的元件本身成了 SSRF 的跳板。WAF 只是攔截「某些」攻擊的一層，設定失誤反而會變成漏洞。「有 WAF 所以安全」是一種誤解；入口檢核、最小權限、中繼資料保護這樣的多層防禦才是正解。