在上一篇文章中，我们介绍了固件安全的安全机制，接下来，我们来介绍一下对应的UEFI规范以及攻击者如何攻击UEFI固件?

通用的可扩展固件接口

UEFI与典型的BIOS进程有几个关键的不同之处，即不再有MBR和VBR来定位代码。而是将GPT（GUID分区表）配置为启动加载程序内的特殊分区，该分区指向FAT32 EFI系统分区。它在GPT条目内包含一个多语言MBR条目，以防止仅识别MBR的旧系统攻击这种新格式。这个启动加载程序分区的路径由一个NVRAM变量控制(稍后将进行提示)，这里的启动加载程序负责查找OS内核加载程序并将控制权转移给它。这些代码存储在直接存储在主板上的SPI闪存中，并在启动时加载到RAM中。

操作系统加载程序由存储在EFI系统分区中的多个文件组成，需要注意的是，正是在这个启动加载程序中，控制从存储在SPI flash上的代码转移到存储在HDD上的代码。这是物理访问硬盘驱动器内存的攻击者有机会攻击的位置。如果禁用了安全启动，那么这里的任何代码都可以更改，因为补丁保护直到windows内核被初始化之后才会出现。

一旦控制从操作系统加载程序转移到winloader，启动服务将被删除，但是所有运行时服务将被启用。值得注意的是，操作系统加载程序在启动后通过hal.dll模块向内核模块公开一组运行时服务。这个模块中的错误通常被用作启动包的插入点，这些服务包括读取/写入NVRAM变量的能力，通过封装更新执行固件更新以及重新启动/关闭功能。

UEFI规范

UEFI规范定义了4个不同的启动阶段。

· SEC-安全启动：找到PEI的加载程序并从SPI Flash运行；

· PEI-EFI之前的初始化：配置内存，执行基本的硬件操作，在tmp内存中运行，然后过渡到perm内存；

· DXE-驱动程序执行环境（Driver Execution Environment）：初始化系统管理模式（也称为ring -2）和DXE服务可执行文件，它还提供启动和运行时服务；

· BDS-启动驱动器选择：发现将使用GPT从中加载操作系统的硬件设备。

测试步骤：SPI闪存位

许多配置可能会大大削弱UEFI安全启动的安全性，以下存储位存储在SPI闪存中，并控制安全启动的关键部分。我们应始终检查是否限制了通过内核模块直接写入SPI闪存，以防止攻击者更改这些变量。

· BIOSWE-BIOS写入启用位（0锁定，1解锁）；

· BLE-BIOS锁定启用位（1锁定，0解锁）；

· SMM_BWP-系统管理模式BIOS写入保护位（1处于锁定状态，0处于解锁状态）；

· PR（0-5）-SPI保护范围，选择性地阻止写入BIOS。

所有这些变量最初都是在驱动程序执行环境阶段设置的，为了验证这些变量，我强烈建议使用英特尔提供的CHIPSEC内核模块，在本页底部的参考资料部分中包含了描述如何安装此工具的指南。

要在安装CHIPSEC内核驱动程序后检查BIOS写入保护位，请在root终端中运行以下命令：

chipsec_main.py -m common.bios_wp

如果PR范围全为0，则root本不会使用它们，应将其设置为保护BIOS中的敏感内存区域。

攻击者如何攻击UEFI固件?

攻击者攻击固件的方式有很多，但这里列出了一些最常见/最明显的方法：

1. 修改未签名的UEFI选项ROMS，因为它可能无法根据配置进行验证；

2. 添加/修改一个DXE驱动程序；

3. 替换/修改启动管理器(使用回退启动管理器)；

4. 修改回退启动加载程序EFI/BOOT/bootx64.efi

5. 添加一个辅助启动加载程序；

6. 绕过SPI写入保护，设置敏感内存位来禁用保护。

在具有根权限的用户空间，使用签名绕过插入内核代码，使用硬件抽象层接口访问系统管理模式。然后找到绕过SPI保护的方法，直接写入上面列出的一个早期启动阶段。

返回安全启动

有三种形式的安全启动：

操作系统安全的启动

这种形式的安全启动发生在系统启动加载程序中，只验证系统内核和启动驱动程序。

UEFI安全启动

这个安全启动是在UEFI固件中实现的，当UEFI应用程序和驱动程序被加载时，验证本身在驱动程序执行环境阶段发生，攻击仍然可以发生在BIOS的PEI或SEC阶段。

此外，如果攻击者能够攻击平台映像本身，他们将能够绕过这个保护。

平台安全启动：使用TPM

可信平台模块（Trusted Platform Module）安全芯片，是指符合TPM(可信赖平台模块)标准的安全芯片，它能有效地保护PC、防止非法用户访问。1999年10月，多家IT巨头联合发起成立可信赖运算平台联盟（Trusted Computing Platform Alliance，TCPA），初期加入者有康柏、HP、IBM、Intel、微软等，该联盟致力于促成新一代具有安全且可信赖的硬件运算平台。2003年3月，TCPA增加了诺基亚、索尼等厂家的加入，并改组为可信赖计算组织（Trusted Computing Group，TCG），希望从跨平台和操作环境的硬件和软件两方面，制定可信赖电脑相关标准和规范。并在并提出了TPM规范。符合TPM的芯片首先必须具有产生加解密密匙的功能，此外还必须能够进行高速的资料加密和解密，以及充当保护BIOS和操作系统不被修改的辅助处理器。

这种形式的安全启动验证所有平台初始化固件，并在一个受信任的平台模块中运行。

最初，安全启动驱动程序验证在DXE中进行，然后在PEI中进行，但现在它应该在TPM(可信平台模块)中进行，或者在只有通过Intel ME固件才能使用的现场可编程熔丝内部进行。

测试步骤：重要的关键位置

签名存储在一个数据库中，该数据库驻留在SPI flash或NVRAM变量中，具体取决于实现方式。还有一个单独的Dbx数据库，它包含一个列在黑名单上的公钥和散列，这些公钥和散列将被显式拒绝。

这些数据库由平台密钥或供应商密钥NVRAM变量(KEK)保护。这个NVRAM变量应该安全地存储在TPM中，并由平台密钥签名。

在安全约定期间，验证平台和供应商密钥只由适当的各方控制是至关重要的。数据库中批准的签名者列表应仅限于系统操作所需的签名者。理想情况下，这仅限于项目所有者。

此外，Dbx数据库应明确拒绝已知的错误签名者。

测试步骤：安全启动策略

上面的部分详细说明了系统在理论上应该如何运行，但是在实践中，它依赖于安全启动策略。该策略可能指定某些媒介(如PCDOption rom)在默认情况下是可信的。

在管理终端中运行以下PowerShell命令，检查测试系统是否启用了安全启动：

Confirm-SecureBootUEFI

在管理终端中运行以下PowerShell命令，检查测试系统是否启用了生产安全启动策略。

Get-SecureBootPolicy

如果使用生产策略运行，该命令将返回一个值{77FA9ABD-0359-4D32-BD60-28F4E78F784B}。任何其他值都表示使用了调试或制造商策略，应该进一步研究。

在非windows设备上，需要使用特定于操作系统和特定于内核映像的方法检查正在使用的安全启动策略。在Rootkit和Bootkit中，我发现Intel EDK2源代码有几个策略值，这些值不能验证可移动媒介或可选ROMS上的映像。

这意味着，具有系统内部知识的攻击者可以利用这些实现细节攻击原本安全的系统。

基于虚拟化的安全性

从Windows 10开始，代码完整性机制已经被移到了系统内核之外，带有虚拟安全模式和Device Guard功能。这两种技术利用硬件辅助的内存隔离来在受管理程序保护的容器中运行操作系统和关键系统驱动程序，这试图确保即使运行时内核被感染，固件和操作系统也不会被进一步攻击。

虚拟安全模式消除了合法内核模块存在RCE漏洞的威胁，该漏洞会危及整个系统，因为攻击者无法在安全容器之外升级他们的特权。

Device Guard是基于WindowsVista中引入的内核模式代码完整性（KMCI）和Windows 8 RT中引入的用户模式代码完整性（UMCI）。Device Guard包含诸多限制代码执行的特性，基于一组策略规则限制什么类型的可执行文件/脚本（包括DLL）可以加载。

Device Guard通过将虚拟安全模式与平台和UEFI安全启动相结合，在此技术的基础上构建。目的是从启动过程开始就加强设备的完整性，并防止Bootkit受到任何感染。平台和UEFI安全启动如上所述发生，但是一旦启动管理器将控制权转移到操作系统内核，Device Guard就会将敏感的系统组件(如正在运行的内核)封装在保护性虚拟机监控程序虚拟容器中。

为了获得这些出色的安全特性的代价是，为Device Guard开发的所有驱动程序必须遵循如下所述的附加规则：

1. 驱动程序只能从非可执行池中分配非分页内存；

2. 驱动程序不能有可写和可执行部分；

3. 驱动程序不能有动态的或自修改的代码；

4. 驱动程序无法将任何数据加载为可执行文件。

经过验证和测量的启动

现代TPM提供的技术可以使系统在解密已被封在TPM内的机密之前，验证其处于已知的安全状态，该技术验证了平台图像没有被更改。

通过将启动组件的哈希存储在TPM PCRS（平台配置注册表）中并在运行时进行检查，可验证启动工作的安全性。

TPM认证是一种证明系统身份的方法，它证明了TPM持有某一特定的密钥，但没有显示该密钥。它通常用于限制一个端点只与特定数量的已知设备通信。

Intel Boot Guard：平台安全启动措施

近些年来，安全社区中关注UEFI BIOS安全问题的人也越来越多了。因此也诞生出了很多用于保护UEFI BIOS免受非法篡改的先进技术，其中一项技术就是Intel Boot Guard（BG）- 一种基于硬件协助的BIOS完整性验证机制。这项技术会在硬件中创建一种可信任的启动链，即当前的启动组件会对下一个组件的完整性进行加密验证。

在厂商的生产制造过程中，Intel Boot Guard这项技术是一种“永久配置”型的设计，即配置信息会被写入一次性可编程Intel芯片组（涉及到保险丝熔断）。因此，这也让我们几乎无法在不了解OEM Root私钥（Intel BG配置中还包括公钥哈希）的情况下去修改BIOS。不过，配置本身的灵活性可以允许我们对Intel Boot Guard进行错误的配置，并在某些情况下绕过这项技术。

Intel Boot Guard是一个验证和测量启动的实现。值得注意的是，它有自己的策略，不同于常规的安全启动，也应该对其进行评估。

Boot Guard会验证BIOS映像，以确保它没有被bootkit感染，它使用硬件信任root（TPM或保险丝）保存正确BIOS内容的哈希，并在TPM中运行验证代码。

这就缓解了以前对SPI闪存完整性的依赖，并将所有信任直接移入为此目的而经过加固的硬件。

总结

在评估硬件设备的安全性时，通常会忽略早期启动系统的安全性。在涉及客户对目标设备具有隔离访问权限的威胁模型中，确保缓解涉及固件植入的攻击媒介至关重要。

本文翻译自：https://maxfieldchen.com/posts/2020-05-31-Hardware-Root-Of-Trust-Bios-UEFI.html如若转载，请注明原文地址：