跳至主要內容
ITD網站資安平台
ITD
搜尋

資安事件與漏洞

危急#SSRF#雲端#IAM#AWS#企業外洩

Capital One 資料外洩事件（2019）— SSRF 如何導致 1 億人資訊外洩及防禦之道

2019 年 Capital One 約 1 億 600 萬人的申請資料外洩，入口是 SSRF。攻擊者經中繼資料服務取得權限過大的 IAM 憑證並複製 S3。說明如何防止重演：IMDSv2、IAM 最小權限與出站白名單。

發布於 2026-06-07 更新於 2026-10-05 閱讀時間 4 分鐘
本頁內容

我們解讀真實發生過的公開事故，但視角不是新聞的重播，而是「在你的環境裡該如何防住」。本文是 基於公開記錄（主管機關、報導、學術分析、官方公告）的解讀。出處在文末註明。

1.06億
受影響人數（美·加）
約14萬
社會安全號碼(SSN)
$80M
美國 OCC 罰款
IMDSv2
此事故推動其推出
事故摘要 / CASE FILE
對象
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)管控＋偵測異常的大量讀取

每一步都有機會被攔下。縱深防禦是指設置好幾個能攔下攻擊的地方，而不是只依賴單一控制。

已公布的時間軸

  1. 2019-03

    雲端環境遭到非法存取（後來才查明）。

  2. 2019-07-17

    外部舉報（GitHub 上的貼文）指出異常。

  3. 2019-07-19

    Capital One 透過內部調查確認遭入侵。

  4. 2019-07-29

    對外公布。一名前 AWS 工程師的嫌疑人被 FBI 逮捕。

  5. 2019-11

    AWS 發布 IMDSv2，作為針對 SSRF 的多層防禦。

  6. 2020-08

    美國 OCC 處以約 8,000 萬美元罰款，指出其在遷移上雲之前的風險評估存在缺失。

根本原因：好幾層防禦同時欠缺

把這起事故歸結為「SSRF 的錯」，就會重演。實際上其本質是 三層接連崩塌。

崩塌的構成（事故當時）

  • 入口處不檢核出站目標（可向任意目標代為發起請求）
  • 中繼資料服務端點無需權杖就回傳憑證（舊方式）
  • 機器的 IAM 角色擁有可大範圍讀取儲存空間的過大權限

守住的構成（杜絕重演）

  • 把出站目標限定為白名單方式，拒絕對內部位址的代為存取
  • 中繼資料採用 IMDSv2：強制工作階段權杖＋跳數限制，阻斷代為抵達
  • IAM 角色採用最小權限：只給所需儲存貯體上所需的操作

責任共擔：雲端使用方必須自行保護的部分

雲端一方負責底層基礎設施的安全，但修復 SSRF、設計 IAM 權限、保護中繼資料是使用方的責任。這起事故被處罰的理由也是「遷移上雲之前的風險評估存在缺失」。使用雲端本身並無問題；重要的是，屬於你責任的部分是否已徹底設計到位。

在你的環境中杜絕重演

以下是無論規模大小都奏效、按優先順序排列的對策。只要你有哪怕一個「接收 URL 並去抓取」「代為取得 Webhook 或圖片」的功能，這就是你自己的事。

1

把出站目標改為「白名單方式」（在第一步就擋下 SSRF）

對於伺服器代為存取使用者提供的 URL 的處理，要限定為僅限已許可的目標。對內部位址（中繼資料服務端點或私有網路）的抵達預設拒絕。SSRF 詞條裡彙總了檢核時容易漏掉的坑（跟隨重新導向、DNS 重新解析等）。

2

對中繼資料強制使用 IMDSv2

把雲端的中繼資料服務端點限定為強制權杖、帶跳數限制的新方式（AWS 上即 IMDSv2）。僅此一項，就能讓從 SSRF 竊取憑證的難度大幅提升。要點是停用舊方式。

3

把 IAM 角色設為最小權限（限制損害）

為了在憑證萬一外洩時把損害控制在有限範圍，給機器或服務掛載的權限要收緊到只給所需對象上所需的操作。「先一股腦給儲存空間全權限」會把一次入侵變成全量資料外洩。

4

準備好出口(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

接下來閱讀

FAQ

QCapital One 事故的根本原因是什麼？
A

並非單一原因，而是多層防禦接連失守。起點是一個 SSRF 缺陷——能讓伺服器代為向任意目標發起請求。攻擊者藉此抵達雲端的中繼資料服務端點，而其後掛載的 IAM 角色又擁有過大權限，因此用臨時憑證就能讀出整個儲存空間。只要其中任意一層正確閉合，損失就會被止住。

Q我自己的小型服務也會受影響嗎？
A

會。SSRF 往往誕生於「接收一個 URL 並去抓取」「代為取得圖片或 Webhook」這類司空見慣的功能。只要你跑在雲上，從中繼資料服務端點竊取憑證這件事，不分規模都可能發生。本文的三項對策（IMDSv2、IAM 最小權限、出站目標白名單）對個人開發同樣有效。

Q只要部署了 WAF（Web 應用程式防火牆）就能防住嗎？
A

不能。在這起事故裡，恰恰是充當 WAF 角色的元件本身遭到 SSRF 濫用。WAF 只能攔截某些類型的攻擊，設定錯誤時反而會成為弱點。「有 WAF 所以安全」是一種誤解；同時還需要輸入檢核、最小權限與中繼資料保護。