安全路透社
当前位置:安全路透社 > 网络转载 > 正文

如何绕过Intel Boot Guard

1.png

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

具体是如何实现的呢?请大家先看看下面这张图片:

2.png

在这条启动链中,第一个启动组件是带有微代码(存储在CPU boot ROM中,这种代码可以用简单的硬件操作来模拟当时无法用技术直接实现的复杂指令)的Intel CPU。它会加载进受保护的内部CPU内存,即ACRAM(Authenticated Code RAM),然后验证并执行一个由Intel签名的Boot Guard ACM(Authenticated Code Module-验证码模块)。其中,RSA公共密钥(用于验证ACM签名)是硬编码在CPU里面的,这也是Intel设计的一种技术实现。IntelBoot Guard ACM的运行要优先于BIOS,因为它还要负责验证Initial Boot Block(IBB)。一般来说,IBB的作用是显示UEFI BIOS中SEC/PEI卷的内容。

IBB中必须包含有这种技术实现的最后一个部分,这部分由BIOS或OEM厂商负责开发:即用来验证余下BIOS内容的代码,剩下的部分一般是DXE卷。

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

如此强大的保护机制真的不存在任何漏洞吗?

事实并非如此!在此之前,研究人员对启动BG ACM的CPU启动码进行了分析,并且发现可以通过逆向工程分析等方式找出OEM在实现Intel BG过程中的错误配置,而这种漏洞将允许攻击者向BIOS中注入编程代码,并对BIOS进行永久性的修改操作(通过对芯片组重新编程来实现对Intel BG的配置,是一种纯软件的实现方式)。

关于这部分的内容我们就不再赘述了,感兴趣的用户可以参考下面这两篇研究报告:

Intel Boot Guard研究

欺骗BIOS:如何让BIOS的防御机制失效

进入正题

首先,我们一起看一看技嘉GA-H170-D3H主板的IBB(UEFI BIOS版本为F04)。虽然它没有开启Intel BG,但相关的技术组件还是存在的:即BG ACM、BG密钥、以及IBB(SEC/PEI)。需要注意的是,它的主板固件基于的是AMI Aptio UEFI BIOS(很多OEM厂商都喜欢使用这款产品,例如技嘉、MSI、华硕、宏基、戴尔和惠普等等)。因此,我们待会儿所要讨论的代码几乎可以在任何系统(2013年之后的系统)中找到,因为这些代码都是由AMI开发的。

IBB中应该包含有哟关于验证BIOS余下组件完整性的代码,即BootGuardPei模块(GUID:B41956E1-7CA2-42DB-9562-168389F0F066)。

首先,BootGuardPei会检测Intel BG的功能完整性,然后注册EFI_END_OF_PEI_PHASE_PPI的通知回调程序(Start),当系统内存可用时,它会在PEI阶段调用这个模块。

3.png

因此,启动程序将会被调用,然后再进行以下操作:

1.检查启动模式。

4.png

很明显,当系统从睡眠模式中启动时,DXE代码根本不会被验证。但是,这并不是最重要的,请继续往下看。

2.使用一个字节的数据创建HOB(用于显示验证程序的输出结果)。

5.png

3.使用GUID:389CC6F2-1EA8-467B-AB8A-78E769AE2A15搜索PEI卷中的哈希存储器(保存了DXE代码的哈希),并验证DXE中的第一个区块。

6.png

哈希存储器的格式如下所示:

7.png

4.接下来,验证第二个区块。

如果验证不成功(例如DXE代码被非法修改),0值将会被写入进HOB。如果DXE没有被修改,则写入正值1。这样一来,如果DXE代码被修改过的话,BootGuardPei就可以检测到了,因为当前DXE代码的哈希与哈希存储器中的不匹配。

但有趣的是,这个模块还允许在BIOS执行其他的东西,因此我们就可以运行修改后的DXE代码了。这又是为什么呢?

在DXE卷中还有另一个与BG相关的模块:BootGuardDxe(GUID: 1DB43EC9-DF5F-4CF5-AAF0-0E85DB4E149A)。它负责对之前BootGuardPei存储在HOB中的结果进行分析,如果DXE代码没有通过完整性验证(HOB中存储的是0值),则立刻关闭系统。

下面是这个模块的程序代码:

9.png

它会调用BootGuardCheck程序,这个程序可以访问HOB立标,然后搜索BootGuardPeiHob。

10.png

11.png

如果BootGuardDxe没有找到BootGuardPeiHob的话,它既不会执行任何操作,也不会返回错误。因此,任何物理内存远程访问攻击都可以将这个HOB从列表中删除,然后绕过DXE的代码完整性验证机制。

不过,如果程序发现HOB中存储的是0值,那么它将会调用PrintFailMessageAndResetSystem。

12.png

你可能已经猜到了,如果攻击者可以将BootGuardDxe从DXE卷中删除的话,DEX的保护机制将无法正常工作,因为用于检测代码验证结果的部分已经不复存在了。

这个漏洞已经在戴尔XPS 13 9350系统(BIOS版本v1.4.4-v1.4.10,开启了Intel Boot Guard技术)中得到了验证。对于戴尔电脑,只要系统部署了其他的BIOS保护机制(PRx、SSM、以及验证UEFI BIOS升级完整性等等)的话,这个漏洞就不会对用户产生多大的影响。因此,如果你想利用该漏洞对这些系统进行攻击的话,你还需要一个SPI闪存编程器或在SMM代码中找到一个RCE/LPE漏洞,并修改BIOS。

但是,现在还是有很多系统并没有额外的BIOS保护机制,因此问题就比较严重了。戴尔的漏洞研究团队已经在他们的系统中确认了该问题的存在,技术人员目前已经在UEFI BIOS v1.4.18中修复了该问题,并正在努力提升Dell系统的整体安全等级。

当然了,我们也将该问题上报给了AMI,他们也表示技术人员正在想办法修复这个漏洞,而且他们已经将该问题告知了相关的OEM厂商。AMI表示,最新版本的AMI BIOS代码库中将不会再有这个漏洞了,OEM厂商可以通过BIOS更新来帮助终端用户进行漏洞修补。

非常好,那我们来看一看他们是如何修复这个问题的吧!下面是技嘉GA-H170-D3H主板的最新BIOS:

13.png

你TM一定是在逗我!!!!!!!

为了应对验证不成功的情况,他们再BootGuardPei HOB中存储了一个正值,而这将与匈奴我们再不需要删除BootGuardDxe模块的情况下绕过Intel BG保护机制,如果HOB存储的是0值,那么它将会重置系统。

如果压根就没有保护机制的话,这个漏洞当然就不存在啦!这一招果然聪明!

* 参考来源:embedi,FB小编Alpha_h4ck编译

未经允许不得转载:安全路透社 » 如何绕过Intel Boot Guard

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册