baton drop (CVE-2022-21894)：Secure Boot 安全功能绕过漏洞

Windows 启动应用程序允许使用 truncatememory 设置从内存映射中移除包含序列化数据“持久”范围的内存块，从而导致 Secure Boot 绕过。

• truncatememory BCD 元素会从内存映射中移除指定物理地址以上的所有内存。
• 此操作在每个启动应用程序初始化时执行，此时序列化的 Secure Boot 策略尚未从内存中读取。
• 因此，可以使用此类元素将序列化的 Secure Boot 策略从内存映射中移除。
• 这将允许在启动应用程序中使用危险设置（bootdebug、testsigning、nointegritychecks），从而破坏 Secure Boot。

该问题通过两个不同的更改修复：

• 在尝试加载序列化的 Secure Boot 策略后，如果没有加载任何策略，并且 Secure Boot 已启用，且启动应用程序不是由 UEFI 固件直接加载的，并且启动应用程序不是 bootmgr，则启动应用程序初始化失败。
• 加载启动应用程序时，如果它包含带有 OriginalFilename 的 VERSIONINFO 资源，并且该文件名包含在黑名单中（包含 bootmgr.exe 和 hvloader.exe；在 Nickel 中，添加了 hvloader.efi，但未向后移植），则加载失败。
  • 在 Windows 8 和 Windows 8.1 中，hvloader.exe 不在 winload 的黑名单中——它原本应该在内，但这破坏了 Hyper-V 加载！
  • 自 Windows 10 版本 1809 起，如果设置了某个标志位（与 flightedbootmgr 元素一起使用，从磁盘加载 bootmgr），则 OriginalFilename 必须 为 bootmgr.exe。

利用

攻击者需要确保序列化的 Secure Boot 策略分配在已知物理地址之上。

• 默认情况下，它会分配到可能的最低地址。
• 最初，序列化的 Secure Boot 策略在加载后、使用 BCD 加载的任何配置之前分配。
  • 自 RS1 起，序列化的 Secure Boot 策略在加载启动应用程序时分配。
  • 自 RS2 起，序列化 Secure Boot 策略时，会释放任何现有的序列化 Secure Boot 策略。
• 如果加载启动应用程序时，BCD 条目的 osdevice 是一个 BitLocker 加密分区，并且 VMK 是通过 TPM 派生的，则序列化的 Secure Boot 策略会被重新分配。
  • 这可以通过在 TPM 解封成功后设置密钥标志的位 0 来伪造；该位可以在 BitLocker 元数据中手动设置，并添加额外的元数据以指定使用 Secure Boot 进行完整性验证。

avoidlowmemory 元素可用于确保所有物理内存分配都位于指定物理地址之上：

• 自 Windows 10 起，如果启用了 VBS，则不允许使用此元素，但由于它在启动应用程序初始化期间使用（在从内存读取序列化的 Secure Boot 策略之前），因此可以通过加载 bootmgr 并指定自定义 BCD 路径（使用 bcdfilepath 元素，即 custom:22000023）来绕过此限制。
• 如果 OS 卷中存在 BitLocker，或者目标系统运行的是 TH1 或 TH2，则此方法将失败；因此，也可以先使用 Windows 8.x 的 bootmgr 进行一次攻击以禁用 VBS，然后换回原始引导加载程序。
  • Windows 10 将启动应用程序初始化为一次性封禁所有 TPM PCR，因此 Windows 8.x 的 bootmgr 将无法在 Windows 10+ 系统上解封 VMK。

可以使用 nointegritychecks 元素加载 hvloader.efi 来加载自签名的 mcupdate.dll，其入口点将在 ExitBootServices 之前被调用。

或者，在非 AMD64 系统上，可以使用 TH2 之前的 winload.efi 配合 testsigning 元素；这允许证书中包含 szOID_NT5_CRYPTO EKU 的自签名二进制文件。

在 ARMv7 系统上，需要加载打了补丁的自签名 hal.dll，并导入 mcupdate.dll 以获得代码执行能力。

在 x86 和 AMD64 系统上，作为 mcupdate.dll 加载的文件必须命名为 mcupdate_*.dll，其中 * 是 CPUID 制造商字符串（如 GenuineIntel、AuthenticAMD 等）。

在 ARM64 系统上，由于最早可用的生产签名版本是 RS2 的 WinPE，因此此技术无法使用；目前只能执行绑定式代码执行（使用 bootdebug）。

包含的文件

此仓库包含以下文件：

• 提供了一个简单负载的源代码。此负载仅无限等待中断，因为如果不找到调用启动应用程序中的有趣函数和变量，就不可能执行其他操作。
  • 由于 mcupdate.dll 在启用分页的虚拟地址上运行，因此无法直接调用 EFI 函数（需要禁用分页才能调用 EFI 函数，返回到禁用分页的虚拟地址会导致不良后果）。
  • 要调用 EFI 函数，负载需要调用 BlImgLoadPEImageEx 或 BlImgLoadPEImageFromSourceBuffer，并在标志中设置位 0，以在 1:1 物理地址-虚拟地址映射中加载附加负载。
    • 或者，它可以调用 BlImgAllocateImageBuffer 并设置相同的位，以在 1:1 物理地址-虚拟地址映射中分配内存；然后自行加载负载（或将自身重新映射到那里）。
• 一个 ISO，利用此问题在 AMD64 上使用 Windows 8 RTM 的 bootmgfw 和 TH1 RTM 的 hvloader 进行利用。
  • 此处使用的负载通过从 hvloader 中通过偏移量获取的函数在屏幕上打印一条消息，然后进入无限循环。
• 一个 ISO，利用此问题在 AMD64 上使用 RS1 的 bootmgr 和 TH1 RTM 的 hvloader 进行利用。
• 一个 ISO，利用此问题在 AMD64 上使用版本 19041.1081 的 bootmgr 和 TH1 RTM 的 hvloader 进行利用。

后记

此问题可用于转储 BitLocker 密钥（当使用 Secure Boot 进行完整性验证时）。

• 虽然这是可能的，但不会披露获取内存中任意卷的派生 BitLocker 密钥并执行代码的具体方法。

此问题的修复还修复了另一个没有 CVE 的问题。

• bootmgr 会忽略内存中已有的任何 BitLocker 密钥表，并分配一个新的，而不会清除旧的。
  • 因此，攻击者可以从 bootmgr 加载 RS2+ 的 bootmgr（指定任意使用 Secure Boot 进行完整性验证的 osdevice），启动到 WinPE，加载已知的易受攻击驱动程序，并使用它在物理内存中搜索并转储现有的 BitLocker 密钥表。

目前尚无已知的易受攻击启动应用程序被撤销。

• 在撤销之前，攻击者可以自带自己的易受攻击引导加载程序。
• 撤销将导致所有现有的 Windows 安装/恢复介质以及旧备份无法启动。
  • 即使禁用 Secure Boot，由于 bootmgr 会检查自己的签名，启动也会失败。

更新（2023-05-10）

发生了不完整的撤销，以及另一个 CVE（CVE-2023-24932）。仍有一些未撤销的易受攻击 bootmgfw，以及仅修复了 bootmgr 加载 bootmgr 情况的额外补丁。这只需要一个粘贴的 bootkit 就能促使微软采取行动 ;)
如果你足够有创意，你就会找到绕过 2000 多个 bootmgfw 文件撤销的方法 ;)