安全事故与漏洞
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 所以安全」是一种误解；入口校验、最小权限、元数据保护这样的多层防御才是正解。