TL;DR
你需要手动启用 Windows Boot Manager 更新。
如果你已经听说过了 CVE-2022-21894 漏洞并且及时下载了今年 5 月 9 日的 Windows 安全更新（KB5025885），你可以通过下述步骤来启用里面包含的修复内容：
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x30 /f，并重启电脑。需要注意的是，在手动启用这次更新之后，所有没有在新系统中更新过的启动介质、官方 ISO 镜像、厂商重装盘、PE 启动器等等将全部失效，无法开机。
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 漏洞却指出了一条非常新颖的道路。
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 的代码，最终达成绕过安全引导、从启动初期就控制计算机的效果。
由于 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，命令与控制）攻击。
这份只有 80kB 的 bootkit 就是目前发现的第一款可以攻破最新版 UEFI Secure Boot 的恶意启动固件——「黑莲花」。
随后，由捷克斯洛伐克的网络安全公司 ESET 主导，「黑莲花」的具体运行逻辑被解包了出来。从原理上讲，它的工作过程与 HIV 有些类似，HIV 的主要攻击目标是人的免疫系统、后续的致病致死往往是免疫系统瘫痪后各种感染引起的；「黑莲花」则是绕过和禁用 Windows 中的各种安全组件，比如 Secure Boot、BitLocker、代码完整性检查（HVCI）等等，在系统完全启动后通过引导 HTTP 远程控制的加载来对目标设备进行攻击或者窃取：
简单来说，在利用 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
全球市场占有率最高的操作系统被曝出了这样底层的漏洞，微软当然要紧急着手进行修复，早在去年一月就推送了 Patch Tuesday 更新宣布修复了 Baton Drop 漏洞。但借着 CVE-2022-21894 兴风作浪的「黑莲花」还没有消停，另一个性质相近的 UEFI 漏洞就被相继发掘出来，这一次是关于 Windows Boot Manager 的 CVE-2023-24932 漏洞。最终，在今年 5 月 9 号的一则 博文 中，微软宣布了针对这次底层漏洞的跨度接近一年的修复计划：
至于为什么要采取这样分阶段的方式来推行一个事关几乎所有 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 部门用来排障或者网络分发的启动镜像，甚至是全盘备份文件……如果它们没有同步添加今年 5 月 9 号的安全更新，那么在更新后的电脑上将通通不能启动。
并且别忘了，戴尔、联想等等 OEM 厂商，以及微星、华硕之类的主板厂商们使用的同样是来自微软的镜像或者固件（更不用提微星在五月的一次 勒索软件攻击 中已经泄露了自己的签名密钥），因此如果你买的电脑自带恢复盘的话，在应用了 Windows Boot Manager 修复之后的机器上也将完全失效。
因此，在倾向于避免导致大范围启动问题的前提下，微软最终选择了这样一个循序渐进的解决方案。虽然现在还不能说成效显著，但是面对当下愈发频繁的针对 EFI 系统分区（EFI System Partition, ESP）的攻击，尽可能主动的手段还是必要的。
幸运的是，无论是「黑莲花」还是其他尚未浮出水面的针对 ESP 的攻击手段，它们本质上都在以牺牲隐蔽性的手段来换取更加便捷的部署。在 ESET 的分析中可以看到，借助「黑莲花」进行 C&C 攻击的一切前提是需要在目标设备上执行「黑莲花」的安装程序，这便需要攻击者与目标进行物理接触、或者通过钓鱼邮件之类的方式取得管理员权限——事情此刻便又回到了传统的网络安全攻防领域中。
除此之外，尽管「黑莲花」运行在我们看不到的系统启动前流程里，但是它的运行依然会在主系统里留下可以追寻的痕迹。如果你怀疑自己或者团队中所使用的设备受到了「黑莲花」的攻击，可以参考微软安全博客在今年四月发布的调查攻击指南来排查和恢复。
关联阅读：Guidance for investigating attacks using CVE-2022-21894: The BlackLotus campaign
如果你只是对于「黑莲花」和与之相关的 UEFI 漏洞的原理感兴趣的话，可以翻阅一下 ESET 今年三月发布的调查报告。在报告中，ESET 的恶意软件分析师 Martin Smolár 对「黑莲花」的原理、工作流程和攻击效果都进行了非常严谨专业的分析。
关联阅读：BlackLotus UEFI bootkit: Myth confirmed
而对于正在使用着 Windows 系统的你我他她来说，我们现在能做的就是保持良好的上网习惯……并且尽量安装一下近期的 Windows 安全更新吧。
> 下载 少数派 2.0 客户端 、关注 少数派公众号，解锁全新阅读体验 📰
> 实用、好用的 正版软件，少数派为你呈现 🚀
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。