Bootkits: Attacking the boot process

The boot process is a critical moment in hardware initialization and the operating system load. There is no better opportunity for malware to take control of the computer in a way that is silent and transparent to the operating system. In previous articles, we talked about rootkits and the mechanisms used to compromise a system. In this article, we will discuss bootkits, whose aim is also to infect the system, but which take the opportunity of the boot to achieve it. This type of software is considered to be one of the most dangerous malware variants, and one of the most difficult to detect/remove.

Boot mechanisms: BIOS and UEFI

To introduce the concept of a bootkit, it is useful to know in some detail what happens in the startup of a PC and what elements are involved.

Regardless of the operating system, practically all domestic PC-compatible computers use one of the following two firmware mechanisms to boot: the traditional mechanism based on BIOS or the more modern UEFI (Unified Extensible Firmware Interface).

BIOS (Basic Input/Output System) is a standard firmware for the verification and initialization of hardware and the management of the PC operating system boot. It was introduced in 1975 for the first time in devices with a CP/M operating system. IBM subsequently divided BIOS into two parts: real mode (with full access to any physical memory address) and protected mode (with virtual memory and control of access to memory). BIOS is a 16-bit system with certain limitations in terms of security (code not signed digitally and boot in CPU real mode) and size restrictions to manage disks/partitions.

UEFI is a firmware that was created with the objective of replacing BIOS, surpassing the latter in matters such as the limitation of the size of disk partitions or the intrinsic security of the boot process. In 1998 EFI was introduced. It was an initiative that went through various phases of evolution until becoming the UEFI specification in 2005. In 2006, it was adopted as a boot mechanism in Intel-based Apple devices. Since 2011, most PCs have incorporated UEFI firmware; however, it is still very common to use the CSM (Compatibility Support Module) to boot the system in the old BIOS style. Since 2012, all computers with Windows 8 have incorporated UEFI.

Managing partitions and security: BIOS vs UEFI

BIOS uses the first sector of the boot disk (512 bytes), called MBR (Master Boot Record) to store the initial boot code, disk parameters, and the partition table. 16 bytes are designated to the partition table and there is a maximum of 4 primary partitions. BIOS uses 32-bit logical block addressing or LBA inputs, which, combined with a block size on a 512-byte disk, results in a maximum space limit of 2^32 * 512 = 2 TB.

Unlike BIOS, UEFI stores in the firmware itself both the boot code and a GUID partition table, and can manage up to 128 partitions. 64 bits are established for LBA, resulting in a maximum size (for disks with 512-byte sectors) of 2^64 * 512 = 9 ZB. Additionally, and due to compatibility with BIOS, it can use MBR. UEFI reserves a small partition in FAT32 format for locating files that manage the kernel boot process (bootloader)

-Partition management: BIOS/MBR vs UEFI/GPT-

In terms of security, BIOS does not digitally sign the firmware code, but rather trusts in a CRC control to verify its integrity. UEFI, however, uses encryption to verify the firmware and the boot code through a digital signature (Secure Boot). Moreover, BIOS starts up with the CPU in real run mode, allowing full access to the memory and hardware resources. The protected mode is used in UEFI during the whole process, employing the virtual memory, thus restricting random access to any memory area and direct access to the hardware.

Now that we know the two main PC boot mechanisms, it is necessary to be aware of what happens in the whole process from the moment at which the computer is connected until the operating system is loaded.

System boot: From the switch to the Operating System

BIOS boot sequence

In a BIOS-based boot, after turning on the computer, a hardware test is run, and the BIOS firmware stored in flash/rom is loaded into the memory and seeks the first boot device available in line with the order configured. Below, we can read the first sector of the device known as MBR (Master Boot Record). The MBR has a total of 512 bytes containing the initial boot code (phase 1), descriptive parameters for the disk, the partition table and the disk signature, ending with a 2-byte marker that identifies the MBR (0 x 55 AA). The signature is 32 bits and is only intended to identify the disk’s hardware.

- Structure of a MBR -

Given the limited size available for the code in the MBR (around 400 bytes, depending on the system), the latter is generally limited to locating and jumping to the next phase of the boot: the bootloader, or phase 2 of the boot.

The bootloader is a portion of the code that is located in the first sector of the partition marked as the VBR (volume boot record) boot partition, which has a similar structure to MBR. The bootloader contains the code that manages the options of the boot menu (multi-system) and operating system load.

Some of the best-known bootloaders are NTDLR (Windows 2000, XP), BOOTMGR (Windows 7, 8, 10) or GRUB2 for Linux.

- VBR: first sector of a boot partition -

- BIOS-based system boot sequence-

UEFI boot sequence

As we have indicated, the boot process in a UEFI-based system is different to BIOS and incorporates improvements with respect to limiting the number and size of partitions, as well as security measures. A UEFI system does not need to recover the boot code from a MBR/VBR, since it is embedded in the firmware in files with a PE format for executable binaries and drivers.

This UEFI firmware has variables whose values are accessible and modifiable for configuring management of the boot. This interaction with the firmware and its variables can be performed using tools such as efibootmgr for Linux, bootcfg for Windows or bless for Mac OS X.

As such, for example, it can be specified to the firmware where to find the bootloader, the file that an EFI system locates in a special partition with a FAT32 format and which will contain the information for loading the kernel of the OS.

Additionally, and due to compatibility with BIOS, UEFI can use traditional MBR/VBR. Moreover, UEFI uses the protected mode of the CPU, which results in access restrictions to hardware input/output and memory, while BIOS boots in real mode, which allows unrestricted access to the resources, with the implications that this has for security.

Lastly, UEFI has options (Secureboot) that perform cryptographic verifications on UEFI variables, drivers, and bootloaders before allowing the boot.

- BIOS boot vs UEFI boot. Source: NIST SP800-147 -

Bootkits

The boot is, in any of its phases, a great situation for avoiding protection measures, attempting to inject code into the operating system’s kernel, and taking control of the machine during the load. A bootkit takes advantage of this circumstance to infect the system before the operating system starts up, and, as such, its detection and elimination is much more complicated.

Although the introduction of UEFI as a replacement for BIOS made it very difficult for this type of software to infect a system, bootkits are beginning to explore new avenues of attack and to avoid the protections implemented by UEFI.

Introduction: Evolution and samples

The first concept of boot infection (and also virus) dates from 1987. It was known as Brain, and although we cannot consider this example to be a bootkit that has the aim of controlling a system, it is true that this is the first time that the idea of attacking the boot sector of a system was conceived (in this case, a floppy disk).

However, it was in the BlackHat of 2005 with a proof of concept called eEye, when we observed a demonstration of the manipulation of the MBR to infect a Windows system. This demonstration was the starting point for successive tests that have been evolving technically, as well as the parallel introduction of malware. The key points in the evolution of bootkits are represented in the following diagram:

- Milestones in the evolution of bootkits. Source:Bootkits: Past, Present & Future (ESET) -

Infection sites and classification of bootkits

There are many variants of bootkits that exploit different routes of infection; however, the most common attack strategies include modifying the MBR/VBR boot code in BIOS systems (which is relatively simple, since there is a lack of a cryptographic signature), kernel boot management files or bootloaders, drivers or more intrusive routes, such as modification of the firmware.

Here are some examples of boot code modification techniques:

• MBR modification: Mebroot, TLD4, Olmasco
• VBR modification: Rovnix, Gapz

Bootloader or firmware modification techniques:

• Bootloader modification: E.g.: Dreamboot (Proof of concept, UEFI)
• Firmware modification: E.g.: Mebromi (BIOS)

- MBR/VBR bootkit classification (BIOS)- Sources: ESET

Bootkits against UEFI and boot protections

As has been indicated, BIOS-based systems lack cryptographic verifications of the code that is executed in the boot, and as such, they are more vulnerable than UEFI systems, which digitally sign the process code. As such, most bootkits focus on BIOS systems with MBR/VBR. However, nowadays, BIOS-based systems are becoming obsolete, and therefore are beginning to lose the interest of malware developers. Consolidation of the UEFI boot in modern systems is beginning to close the door to traditional BIOS bootkit lines, and we expect that the future of research and occurrence of bootkits will focus on UEFI.

Infecting and modifying firmware would be ideal, but it is the much more complicated option, and depends a lot more on the platform. BIOS firmware modification can be achieved relatively simply, since use of a cryptographic signature is not necessary, but rather only a CRC checksum, and it is possible to rewrite it. UEFI implements verifications both of drivers and bootloaders (Secure Boot), such as the kernel of the operating system and firmware, and is supported by cryptographic keys stored in ROM and in TPM technology with the aim of avoiding any type of manipulation.

Attacks against UEFI security

Investigations such as the Dreamboot proof of concept or the investigation presented at the Syscan2014 conference: Setup for Failure: Defeating Secure Boot opened the doors to possibilities of avoiding UEFI protection mechanisms in drivers, bootloaders and kernel. It was discovered that there are certain UEFI integrating elements to which the digital signature verification is not strictly applied, allowing routes of attack to be opened up:

• ROMS option: Running of firmware of drivers not embedded in UEFI, generally located on additional cards (video, network interface controllers, disks)
• DXE (Driver Execution Environment): Initialization and drivers
• Bootloader: Manipulations of EFI variables allow SecureBoot to be avoided and a manipulated bootloader to be loaded. (Setup for Failure: Defeating Secure Boot Syscan 2014)

- UEFI attack routes: ROM option, DXE driver and bootloader - Source: ESET

Future

UEFI, Secure Boot and their protection mechanisms make life difficult for modern bootkits. As such, new routes of attack that focus on the firmware of network devices or hard disks are appearing. The future of malware that specialises in attacking boot processes, drivers and device control looks like it may arouse much interest.