資安事件與漏洞
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 替你盯著才是現實的解法。