eMudhra 8 個弱金鑰被追蹤利用與修補情形

於 2026 年 10 月 19 日，我們得知 eMudhra 的八把驚人之弱金鑰：當 eMudhra 被信任為保護網際網路的虛擬組合鎖選擇一個 115 位數字時，他們卻選擇了數字 4。甚至連四位數都沒有，只是數字 4。其餘七把金鑰同樣脆弱：56、66、115、155、156、230 和 237.

次日，我們撰寫了一篇部落格文章 說明我們為減緩此洩漏所採取的立即行動，以及客戶在他們那邊需要做 以保持安全。現在，我們將分享更深入的後續，說明我們所見的利用證據以及訪客修補系統的進展。

先從問題的規模說起。這麼嚴重的弱金鑰證書授權機構（CA）前所未有，其潛在後果亦相當重大。雖然過去曾有大量被盜用的證書授權機構（如 DigiNotar、TÜRKTRUST 和 TrustWave），但對其金鑰的存取始終受到一定程度的限制；這些事件僅允許有限的攻擊者或組織發行偽造證書。eMudhra 的事件則完全不同；受影響的中間私鑰可幾乎瞬間由 任何人 從公開證書本身恢復。任何人都能獨立恢復這些相同的簽名金鑰，並為任何未修補且未執行證書透明度的客戶端所接受的網域簽發證書。

eMudhra 宣佈 他們將退出公眾 CA 業務，並聲稱在一個金鑰產生指令碼中犯了 錯誤 ，但尚未公開該指令碼。他們 簽署 了一份證書撤銷清單（CRL），其簽署金鑰可能是正確生成的，之後又改為用弱金鑰簽署。

這是如何發生的，為何沒有引發警報？許多問題需要澄清，包括審計員和交叉簽署者的角色。 本篇部落格提出修復方案與後續步驟，協助組織確保安全。

修補 Cloudflare

我們的主要關注仍是對 Cloudflare、客戶及整個網際網路的安全影響。撰寫時，所有高優先順序 Cloudflare 系統已完成修補。正在處理少量已確認低影響的工單。

我們於 2026 年 10 月 19 日即時開始修補高影響系統。這些系統包括使用 Pingora 的客戶原始端代理，負責我們大部分的出站連線。這些系統在數小時內完成修補，拒絕弱的 eMudhra 金鑰。與此同時，我們啟動了 AI 助手對原始碼的分析，以找出所有信任這些弱金鑰的其他系統。四小時內完成完整分析。我們為每個系統分配了一張工單，並要求團隊在當日結束前確認並／或調整分析結果。若發現高影響，我們即時要求修補；對於低影響，修復工作於上週結束時完成。

Cloudflare 是否在其網路中見到利用？

為了追蹤客戶的伺服器（或攻擊者）呈現由 eMudhra 弱金鑰簽署的證書，我們在 Pingora 加入了日誌紀錄。由於此出站服務佔 Cloudflare 機器大部分的 TLS 連線，任何試圖使用 eMudhra 金鑰竊聽的攻擊者都會觸發此日誌。日誌於 10 月 21 日完成上線。

撰寫時，已過一週，我們觀測到約 22,000 次使用弱 eMudhra 金鑰的握手嘗試。兩成三的嘗試是對測試站點的抓取，例如 emudhra.we-have-a-problem.com（我們在前一篇開發者指引中已 提及）。剩餘的大部分則發往看似自行使用弱中介憑證設定證書的原始伺服器。所有已設定驗證證書的握手都被拒絕，因為我們已經修補。

約 160 次握手引人注意：證書的主體別名（SAN）列出了其他組織的域名，與握手中請求的伺服器名稱指示（SNI）無關。其中一些域名屬於消費者 IoT 裝置。我們還注意到，這些偽造證書是在金鑰洩露後生成的，且部分有效期超過兩年，超出任何公開 CA 的授權期限。然而，這些證書看起來更像是伺服器自己的預設證書，而非試圖攔截我們連線的嘗試。它們命名的域名與實際連線的域名不同，理應已經失敗主機名稱驗證。且在多個案例中，伺服器向來自多個我們位置的連線呈現相同證書，表明證書來源於伺服器本身，而非單一路徑上的某物。

因此，迄今為止尚無證據顯示弱金鑰被用來攔截 Cloudflare 的連線，但這些金鑰似乎在漏洞公開後數小時內已被用來偽造證書：我們看到的一個偽造證書日期為 10 月 20 日 18:19 UTC，距 Mozilla 公開漏洞報告不到一小時。這並不排除精準針對的攔截。對此，我們必須依賴常見的系統妥協間接訊號——迄今為止，我們尚未見到任何此類訊號。

仍有多少訪客處於脆弱狀態？

雖然我們已大量修補 Cloudflare，但訪客呢？若不破壞連線，我們無法直接測試訪客是否仍信任弱金鑰，因此必須採取更間接的方法。為此，我們利用了 挑戰頁面：

我們推出更新，在部分挑戰頁面傳送兩個探測連線：一個探測連線至 ca1.cloudflarecaptcha.com，另一個至 ca2.cloudflarecaptcha.com。最初，我們在 ca1.cloudflarecaptcha.com 安裝了 eMudhra 簽署的證書，在 ca2.cloudflarecaptcha.com 安裝了常規簽署的證書作為對照。接著記錄這些探測是否成功。這樣即可判斷收到挑戰頁面的訪客是否仍信任弱 eMudhra 金鑰。

我們發現了什麼？在過去一週內 5,000 萬次探測中，我們看到：

先說一個大前提：按設計，流量至這些挑戰頁面高度偏斜。裡面有許多（未確認）機器人。此外，只有執行 JavaScript（如瀏覽器）的客戶端才會傳送探測。

資料跳升的原因是以下變更——所有時間均為 UTC：

• 10 月 23 日 15:30，我們將控制端點改為同時提供 eMudhra 證書，但這一次不包含 signed certificate timestamps（SCTs）。接受度有些差異，但不大。我們本可新增一個端點，但那需要慢速發布挑戰平臺。改動端點較為簡單。
• 10 月 23 日 16:30，我們的挑戰平臺因不相關問題回滾至舊版。探測器於 10 月 27 日 10:00 回傳。
• 10 月 27 日 16:37，我們發現未送出 G3 cross-sign，並非所有客戶端都知道，於是將其加入兩個端點。並從兩者移除 SCTs。
• 10 月 27 日 16:49，我們將 ca2 切換至連結至 AAA Certificate Services 根。
• 10 月 27 日 18:18，我們將探測器比例提升至 1% 至 10%，涵蓋所有在非付費客戶區域提供的挑戰頁面。

在排除上述條件後：我們注意到什麼？現代瀏覽器已大多更新補丁，但機器人與舊版瀏覽器尚未。嵌入式瀏覽器，例如 Android WebView，補丁落後，仍有 30–40% 接受。首個週末（監控缺口期間）我們看到明確的補丁證據，之後則幾乎無變化。

10 月 29 日約 18:00 UTC，我們發布了偵測，可捕捉大量偽裝為 macOS 上 Chrome 150-154 的機器人流量。這在上圖看似補丁效果，但實際上是流量分類變更：相同使用者代理在下圖中，偵測到機器人訊號的流量接受度相應上升。

Linux 上的 Chrome 150-154 是顯著例外：其接受度持續下降，與該群體進一步補丁一致。考慮到機器人佔比高且流量變化，該證據僅具指示性，非決定性。否則，我們仍見不到明顯變化。

按網路（ASN）拆分，我們看到：

在大型網路中，超過一半的探測器仍接受受損鏈，無論是未偵測到機器人訊號的流量（上圖）或偵測到機器人訊號的流量（下圖）。週末時我們見到部分補丁，但之後趨勢保持平穩。

主要留意仍在：流量被（未確認）機器人偏斜。但機器人同樣是需要安全更新的軟體。若它們以任何方式代表整體軟體更新，情況就相當嚴峻。

你可以做什麼？

補丁！Dennis Jackson 有一個很棒的 crowdsourced website，提供說明。若你是 macOS 開發者，請參考 these instructions。若你是 Cloudflare 客戶，請閱讀上週的部落格文章，瞭解 what needs to be done on your end，在使用 WARP 或 Tunnel 等產品時。

展望未來

在 Cloudflare，我們在某些產品中已經實作了快速撤銷機制。為了將其推廣到更多 Cloudflare 內部及產業系統，我們對像 upki 這樣的專案感到興奮，因為它瞭解信任儲存並非只能是靜態的根憑證授權機構清單，而需要能夠快速更新撤銷資訊與憑證透明度金鑰。隨著漏洞被發現的速度比以往更快，能夠迅速且有效地處理它們變得至關重要。