安全事故与漏洞
Equifax 信息泄露事件（2017）——未打补丁的 Apache Struts 导致 1.47 亿人泄露的原因与防御
2017 年，信用信息巨头 Equifax 泄露了约 1.47 亿人的个人信息。原因是已经发布了修复补丁的 Apache Struts 已知漏洞（CVE-2017-5638／CVSS 10.0），没有被应用到公开系统上。更糟的是，监控设备因证书失效而停摆，导致长达 76 天都没能察觉数据被持续外带。已知 CVE 被放任、资产盘点不足、检测出现空白这三处崩塌，本文只用公开记录的事实，讲解如何用补丁 SLA、资产清单、机器监控等具体手段，让它不在你的环境里重演。
回顾真实发生过的公开事故，不是重播新闻，而是从 「在你的环境里如何防御」 的视角来解读。本文是 基于公开记录（监管机构、官方公告、Apache Software Foundation、报道）的解说。出处在文末注明。
- 对象
- Equifax（美国信用信息巨头）
- 公布
- 2017 年 9 月 7 日（入侵 5 月～7 月／发觉 7 月 29 日）
- 手法分类
- 利用已知 CVE（Apache Struts RCE）未应用，进行入侵与对外带出
- 影响规模
- 美国约 1.47 亿人（姓名、SSN、出生日期、住址等。部分信用卡号也在内）
- 根本原因
- 放任已知 CVE ＋ 缺乏资产清单 ＋ 检测空白（证书失效）
- 真正的对策
- 补丁 SLA、资产盘点、机器监控、检测健全性
发生了什么（通俗版）
Equifax 运营着一个供用户对信用信息提出异议的在线申诉窗口。它的底层使用了一个名为 Apache Struts 的组件，而该组件被发现存在一个 可以从外部执行任意代码 的严重漏洞（CVE-2017-5638）。
修复补丁在 漏洞公布的同一天（2017 年 3 月 7 日） 就已发布。然而，目标的申诉系统 一直没有打上补丁而被放任。攻击者在两个月后的 5 月，利用这个已知的窟窿入侵，并在内部网络中横向移动，带出了大量个人信息。
更糟的是，监控通信的设备 因证书失效而长期停摆，导致异常的外带活动 76 天 都没能被检测到。7 月 29 日刚更新证书，可疑通信便立刻显现而被发觉——本应用来察觉的机制，竟然是停着的。
本质不是『高难度的攻击』，而是『没打补丁』
这次事故所利用的，是一个全球早已公开、补丁也已发布的已知窟窿。造成损失的不是攻击的高级程度，而是缺少『在规定时间内堵住已知危险的运维』。无论是个人开发还是组织，这都会以同样的结构发生。
这条连锁也是一张『防御地图』
重要的是，这是一条 五跳 的连锁，而 每一跳都有可以拦下的地方。请不要把它读成攻击步骤，而要读成 哪里本可以被切断。
① 已知 CVE 公开（修复补丁同日发布）
⊘ 拦截点：用机器监控即时检测『与自己相关的 CVE』
② 公开系统一直未应用而被放任
不掌握 Struts 在哪里运行，漏出了修复的网。
⊘ 拦截点：资产清单 ＋ 补丁 SLA（公开→应用的期限）
③ 通过 RCE 入侵
从未应用的窟窿以任意代码执行获得立足点。
⊘ 拦截点：最小权限・WAF 作为『辅助』并用
④ 在扁平网络中横向移动并大量外带
隔离薄弱，一处被攻陷便波及到广域数据。
⊘ 拦截点：用网络隔离缩小爆炸半径
⑤ 监控证书失效，76 天无法检测
本应用来察觉的设备停着。
⊘ 拦截点：把证书・监控的健全性检查养成习惯
已公布的时间线
2017-03-07
CVE-2017-5638 公布。同日发布修复补丁。2017-03～
公司内部发出告警。但目标的申诉系统仍未应用。2017-05～07
攻击者利用未应用的窟窿入侵，带出数据。2017-07-29
刚更新监控设备的证书，便检测到可疑通信而被发觉。2017-09-07
对外公布。查明约 1.47 亿人受影响。2019-07
与 FTC・CFPB・各州以最高约 7 亿美元达成和解（美国史上最大规模）。
根本原因不只是『一处未应用』
如果停留在「忘了打补丁」上，就会重演。实际上，本质是 多个层连续崩塌。
崩塌的配置（事故时）
- 放任已知 CVE（修复已发布，却没应用到公开系统）
- 缺乏资产清单（不掌握组件在哪里运行）
- 扁平网络（允许横向移动、数据波及）
- 检测空白（监控设备因证书失效而长期停摆）
守住的配置（防止重演）
- 补丁 SLA：定下从公开到应用的时限，优先处理 KEV／高 CVSS
- 资产清单：用机器掌握依赖与运行位置，不让它漏出修复的网
- 网络隔离：缩小被攻陷后的爆炸半径
- 检测健全性：定期确认证书・监控的存活
『打补丁』不是一次性作业，而是运维
关键不是「将来某天修」，而是要有「在公开后 N 小时／天以内修好」的时限（SLA）。并且，为了不遗漏该打补丁的对象，需要让机器掌握哪里在运行什么。一旦依赖人的记忆，就会像 Equifax 那样留下『仅有一台』漏网。
在你的环境里防止重演
下面是不论规模都有效、按优先级排列的对策。把「不放任已经公开的 CVE」这一点，用机制来保证。
拥有资产清单（哪里在运行什么）
把自己的依赖库，以及它们在哪些服务・容器上运行，列成清单。Equifax 最大的绊脚石就是「漏掉了目标系统」。要点在于以 实际正在运行的版本 来掌握。
定下补丁 SLA（公开→应用的期限）
先定下「重大 CVE 在公开后 N 天以内应用」的期限。尤其要把 KEV（正在被实际利用）与高 CVSS 放在最优先。有了期限，『放任』才会被可视化。
让机器去监控（不靠人力追踪）
靠人力追踪 CVE 是不可能的。用 Dependabot（GitHub）或 osv-scanner 检查锁文件，只对与自己依赖相关的 CVE 自动通知。依赖的机器监控该怎么搭建里有具体步骤。
准备隔离与检测（被踩中之后的保险）
隔离网络以抑制横向移动，并能检测异常的大量外带。把监控与证书『是否还活着』的确认也纳入运维——用来察觉的机制停着的话，就毫无意义。
本站自身也在实践同样的对策
本站自身也按这里所写的，把自己的依赖纳入 CVE 监控的对象。Equifax 的教训——用人不会疏漏的机制堵住已知的窟窿——被我们转化为产品的说服力。把「将来某天修」换成「在期限内、借助机器修好」，正是这次事故真正的收获。
出处（公开记录）
本文的事实基于以下公开信息。不涉及攻击的复现步骤或载荷，只聚焦于防御的教训。
- Apache Software Foundation「Media Alert: Equifax Data Breach Due to Failure to Install Patches」(2017) — news.apache.org
- Equifax 官方公告「Releases Details on Cybersecurity Incident」(2017) — investor.equifax.com
- CFPB/FTC/各州 和解公告 (2019) — consumerfinance.gov
- CSO Online「Equifax data breach FAQ」— csoonline.com
接下来阅读
FAQ
QEquifax 事故的根本原因是什么？
不是某种新型的高级攻击，而是『把已经发布了修复补丁的已知漏洞（Apache Struts 的 CVE-2017-5638／CVSS 10.0）没有应用到公开系统上』。再加上没有掌握那个组件究竟在哪些系统上运行，监控设备又因证书失效而停摆，导致长达 76 天都没能察觉数据被外带。
Q明明有补丁，为什么没打上？
据公开记录，修复在漏洞公布的同一天（2017 年 3 月 7 日）就已发布。公司内部也发出了告警，但目标的在线申诉系统始终没有应用补丁而被放任。『那个组件究竟在哪里运行』的资产清单不健全，使它漏出了修复的网，这是很大的原因。
Q像我这样的小规模开发也有教训吗？
有。无论规模大小，『不放任已知 CVE』『掌握自己的依赖里是否含有那个组件』『让机器去监控以消除疏漏』这三点都是一样的。靠人力追踪 CVE 是不可能的，所以让 Dependabot 或 osv-scanner 替你盯着才是现实的解法。