In my previous blog post about my upcoming Black Hat USA talk, we discussed some of the details about Intel Boot Guard technology. It was good to see Dell last week, who also shared some details about their implementation.
In this blog, I want to continue to focus on BIOS protection technologies and discuss the importance of this research. For example, I’d like to share why it’s important to protect the platform boot process properly, right from its early steps. I’d also like to discuss what the real needs are for Secure Boot improvements (in case of operating system loaders), and how they are covered by the latest boot stages of UEFI firmware.
In this blog, I will provide some interesting facts about the importance of my Black Hat research.
The Evolution of Modern Rootkits
Nowadays, it’s rare for us to catch an interesting rootkit or bootkit in-the-wild. Most malware threats have migrated to user-mode. This fact is directly connected to the evolution of security technologies of modern operating systems.
As an example, Microsoft Windows has, in the past few years, introduced a lot of security changes into their kernel for the kernel-mode drivers. Now, the kernel can't load unsigned drivers because of the Code Signed Policy. The Patch Guard created a lot of limitations on kernel-mode code modifications. The Virtual Secure Mode (VSM) and Device Guard on MS Windows 10 raise the threshold of complexity for kernel-mode rootkit development.
Figure 1
The move to UEFI and the spread of the Secure Boot scheme changed the bootkit landscape, drawing more attention to BIOS firmware from security researchers. Also, these changes increase the cost of development for kernel-mode rootkits and bootkits. Now, this has already happened previously, mostly because of Code Signing Policy. The bootkit development process was much cheaper than the many ways to bypass protections from user-mode via vulnerabilities in signed drivers or Windows kernel-mode components.
From the attacker’s perspective, the more logical way to do things nowadays is to simply move to the next level down into the software stack - after boot code, that is the way to the BIOS.
Figure 2
The BIOS level of persistence is very different with anything else. The firmware implants or rootkits can survive after an operating system reinstallation, or even after a full hard drive change. It is an entirely different level of persistence, which can keep the rootkit infection active for the whole cycle of usage of infected hardware. The firmware level is the last boundary before the hardware, as it is precisely the BIOS that starts the initial stages for the hardware setup into the boot process.
Let’s have a look at the timeline from my Black Hat Asia talk, which shows the detected in-the-wild BIOS threats and the related activities of security researchers.
Figure 3
BIOS firmware has always been a challenging target for researchers, both due to lack of information, and due to the difficulty of modifying or instrumenting the BIOS by adding new code to execute during the boot process. But since 2013, we’ve seen a lot more effort from the security research community in order to both find new ways of exploitation, and to demonstrate the weaknesses and attacks on recently introduced security features (for example, in Secure Boot).
However, firmware attacks are not among common tactics of the cybercrime underground. In the past, almost all known incidents of firmware compromise were related to targeted attacks.
Matryoshka Firmware Updates
The instructions for UEFI firmware updates usually mention an update for the BIOS, which is the main firmware. But in the same way, that usual BIOS update delivers a lot of different “embedded” firmware to the various hardware units inside the motherboard or even in the CPU. Any BIOS vulnerability that bypasses authentication for a BIOS update image opens the door for the delivery of malicious components. However, it opens the door not only to BIOS implant installations, if any other issues make it possible to install one of the “embedded” firmware updates without authentication, or even to bypass it completely.
Basically, each firmware is an additional place where an attacker can store and execute code; an opportunity for a malicious implant. So how much firmware in our fancy modern hardware do we usually have? It is a very good question. Most modern desktops and laptops have the following kinds of firmware:
Figure 4
As an example, if Intel Management Engine (ME) opens access for read and write to ME memory regions from the BIOS, a skilled attacker can try to play with this possibility. I found a similar issue in recent Gigabyte hardware. Combined with the weak configuration of Boot Guard, this issue helped me to bypass implementation of Intel Boot Guard on this hardware.
This issue already patched and confirmed by a vendor. I will give more details about this issue next week, in my Black Hat talk.
BIOS Guardians for Intel-based UEFI Firmware
In previous blogs, we’ve already discussed SPI flash protections and issues with misconfiguration. But let’s get all the protections in one place (not including runtime exploit mitigations).
- BIOS control bits for SPI flash unauthorized write protection (BLE, BIOS_WE, SMM_BWP)
- SPI flash memory access policies (PRx)
- BIOS updates authentication (signing, BIOS Guard)
- Early boot process authentication and verification controlled by hardware (Boot Guard)
- BIOS update authentication and access policies to SPI flash controlled by hardware (BIOS Guard)
Figure 5
But it’s rare when we can see all the protections enabled in one piece of hardware. As an example, Intel Boot and BIOS Guard technologies are available only on the most expensive versions of CPU, with vPro technologies.
How Many Times Guardians Will Fail - Black Hat Talk
I discovered six different issues that I will detail in my upcoming Black Hat talk:
- ASUS Vivo Mini (CVE-2017-11315)- SMM privilege escalation (from ring 0 to ring -2)
- Lenovo ThinkCentre (CVE-2017-3753) - SMM privilege escalation (from ring 0 to ring -2)
- MSI Cubi2 (CVE-2017-11312, CVE-2017-11316) - SMM privilege escalation (from ring 0 to ring -2)
- Gigabyte BRIX (CVE-2017-11313, CVE-2017-11314) - Intel Boot Guard bypass
All the vendors have been informed in May 2017, via our responsible disclosure approach. Some of them have already released a patch, some not. But the disclosure date will be the same: Thursday, July 27th, 2017 - 5:00pm-6:00pm at South Seas ABE.
Don’t Forget to Come for My Book Signing Session. :)
I will also be doing an exclusive book signing of my recent publication, “Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats” at Cylance booth 716 on Thursday, July 27 3:00pm-4:00pm.
See you next week in Vegas!
