黑莲花UEFI引导后门的漏洞分析

点击蓝字 关注我们

UEFI，全称Unified Extensible Firmware Interface，即“统一的可扩展固件接口”，是一种详细描述全新类型接口的标准，是适用于电脑的标准固件接口，旨在代替BIOS（基本输入/输出系统）。

由于其发生在电脑启动的早期阶段，所以一些APT攻击组织会通过UEFI漏洞注入引导后门，从而针对军政外交等特定目标进行持久化驻留，这种底层的持久化驻留比较难发现，可以达到长期驻留持续监控目标的目的。现在，可以绕过基本平台安全功能（UEFI 安全启动）的 UEFI bootkit已经从神话走向现实。

这次给大家带来的就是UEFI引导后门黑莲花所使用的漏洞CVE-2022-21894的原理分析，目前的文章看上去大多分析了这个漏洞的使用，但是并没有文章分析这个漏洞的原理，那我就来分析一手。

这个漏洞发生在操作系统的引导阶段，当一个攻击者拥有管理员权限后，可以通过篡改操作系统的引导程序，在secure boot开启的情况下执行未被微软签名过的动态链接库代码。

要说明这个漏洞，就要从BCD说起，BCD，即启动配置数据。它作为在ESP引导分区的文件，存储了所有启动相关的配置参数，例如是否可以加载测试签名的程序，是否可以对启动阶段进行调试，引导阶段下一步执行的程序等等。如果我们想要查看或者修改BCD，只需要通过bcdedit.exe工具就可以进行操作。

然而遗憾的是，这种修改是有限的，在开启secure boot的情况下，诸如执行未签名程序等配置均无法实现修改。

也就是说，如果我们能够找到一个方法，绕过这个安全引导策略，我们就可以执行任意代码。

这里必须提到一组有趣的配置。

Avoidlowmemory：指定当前程序可用的最低物理地址

Truncotememory : 指定最高物理可用地址。

那么如果我们想办法让安全启动策略所在地址大于最高物理可访问地址的话，那么程序获取安全启动策略就会失败。CVE-2022-21849正是利用了这种思想。

通过在BCD中设置avoidlowmemory为0x10000000,然后加载自定义的新BCD文件，新的BCD中设置truncatememory 为0x1000000，于是安全启动策略被加载到了高于0x10000000的地址，从而导致获取失败。

BCD1：

BCD2：

通过这个方式，我们可以执行微软签名程序hvloader.efi，并在其拉起动态链接库mcupdate.dll的时候将原本的签名dll换成未签名dll。

通过这个未签名的程序，我们可以加载并调用自定义的UEFI应用。值得注意的是，由于我们处在保护模式下，所以我们自定义的efi程序要做的第一件事就是获取uefi应用的runtime，代码可以照抄EfiGetVariable函数，调用BlpArchSwitchContext。由于我们也不知道这个函数的地址，所以我们需要在动态链接库中搜索hvloader.efi的位置，然后找出这个函数的相对偏移。到此，我们已经成功执行了自定义的UEFI应用，接下来，黑莲花使用了MOKList将自己的公钥添加入厂商证书来实现持久化，并将自定义签名程序grub.efi设置为引导启动程序。

到这里大多数文章就已经结束了，然而我好奇的是这个所谓的序列化安全策略到底是什么，因为我并没有搜到关于它的任何说明，以及为什么策略加载失败程序能够正常执行，于是我打开了hvloader.efi想要一探究竟。

首先第一个问题：程序为什么会加载一个dll呢？这个问题我在BtLoadUpdateDll函数中找到了答案。hvloader是负责虚拟化支持的引导程序之一，而这个mcupdate.dll是负责微码处理的链接库。如下图所示，BtLoadUpdateDll函数通过BtpIdentifyPlatform获取平台，并通过调用BlBalLoadImage，最终调用 ImgpLoadPEImage来加载dll。然而遗憾的是，在这里我没有找到任何和安全启动策略相关的处理，只在ReactOS的代码中找到了ImgpLoadPEImage类似的实现，并发现了securebootpolicy的相关字样。

于是我又试图通过BCD和secure boot 来找到蛛丝马迹，并找到了如下函数：

看上去当每个BCD在加载时都会触发对应的回调函数，并通过Secureboot的策略表找到相关的配置，所以如果这个表初始化失败就会被当成空表继续执行代码吗？怀着这个猜想，我进一步阅读了相关实现，并找到了BCD配置回调的初始化位置：

通过查看这个回调的使用，我们找到了存储安全启动策略的变量boot_policy：

并在初始化位置发现和我们猜想的一样，如果没有找到配置策略，程序会返回并正常工作。

到此我们的疑惑就完全解决了。引导程序会在初始化的过程中从指定物理地址范围内搜索安全启动策略。如果没有找到，那么就无视掉加载失败的问题，之后程序加载每一个BCD配置的时候，都会通过回调函数检查安全启动策略中是否存在相关限制。由于配置没有找到，所以成功加载所有代码，微软给的修复方法也是简单粗暴：即禁用所有可以这么配置的程序。不过也有担心认为这样下去DBX很快就会不够用了。