Google／官方：加納、塞拉利昂、美屬薩摩亞三個國家頂級域遭騎劫——黑客竄改 DNS 騙取多個 Google 網域及全球大品牌 HTTPS 憑證；Chrome 以 CRLSet 封鎖，籲域名持有人監察 CT 日誌、發布限制性 CAA 記錄

重點摘要

Google Chrome 安全團隊於香港時間十月六日晚發文披露，上周發現加納（.gh）、塞拉利昂（.sl）及美屬薩摩亞（.as）三個國家及地區頂級域（ccTLD）遭第三方騎劫。攻擊者竄改相關網域的權威 DNS 記錄，藉此通過自動化網域控制驗證，騙取多個 Google 網域以及「數個全球大品牌與廣泛使用的網上服務」的未授權 HTTPS 憑證。

Google／官方：加納、塞拉利昂、美屬薩摩亞三個國家頂級域遭騎劫——黑客竄改 DNS 騙取多個 Google 網域及全球大品牌 HTTPS 憑證；Chrome 以 CRLSet 封鎖，籲域名持有人監察 CT 日誌、發布限制性 CAA 記錄

Google Chrome 安全團隊於香港時間十月六日晚發文披露，上周發現加納（.gh）、塞拉利昂（.sl）及美屬薩摩亞（.as）三個國家及地區頂級域（ccTLD）遭第三方騎劫。攻擊者竄改相關網域的權威 DNS 記錄，藉此通過自動化網域控制驗證，騙取多個 Google 網域以及「數個全球大品牌與廣泛使用的網上服務」的未授權 HTTPS 憑證。

Google 表示事件不涉及其自身系統被入侵，亦無理由相信簽發憑證的憑證機構有任何過失；Chrome 已透過 CRLSet 即時封鎖已識別的未授權憑證，並聯同簽發機構撤銷涉及 Google 的憑證。不過官方明言，瀏覽器端攔截不應被視為唯一防線，呼籲域名持有人全面監察憑證透明度（CT）日誌，並發布限制性的 CAA 記錄。本文內容已核對 Google 官方網誌原文及 Ars Technica 報道，來源真實性已驗證。

三個國家頂級域遭騎劫：黑客竄改 DNS 騙出 Google 及多個大品牌 HTTPS 憑證，Chrome 緊急封鎖並籲企業監察 CT 日誌

HTTPS 憑證是整個網絡信任體系的基石：瀏覽器看到一張由受信任機構簽發、綁定 google.com 的憑證，便會相信自己連上的是真正的 Google。這次事件可怕之處在於，攻擊者並沒有攻破 Google，也沒有攻破任何憑證機構，而是從更上游的「頂級域註冊局」入手，令一切驗證程序看起來完全合規。

一、事件經過：從註冊局下手，令驗證「合法地」出錯

技術細節

根據 Google Chrome Secure Web and Networking Team 發表的〈Chrome's Response to Recent ccTLD Registry Hijacks〉，事件要點如下：

  • 受影響範圍：.gh（加納）、.sl（塞拉利昂）及 .as（美屬薩摩亞）三個 ccTLD 遭第三方騎劫，令任何以這三個後綴結尾的網域都處於風險之中。
  • 攻擊手法：攻擊者修改了選定網域的權威 DNS 記錄（Ars Technica 補充，亦包括名稱伺服器委派），從而通過憑證機構的網域控制驗證（DCV），取得未授權的 HTTPS 憑證。
  • 受害者：涵蓋「數個 Google 網域」，以及其後透過 CT 日誌發現的其他機構，包括「數個全球領先品牌及廣泛使用的網上服務」。Google 未有點名其他受影響機構，亦未公布涉事憑證的數量。
  • 責任界定：Google 指事件並非其系統遭入侵；基於攻擊性質，亦「沒有理由相信」簽發憑證的機構做錯了甚麼。

Chrome 的應對

Google 表示，按慣常事故應變程序，Chrome 即時透過 CRLSet（Chrome 內建、可快速推送的憑證封鎖清單）阻止涉及 Google 的未授權憑證，並與簽發機構合作撤銷憑證，以保護 Chrome 以外的客戶端用戶。初步處理後，CT 日誌數據顯示更多機構相信受同一批攻擊波及，Chrome 遂主動封鎖這些憑證，並在可行情況下通知受影響機構。官方強調，Chrome 用戶毋須採取任何行動。

二、技術原理深度解析

為何控制 DNS 就等於控制憑證？

大部分公開 HTTPS 憑證採用自動化網域驗證：憑證機構要求申請人在 DNS 加入指定 TXT 記錄，或在網站特定路徑放置驗證檔案，以證明「控制」該網域。一旦攻擊者掌握了頂級域註冊局，便可改寫下層網域的權威記錄或名稱伺服器委派，把驗證流量導向自己。對憑證機構而言，一切流程都符合規範，簽發出來的卻是落入攻擊者手上的「真」憑證。

這正是 Ars Technica 所說的「憑證簽發是信任鏈中的薄弱一環」。持有這類憑證，攻擊者便可在加密層面冒充受影響服務，配合流量劫持進行中間人攻擊。Ars 亦提到，二零一一年荷蘭憑證機構 DigiNotar 遭入侵，攻擊者曾為 google.com 等逾二百個高流量網域偽造憑證，並用於針對至少三十萬名與伊朗有關的用戶；不同的是，今次問題出在 DNS 上游，而非憑證機構本身。

CT 日誌與 CAA：兩道企業自己能掌握的防線

  • 憑證透明度（CT）：Chrome 信任的公開憑證都必須登錄公開 CT 日誌。持續監察 CT，等於每當有人為你的網域簽發憑證，你都能接近實時收到警示。Google 建議監察範圍要覆蓋整個域名組合，包括閒置或地區性 ccTLD 網域；持有 .gh、.sl 或 .as 網域者應即時檢查近期 CT 記錄有否不明簽發。
  • 限制性 CAA 記錄：CAA（RFC 8659）讓域名持有人聲明哪些憑證機構可為其網域簽發憑證。Google 坦言 CAA 無法在 DNS 被騎劫期間阻止簽發，但在恢復 DNS 控制權後極為關鍵：由於憑證機構可快取並重用已完成的網域驗證結果，攻擊者或可在騎劫結束後利用快取繼續簽發。若配合 RFC 8657 把簽發限於指定 ACME 帳戶及驗證方式，便能堵住這個缺口。

長遠方向：縮短憑證有效期與驗證重用期

Google 表示會透過 Chrome Root Program 及新的 Chrome 抗量子根程式，推動縮短憑證有效期及網域驗證重用期。按 CA/Browser Forum 的 SC-081v3 決議，公開 TLS 憑證最長有效期由三百九十八日分階段縮減至四十七日，網域驗證資料重用期最終縮至十日，時間表由二零二六年三月起至二零二九年三月完成。驗證重用期愈短，攻擊者利用舊驗證結果的空間就愈小。

三、日常應用場景

1. 開發者與技術團隊

應把 CT 監察納入日常運維：可使用 CT 監察服務或自建告警，對所有正式、測試及行銷用網域設定通知。同時檢查 DNS 是否已發布 CAA 記錄，並盡量以 accounturi 及 validationmethods 參數把簽發權限鎖定到團隊實際使用的 ACME 帳戶。

2. 企業與隱私敏感行業

銀行、電商及 SaaS 營運者往往為不同市場註冊大量 ccTLD 網域，其中不少長期閒置、無人看管。今次事件說明，風險不一定來自自己的系統，而可能來自註冊局這類第三方。企業應盤點全部網域資產，評估各後綴註冊局的安全記錄，並為關鍵網域啟用註冊商鎖定等措施。

3. 一般用戶

Google 指 Chrome 用戶已自動受保護，毋須行動；但官方同時承認無法保證已找出所有受影響網域，而 Chrome 的攔截亦不能可靠保護非 Chrome 用戶。使用其他瀏覽器或 App 的用戶，應保持軟件更新，並對異常登入提示保持警覺。

4. 香港與亞洲市場視角

香港企業拓展東南亞、非洲及太平洋市場時，常為品牌註冊當地 ccTLD 網域。這類為地區市場而設、流量不高的網域往往不在資訊保安團隊的監察清單內，卻同樣可被用作冒充品牌、騙取憑證。本站較早前亦報道根區金鑰將於十月十一日更換，DNS 信任鏈相關議題接連浮現，香港機構不妨借此一併檢視 DNSSEC、CAA 與 CT 監察的設定。

四、專業評價與潛在考量

優勢

  • CT 日誌再次證明其價值：Google 正是靠 CT 數據，在初步處理後找出其他受影響機構並主動封鎖。
  • CRLSet 讓 Chrome 能繞過傳統撤銷流程的延誤，快速保護大量用戶。
  • 官方給出具體、可執行的防禦建議（CT 監察、限制性 CAA、ACME 帳戶綁定），企業可即時落實。

需要留意的地方

  • Google 未公布其他受影響機構名單及憑證數量，亦未交代攻擊者如何攻破三個註冊局，外界難以評估實際影響。
  • Google 明言不能保證已找出所有受影響網域；未被發現的憑證仍構成威脅。
  • CAA 無法在騎劫進行期間阻止簽發，CT 監察亦屬事後偵測，兩者都只能縮短而非消除風險窗口。
  • 事件凸顯網絡信任仍依賴大量資源參差的第三方註冊局，單一機構難以獨力防範。

結語

這宗事件的教訓是：即使自己的伺服器、憑證機構與瀏覽器都沒有出錯，只要上游註冊局失守，攻擊者仍可取得「合規」的 HTTPS 憑證。Google 已出手封鎖，但它亦清楚表示瀏覽器只是最後一道防線，真正能及早發現問題的，是持續監察 CT 日誌與正確設定 CAA 的域名持有人。隨着憑證有效期與驗證重用期持續縮短，企業的憑證自動化與監察能力只會愈來愈重要。

如需為企業網域組合建立 CT 監察、CAA 與 DNS 安全設定，或規劃零信任架構與雲端遷移，可參考 YSK Limited 的雲端遷移與網絡安全服務（高可用架構目標 99.99% uptime，https://ysk.hk/services/cloud-security）；若團隊缺乏人手處理日常運維與憑證自動化，亦可了解 HK$2,000／月起的遠端開發者外判計劃（https://ysk.hk/services/outsourcing）。

參考來源

延伸閱讀 · 相關服務與產品

相關文章