Researches of EMBEDI conducted series of testing and successfully bypassed intel boot guard
This vulnerability was experimentally confirmed on the Dell XPS 13 9350 system with UEFI BIOS versions 1.4.4 – 1.4.10 that has the turned on Intel Boot Guard technology. As for Dell systems, this vulnerability is not dangerous as long as these systems have another BIOS protection mechanisms applied
What is Boot Guard?
In recent years, there is an increasing attention to the UEFI BIOS security. As a result, there are more advanced technologies created to protect UEFI BIOS from illegal modifications. One of such technologies is Intel Boot Guard (BG) – a hardware-assisted BIOS integrity verification mechanism available since Haswell microarchitecture (2013). So-called «UEFI rootkits killer» this technology is designed to create a trusted boot chain (where a current boot component cryptographically measures/verifies the integrity of the next one) with Root-of-Trust locked into hardware.
How does the Boot Guard work?
By looking at the picture we can figure it out that The first boot component (the Root of Trust) in this chain is Intel CPU with the microcode (located inside the CPU boot ROM). It loads into the protected internal CPU memory called Authenticated Code RAM (ACRAM), verifies and executes an Intel-signed BG startup Authenticated Code Module (ACM). The hash of the RSA public key (which is used to verify the signature of the ACM) is hard-coded inside the CPU.
It has very strong mechanism of loading ACRAM and verifies and executes ACM. Researches have taken the Gigabyte GA-H170-D3H motherboard with UEFI BIOS version F04 and took an look at IBB of the motherboard Though it doesn’t have BG guard enabled, the components of this technology are present.
The researches have tried to kill the killer of the boot guard
Firstly, the BootGuardPei entrypoint routine checks the compatibility with Intel BG (through the MSRs) and registers the notification callback procedure (Start) for EFI_END_OF_PEI_PHASE_PPI to be called in the end of PEI phase when the operating memory will be available to use.
Therefore, the Start routine is called further, which does the following.
1. Check the booting mode.
2. Create HOB with only one byte of data (which will represent the result of verification routine).
3. Search the hash container (which holds the hash of DXE code) inside the PEI volumes (by GUID: 389CC6F2-1EA8-467B-AB8A-78E769AE2A15) and verify the first block of DXE pointed by this container.
4. After that verify the second block (if it is described by the hash container like the first one).
In case the verification was not successful (for example, because the DXE code was illegally modified), the zero value will be written into HOB. If the DXE were not modified, the positive value (1) would be written. So, the illegal modification of the DXE code will be detected by the BootGuardPei (the hash of the DXE code would not fit one in the hash container).
Good! However, the funny thing is, instead of immediately applying the Intel BG enforcement policy (usually it is an immediate shutdown), this module still allows further execution of BIOS, hence running the modified DXE code. Why?
Inside the DXE volume there is another BG-related module: the BootGuardDxe (GUID: 1DB43EC9-DF5F-4CF5-AAF0-0E85DB4E149A). It is responsible for analyzing the results (previously saved in HOB by BootGuardPei) and shutting down the system if the DXE code does not pass the integrity check (if HOB contains the zero value, as we have already discovered).
You might have already guessed, that if an attacker manages to delete the BootGuardDxe from the DXE volume, the protection of the DXE part will not work at all (there will be no code to check the results of the verification done by the IBB).
Researches have finally delete the BootGuardDxe from the DXE volume and made sure that no code to check the results of the verification done by the IBB.
Hacker’s can easily use the vulnerability to hide their rootkit deep making the system part of the victim forever.