Windows Security

Securing the Boot Process

UEFI Vulnerabilities

UEFI firmware is a radical change over BIOS firmware. For comparison, the 1994 plug and play BIOS specification from Intel and Phoenix was 56 pages long and defined basic functionality to configure plug-and-play devices. The UEFI specification is 2558 pages and defines:

  • A full TCP/IP network stack including WiFi, Bluetooth, UDP, IPsec, TLS, HTTP, DNS v4/v6, ARP, DHCP, and FTP support
  • File I/O with support for USB devices
  • A shell environment allowing scripting, and access to pre-boot applications that provide file manipulation and device access
Even a full-on web-browser with internet access can be run from UEFI firmware. UEFI application development is beyond the scope of this module, but if you are interested in exploring it more: here is a Hello World project in C using the EFI API, and a tutorial using bare-metal UEFI assembly. Additionally, you can find an excellent tutorial on UEFI shell scripting here.

All the features provided by UEFI facilitate management subsystems such as the Intel Management Engine and AMD Secure Technology.

The Intel ME:

  • Runs on an embedded microcontroller found in Intel chipsets integrated into motherboards
  • Runs its own operating system with a micro-kernel
  • Provides out-of-band access to system devices to include, RAM, and network interfaces
  • Runs independent of the powerstate of the PC, even if the system is powered off
The massive increase in firmware based capabilities has also massively increased the attack surface available for exploitation. This has lead to a number of CVEs to include:
  • CVE-2017-5689 for Intel Active Management Technology
    • (AMT). This CVE is rated 10 in severity; it allows the complete compromise of integrity and confidentiality of a System while requiring no authentication, and very little skill to execute remotely. An exploit explanation is available here
  • CVE-2018-3628 which revealed a possible buffer overflow in AMT's HTTP handler
  • A number of CVEs were just disclosed allowing potential privilege escalation in machines running InsydeH2O firmware
  • MoonBounce is a rootkit targeting UEFI firmware which was recently discoverd by Kapersky
Firmware exploits are not specific to Windows because they are not specific to any OS. They execute code before, and outside of, any OS installed on a PC. Because of this, they should be considered as a potential attack vector, regardless of what OS a machine is running.


Secure Boot

The UEFI Consortium created the secure boot specification to mitigate the chance of malicious code being loaded and prevent the installation of rootkits and bootkits. Microsoft provides an overview of the UEFI Secure Boot process on this page, and another more in-depth look at it here. The UEFI Consortium also provides a description and some background information about secure boot in this document. Finally, Brandon Adler gives a good description of the UEFI Secure Boot specification in this video:


Key Points are:

  • The secure boot process creates a chain of trust utilizing public key certificates
  • Secure boot uses RSA 2048 or stronger asymmetric encryption
  • The secure boot Public Key Infrastructure (PKI) is very similar to PKI websites use; they have root certificate authorities (CA), and intermediate CAs, which sign their site's X.509 certificate
  • The Platform Key (PK) is a self-signed key and acts as the root CA in the Secure Boot process
  • The PK is usually set by the equipment manufacturer before shipping a system
  • There can be only one PK in a UEFI secure boot system
  • Key Exchange Keys (KEKs) are a second tier of keys
  • KEKs establish a trust relationship between the OS and the firmware
  • There can be several KEKs in the UEFI NVRAM
  • Most systems have a Microsoft public CA key and a vendor public CA key pre-installed
  • Both the PK and the KEKs can be used to update the secure boot databases
  • The secure boot databases consist of the: Deny List Database (DBX), Allow List Database (DB), Timestamp Database (DBT), and Recovery Database (DB)
  • The DBX is used to explicitly deny images which have a matching SHA-256 hash or revoked X.509 certificate
  • The DBX is the first database that is checked before code is executed
  • The DB stores signed signatures of allowed images such as operating system loaders like bootmgfw.efi
  • The DBT stores timestamps to check if a certificate has expired
  • The DBR stores authorized signatures for recovery images to use in the event that no valid DB image is found
  • Secure boot is supported in Windows 8 and later versions
  • Secure boot is a UEFI specification and does not require a Trusted Platform Module (TPM)
The secure boot process is fairly involved, so here is Lowell Vanderpool with another video explaining it:

Additional Points:

  • On boot, the UEFI firmware verifies the Boot Manager (bootmgfw.efi) signature in the secure boot DB
  • Each Windows component in the boot chain verifies the Authenticode signature of the next component
  • Starting with Windows 8, the Windows Kernel launches the Windows Defender Early Launch Anti-Malware (ELAM) driver (wdboot.sys)
  • ELAM scans the signatures of third-party drivers to ensure they have valid digital signatures before loading them

While secure boot keys such as the PK are not intended to be installed by end-users, it is possible to create your own PK for secure boot and install it to your UEFI NVRAM. The NSA provides this instructional guide on how to completely customize UEFI secure boot with your own key Infrastructure.