▍TL;DR
如果你已經聽說過了 CVE-2022-21894 漏洞並且及時下載了今年 5 月 9 日的 Windows 安全更新（KB5025885），你可以通過下述步驟來啟用裡面包含的修復內容：
在 Windows 中安裝 2023 年 5 月 9 日或之後的安全更新，並重啟電腦。
以管理員身份運行 cmd ，通過下面的指令手動添加新的安全引導 UEFI 黑名單（DBX）和指令完整性啟動策略（Code Integrity Boot Policy）： reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x30 /f，並重啟電腦。
開機後等待至少五分鐘以上，再次重啟電腦。
此時如果你可以在 Windows 事件查看器中找到 ID 為 1035 和 276 的事件，說明手動啟用更新成功。
需要注意的是，在手動啟用這次更新之後，所有沒有在新系統中更新過的啟動介質、官方 ISO 鏡像、廠商重裝盤、PE 啟動器等等將 全部失效， 無法開機。
▍源起：UEFI 漏洞
Windows 的啟動過程，其實比我們想像的更加複雜。
試想一下，一個程序從你按下電源鍵的那一刻便已經啟動，隨後默默的注視著每一個子程序的啟動和運行，直到你進入了 Windows 、各種默認啟動的軟體開始運行之後，它依然在默默的關注著和掌握著你所有的數據化信息。
這個自始至終默默睜著眼睛的程序，叫做 Secure Boot（安全引導），是 Windows 啟動流程中不可或缺的一環。它會在作業系統的啟動過程中仔細檢查每一項被喚醒的程序和驅動，並且會持續運行到進入作業系統的初期階段，以防止那些心懷鬼胎的程序從啟動伊始悄悄接管一些重要進程，挖穿 Windows 的牆角。
而 Secure Boot 的運行環境，則被稱作 UEFI（統一可擴展固件接口），從 Windows 8 時代開始被微軟逐步推廣，用以取代曾經沒有圖形介面、交互不方便的 BIOS 方式。
但是儘管從系統運行的如此初期就已經介入，Secure Boot 也不是無懈可擊的。早在 2021 年 12 月，就有一項 UEFI 執行流程中的漏洞被披露出來，指出系統啟動過程中的 Secure Boot 檢查是 可以被繞過的。這個漏洞最終被稱為 Baton Drop，並獲得了自己的通用漏洞披露（Common Vulnerabilities and Exposures）編號：CVE-2022-21894 。
作為銜接 Windows 與計算機硬體的橋樑，UEFI 自身就像是一個袖珍的作業系統一樣，在初始化階段會依次加載啟動分區上的各種 UEFI 應用（UEFI Applications）並最終進入 Windows Boot Manager 、由它來生成啟動環境（boot environment），進而根據情況選擇進入特殊模式還是主系統。
在正常的系統啟動過程中，Secure Boot 功能會通過加密驗證每一個啟動環節在出廠時就寫入的數字簽名來確保它們的安全性，並且直到主系統完成啟動並開始加載各種驅動和應用時都在持續工作著。按理說這樣主動且強勢的介入方式應該可以杜絕絕大多數的惡意啟動項了，然而 Baton Drop 漏洞卻指出了一條非常新穎的道路。
圖｜Microsoft
Secure Boot 功能得以運行並將惡意程序防範於未然的前提，自然是它在每一個應用啟動之前就對它們進行檢查，這就要求在 UEFI 運行時，Secure Boot 的相關代碼被優先從內存中提取出來運行、隨後才是某個特定的 UEFI 應用。
那麼如何讓 Secure Boot 策略的代碼最優先呢？自然就是讓它們所在的內存地址儘可能的「低」了——你可以將內存地址想像成一個垂直堆疊的結構，在這個結構中，電腦的運行邏輯會按照從下往上的順序進行讀取，因此內存地址越低的代碼會先於地址高的代碼執行。為了保證 Secure Boot 的安全性，微軟默認便規定了將它分配在了儘可能低的地址上，優先於任何 UEFI 應用的代碼。
而 Baton Drop 漏洞指出 Secure Boot 可以被繞過的原理，正是出在它的內存地址分配上。
作為電腦啟動的基本進程，每個 UEFI 應用也擁有一定的自主權，它們可以通過啟動配置數據（Boot Configuration Data, BCD）調整計算機的硬體，其中一個名為 turncatememory 的 BCD 會將特定地址以外的內存映射表中的代碼清除掉，用於給下一個 UEFI 應用騰出內存空間。
但如何讓原本「趴低」的 Secure Boot 代碼被 turncatememory 擊中呢？自然就是讓它的代碼被重新分配到更高地址的內存上了。對於一個惡意的 UEFI 應用來說，它可以通過人為篡改後的 BitLocker 元數據來為自己的 BCD 偽造一個具有極高可信度的來源，當 Secure Boot 的代碼識別到這個高可信度的來源後就會允許自己的內存地址被重新分配。
這時，藉助另一條名為 avoidlowmemory 的 BCD ，一個不懷好意的 UEFI 應用就有權力要求 Secure Boot 策略（在字面意義上）避開低地址、轉移到更高的內存地址上了。
至此，一個不懷好意的 UEFI 應用通過偽造的高可信度的 BCD 來源，讓原本最優先執行的 Secure Boot 策略心甘情願地「起身讓座」。
繼而以 avoidlowmemory 和 turncatememory 的組合拳清除掉執行 Secure Boot 的代碼，最終達成繞過安全引導、從啟動初期就控制計算機的效果。
▍實戰：「黑蓮花」（BlackLotus）來了
由於 Baton Drop 牽涉到了優先度和安全級別極高的 Secure Boot ，微軟封堵漏洞的辦法主要藉助了 UEFI 的黑名單機制。作為 Secure Boot 之外的另一道安全手段，UEFI 會預製一份名為 UEFI Forbidden Signature Key（簡稱為 DBX）的黑名單，每當 UEFI 在運行中識別到了某一個 UEFI 應用的二進位數字簽名與 DBX 相匹配，就會直接禁止這個應用的運行。
但是由於 Windows 本身複雜的銷售方式，這些二進位數字簽名既可能來自微軟，也可能來自銷售電腦或者主板的 OEM 廠商，或者是顯卡、網卡等等硬體的驅動程序簽名，而 DBX 獲得及時更新的唯一方式就是 Windows 升級或者 OEM 廠商提供的固件升級。為了應對 Baton Drop 這種位於 UEFI 層級的漏洞，微軟目前能做的就是將確認擁有漏洞的數字簽名添加到 DBX 裡面，再通過 Windows 更新推送給全球的用戶。
這時，一個「船大難掉頭」的問題就出來了：第三方廠商們修復漏洞推出更新的速度參差不齊，微軟不能一次性就把所有帶漏洞的數字簽名全部添加到 DBX 裡面，因為一旦這樣做了， DBX 更新後的用戶只要還在使用著沒有更新 UEFI 固件的主板或者硬體，就必然會碰到 UEFI 無法完整的執行、進而導致無法開機的問題。
果然，不久之後，這個沒有完全堵上的窟窿就引來了狼群—— 2022 年 10 月 6 日，有人開始在黑客論壇上以每份 5000 美元的價格兜售一款號稱可以繞過 Secure Boot 並且具有 Ring0 級別內核固化的 bootkit ，最終作為 HTTP 加載器讓劫持者實現 C&C（Command and Control，命令與控制）攻擊。
圖｜Bleeping Computer
這份只有 80kB 的 bootkit 就是目前發現的 第一款可以攻破最新版 UEFI Secure Boot 的惡意啟動固件——「黑蓮花」。
隨後，由捷克斯洛伐克的網絡安全公司 ESET 主導，「黑蓮花」的具體運行邏輯被解包了出來。從原理上講，它的工作過程與 HIV 有些類似，HIV 的主要攻擊目標是人的免疫系統、後續的致病致死往往是免疫系統癱瘓後各種感染引起的；「黑蓮花」則是繞過和禁用 Windows 中的各種安全組件，比如 Secure Boot、BitLocker、代碼完整性檢查（HVCI）等等，在系統完全啟動後通過引導 HTTP 遠程控制的加載來對目標設備進行攻擊或者竊取：
簡化後的「黑蓮花」攻擊流程，其主要利用的依然是一年前的 CVE-2022-21894｜ESET
簡單來說，在利用 Baton Drop 漏洞繞過 Secure Boot 之後，「黑蓮花」就可以在 NVRAM 裡面原本只讀的 MokList 列表中加入一份來自攻擊者的機主密鑰（Machine Owner's Key, MOK）實現提權和漏洞固化。再次重啟後，「黑蓮花」的「假大旗」玩成了「真虎皮」，Windows 原本的正常啟動程序就會讀取到這份來自攻擊者的 MOK ，一路綠燈地加載「黑蓮花」自簽名的啟動工具 grubx64.efi 和來自攻擊者的內核驅動，相繼禁用各種 Windows 安全工具直至主系統啟動，最終導致 C&C 攻擊。
之所以「黑蓮花」可以在微軟針對 Baton Drop 發布補丁後大半年才橫空出世，正是由於 UEFI 裡面這份不能一次性更新完的 DBX 列表。在這個空檔里，「黑蓮花」通過自帶漏洞驅動（Bring Your Own Vulnerable Driver, BYOVD）的方式，藉助暫時沒有被列入黑名單但擁有漏洞的二進位文件進行自簽名，進而讓自己的 UEFI 應用（也就是上面的 grubx64 ）可以被順利的運行。
Although the vulnerability was fixed in Microsoft’s January 2022 update, its exploitation is still possible as the affected, validly signed binaries have still not been added to the UEFI revocation list. BlackLotus takes advantage of this, bringing its own copies of legitimate – but vulnerable – binaries to the system in order to exploit the vulnerability.
Martin Smolár, ESET
Although the vulnerability was fixed in Microsoft’s January 2022 update, its exploitation is still possible as the affected, validly signed binaries have still not been added to the UEFI revocation list. BlackLotus takes advantage of this, bringing its own copies of legitimate – but vulnerable – binaries to the system in order to exploit the vulnerability.
Martin Smolár, ESET
▍修復：微軟的「三步走」
全球市場占有率最高的作業系統被曝出了這樣底層的漏洞，微軟當然要緊急著手進行修復，早在去年一月就推送了 Patch Tuesday 更新宣布修復了 Baton Drop 漏洞。但借著 CVE-2022-21894 興風作浪的「黑蓮花」還沒有消停，另一個性質相近的 UEFI 漏洞就被相繼發掘出來，這一次是關於 Windows Boot Manager 的 CVE-2023-24932 漏洞。最終，在今年 5 月 9 號的一則博文中，微軟宣布了針對這次底層漏洞的跨度接近一年的修復計劃：
2023 年 5 月 9 日的 CVE-2023-24932 補丁中，將會包含一份默認不啟用的修復程序，用戶需要參考微軟提供的指南自己更新目前使用的啟動媒介並添加具有針對性的 DBX 列表。
2023 年 7 月 11 日的 KB5028185 更新中簡化了上述的操作步驟。
2023 年 5 月 9 日的 CVE-2023-24932 補丁中，將會包含一份默認不啟用的修復程序，用戶需要參考微軟提供的指南自己更新目前使用的啟動媒介並添加具有針對性的 DBX 列表。
2023 年 7 月 11 日的 KB5028185 更新中簡化了上述的操作步驟。
至於為什麼要採取這樣分階段的方式來推行一個事關幾乎所有 Windows 用戶的重大更新，原因正如前文所述，無論是 Baton Drop 還是 Windows Boot Manager ，想要徹底解決問題就必須把所有此前有漏洞的 UEFI 固件給「拉黑」，用更新後的 DBX 列表核驗啟動時加載的每一個 UEFI 應用，從而阻止「黑蓮花」這樣的惡意 bootkit 混入其中。
但是，此前帶有漏洞的 UEFI 固件存在於來自微軟的幾乎所有 Windows 官方鏡像，涵蓋範圍從 Windows 11 到 Windows 10，甚至早至 2008 版的 Windows Server ——換句話說，幾乎所有你之前下載的 .iso 鏡像文件，或者是以此灌裝的安裝盤、Windows To Go 啟動器、各類 Win PE 安裝器、公司 IT 部門用來排障或者網絡分發的啟動鏡像，甚至是全盤備份文件，在補丁更新之後的電腦上將 通通不能啟動。
並且別忘了，戴爾、聯想等等 OEM 廠商，以及微星、華碩之類的主板廠商們使用的同樣是來自微軟的鏡像或者固件（更不用提微星在五月的一次勒索軟體攻擊中已經泄露了自己的簽名密鑰），因此如果你買的電腦自帶恢復盤的話，在應用了 Windows Boot Manager 修復之後的機器上也將完全失效。
因此，在傾向於避免導致大範圍啟動問題的前提下，微軟最終選擇了這樣一個循序漸進的解決方案。雖然現在還不能說成效顯著，但是面對當下愈發頻繁的針對 EFI 系統分區（EFI System Partition, ESP）的攻擊，儘可能主動的手段還是必要的。
▍補牢：我們應該怎麼做
幸運的是，無論是「黑蓮花」還是其他尚未浮出水面的針對 ESP 的攻擊手段，它們本質上都在以犧牲隱蔽性的手段來換取更加便捷的部署。在 ESET 的分析中可以看到，藉助「黑蓮花」進行 C&C 攻擊的一切前提是需要在目標設備上執行「黑蓮花」的安裝程序，這便需要攻擊者與目標進行物理接觸、或者通過釣魚郵件之類的方式取得管理員權限——事情此刻便又回到了傳統的網絡安全攻防領域中。
圖｜arsTECHNICA
除此之外，儘管「黑蓮花」運行在我們看不到的系統啟動前流程里，但是它的運行依然會在主系統里留下可以追尋的痕跡。如果你懷疑自己或者團隊中所使用的設備受到了「黑蓮花」的攻擊，可以參考微軟安全博客在今年四月發布的調查攻擊指南[1]來排查和恢復。
如果你只是對於「黑蓮花」和與之相關的 UEFI 漏洞的原理感興趣的話，可以翻閱一下 ESET 今年三月發布的調查報告 [2]。在報告中，ESET 的惡意軟體分析師 Martin Smolár 對「黑蓮花」的原理、工作流程和攻擊效果都進行了非常嚴謹專業的分析。
而對於正在使用著 Windows 系統的你我他她來說，我們現在能做的就是保持良好的上網習慣……並且儘量安裝一下近期的 Windows 安全更新吧。
相關連結
[1] 微軟安全博客調查攻擊指南：
https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/
[2] ESET 調查報告：
https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
原文連結：
https://sspai.com/post/81836?utm_source=wechat&utm_medium=social
作者：PostMeridy
責編：廣陵止息
/ 更多熱門文章 /