CVE-2026-8863：拆解 Secure Boot 繞過漏洞，微軟簽名 bootloader 反成木馬屠城記

呢批有漏洞嘅 bootloader 之所以仲喺現實世界存在，係因為好多硬件同軟件廠商，當年拎咗開源嘅 shim 去開發自己嘅產品，但之後就一直冇幫佢哋做更新。安全公司 Positive Technologies 就搵到咗一批受影響嘅特定產品，包括 WhiteCanyon WipeDrive（硬碟清除工具）、Baramundi Management Suite（系統管理套件）、PC-Doctor Service Center（硬件診斷工具），同埋芬蘭嘅 Matriculation Exam Abitti 考試系統 。呢啲第三方工具，會將佢哋嗰個老舊但有微軟簽名嘅 shim 裝咗喺 EFI 系統分割區（EFI System Partition）入面。就算你之後將主系統嘅保安更新做到足，呢個「歷史遺留」嘅 bootloader 都會成為一個永久嘅後門 。

攻擊手法：Bootloader 版嘅「自帶漏洞驅動程式」

要利用 CVE-2026-8863 漏洞，並唔係遙距攻擊咁簡單。黑客首先需要獲得目標電腦嘅管理員權限，或者有能力修改開機流程 。一旦攞到呢種存取權限，就可以玩一招類似「自帶漏洞驅動程式」（Bring Your Own Vulnerable Driver, BYOVD）嘅手法。只不過，今次帶嘅唔係驅動程式，而係將一個有問題、但又合法（有微軟簽名）嘅 shim bootloader，放入去開機路徑度。

當系統喺開咗 Secure Boot 嘅情況下啟動，UEFI 韌體會檢查呢個 shim 嘅數碼簽名。佢會發現個簽名冇問題（係由受信任嘅 Microsoft UEFI CA 2011 證書簽發嘅），於是就會照執行 。黑客就可以利用呢個老舊嘅 shim，將開機流程綁架，喺 Windows 或者任何保安軟件都未初始化之前，載入惡意 payload。咁樣，黑客就可以喺電腦啟動嘅最早階段，獲得完整嘅系統控制權，亦即係所謂嘅**「開機前任意代碼執行」**嘅狀態 。

開機前執行程式碼嘅風險：難以清除嘅頑固感染

呢種「開機前代碼執行」嘅能力，正正對應到 MITRE ATT&CK 框架入面嘅攻擊技術 T1542.003 — Pre-OS Boot: Bootkit（開機前啟動：Bootkit） 。Bootkit 係一種惡意軟件，佢嘅運作層級低過作業系統，可以提供一種極之隱蔽嘅持續感染（persistence）機制。就算你重裝作業系統，佢一樣可以存活落嚟，而且可以避過絕大部分傳統防毒軟件嘅偵測 。

如果黑客透過 CVE-2026-8863 攻擊成功，就可以做到以下嘅嘢：停用 BitLocker 硬碟加密、將惡意代碼注入作業系統核心（kernel），或者建立一個每次開機都會執行嘅持久性後門。要徹底清除 bootkit 感染係極之困難嘅事，好多時都需要將系統嘅韌體完全重刷一次先搞得掂。所以，就算呢個漏洞需要本機存取權限先可以利用到，對企業安全團隊嚟講，佢嘅威脅級別依然好高。Rapid7 嘅評估報告將呢個漏洞嘅 CVSS v3.1 基本分數評為 7.8 分，並將其利用可能性歸類為「較低」，不過佢對系統嘅機密性、完整性同可用性所造成嘅技術影響，就被評定為「高」 。

UEFI 信任問題嘅歷史輪迴

CVE-2026-8863 並唔係單一事件，而係保護 UEFI 開機流程呢場長期戰爭中嘅最新一集。佢嘅攻擊手法，同 2020 年嘅「BootHole」漏洞（CVE-2020-10713）非常相似。當年 GRUB2 嘅漏洞同樣容許繞過 Secure Boot，需要一次大規模嘅 DBX 更新先修復到 。之後仲有「BlackLotus」bootkit，佢利用咗 Windows bootloader 嘅漏洞，達到類似嘅開機前持續感染效果 。

今次嘅情況仲更加複雜，因為同期仲發生緊大規模嘅信任憑證到期事件。幫呢批有問題嘅 shim 同無數其他第三方組件簽名嘅 Microsoft Corporation UEFI CA 2011 證書，本身將於 2026 年 6 月 27 日到期 。微軟一路都喺度推動成個生態系統，遷移到 2023 年嗰批新證書。呢個係一個好複雜嘅操作，當 CVE-2026-8863 被公布嘅時候，好多機構嘅遷移工作都仲係進行緊 。

補救措施同企業部署注意事項

要修復 CVE-2026-8863，並唔係一個簡單嘅 Windows Update 就搞得掂。最核心嘅緩解措施，係進行一次UEFI 禁用簽名資料庫（DBX）更新，將嗰批有問題嘅 shim bootloader 嘅加密雜湊值（cryptographic hashes），加入到韌體嘅吊銷清單（revocation list）入面。一旦套用咗呢個更新，UEFI 韌體就會拒絕執行呢啲 bootloader，就算佢哋個數碼簽名係有效嘅都冇用 。

對企業 IT 同安全團隊嚟講，部署 DBX 更新需要仔細規劃：

1. 先喺測試環境試行 DBX 更新： 將更新部署到一個非生產環境嘅測試群組，確保封鎖咗舊版 shim 之後，唔會搞到啲重要系統開唔到機。尤其要留意嗰啲可能暗中依賴咗受影響第三方 bootloader 嘅系統 。
2. 審計第三方 Bootloader： 用資產盤點工具掃描所有 EFI 系統分割區，檢查有冇嗰啲存在漏洞嘅 bootloader。將掃描結果同 Positive Technologies 公布嘅產品清單做對比，包括用嚟清除硬碟、管理系統同診斷硬件嘅工具 。
3. 檢查雙系統同 Linux 機器： 裝咗 Windows 同 Linux 雙系統嘅電腦，特別係用緊舊版 Linux 發行版嘅，喺套用 DBX 吊銷更新之後，好大機會會鎖死開唔到機。部署前，一定要確保所有安裝咗嘅 Linux 發行版，都已經遷移到最新、冇漏洞嘅 shim bootloader 。
4. 同軟件廠商協調： 聯絡任何被搵到嘅受影響 bootloader 嘅廠商（例如 WhiteCanyon 或 Baramundi），喺封鎖舊版 bootloader 之前，向佢哋索取已更新、兼容 Secure Boot 嘅工具版本 。
5. 準備好 BitLocker 恢復密鑰： 任何對 Secure Boot 設定嘅變更，都有可能觸發 BitLocker 恢復密鑰嘅提示。喺部署 DBX 更新之前，要確認所有恢復密鑰都有備份，而且技術支援團隊可以存取到，避免出現大規模嘅鎖機災難。
6. 用「更新圈（Update Rings）」分階段推出： 採用分階段方式，由 IT 部門開始，再到試點用戶，最後先至廣泛部署。喺每個階段，都要密切監察有冇出現開機完整性嘅問題。

CVE-2026-8863 漏洞係一個好強烈嘅提醒：Secure Boot 嘅保護能力，完全取決於佢信任嘅第三方簽名代碼生態系統有幾咁穩健。企業要持續咁審查開機前環境，同埋手腳快啲套用 DBX 吊銷更新，已經成為維護平台完整性嘅必要工作。