Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Most exploits that we talk about assume that an attacker does not have complete control of the computer. But, what if they did? This article, which heavily references the new Rootkits and Bootkits book, provides an insight into what can happen when an attacker goes after the boot process. In particular, it talks about rootkits (kernel modules injected for persistence) and bootkits (modifying the boot process itself).

BIOS (Basic Input Output System) prepares the system for higher level operating systems to be used. Prior to getting to this step, quite a bit has to happen though! The steps for the BIOS are listed below:

1. ROM BIOS Initialization - The initial boot process.
2. Use MBR (Master Boot Record) to find all of the hard drive partitions and boot code. Once the drive has been choose, the 0x1BE sized boot code loads the next step.
3. VBR (Volume Boot Record) finds an active partition within the drive to use. This steps loads the Initial Program Loader (IPL).
4. The IPL parses the file system and starts to get things ready. The IPL is quite small and is used to load the bootmgr.
5. The bootmgr reads the configuration data of the kernel and starts to the the kernel.
6. Kernel modules are loaded.
7. Finally, the first user mode process.

The boot process has some protections. In particular, Windows Vista implemented kernel module signing. Additionally, the ELAM (Early Launch Anti-Malware) allows for anti-virus to hook into the early boot process. However, because an attacker could hook into the boot process itself, these could be circumvented easily. Because of this lack of security on the beginning of the boot, something new was created!

The Universal Extensible Firmware Interface (UEFI) was the overhaul that the BIOS needed in order to get to a Secure Boot. The order in which things happen is a little different and centralized. Instead of steps 2-5 being in separate stages, they are all in one single UEFI boot stage.

1. UEFI boot initialization. Loads the platform modules and gets UEFI ready to go.
2. UEFI boot manager. This initializes buses, loads device drivers and loads the boot application.
3. Kernel modules are loaded.
4. Finally, the first user mode process.

Step 2 has quite a bit going on inside it though. This stage has 4 main steps outlined by the UEFI specification.

• SEC - Security boot: finds the loader for PEI and runs from SPI Flash.
• PEI - Pre-EFI Initialization: configures memory, does basic hardware things, runs in tmp memory then transitions to permanent memory.
• DXE - Driver Execution Environment: Initializes System Management Mode (also called ring -2) and DXE service executables. It also provides boot and runtime services.
• BDS - Boot Drive Selection: discovers the HW device from which the OS will be loaded using the GPT.

Instead of using the MBA and VBA, has the GPT (GUID partition table). This table is used to reference the drive and partition to use in order to boot the system. Additionally, configuration settings for UEFI are stored on the motherboard and are called NVRAM (nonvolatile random access memory) variables. The amount of things that can go wrong has shrunk significantly; sometimes, centralized security is a good thing.

This changed the game: it is no longer simple to modify the bootloader process, as everything is validated from the ground up. But, some mistakes can still be made. In poorly configured environments, it may be possible to modify the UEFI ROM, modify any of the mutable drivers, add secondary bootloader, insert signed kernel code... there are still quite a bit of things that can go wrong. A lot of the security relies on the SPI write protection on the BIOS working and the cryptography for verification being secure.

The Secure Boot process of UEFI proved to not be enough though. Because the verification steps were happening late in step 2 (DXE), previous sections could be compromised. As implementations got stronger, the root of trust got moved to lower and lower stages, even to hardware at times.

From here, there are some platform specific boot processes that have been added. For instance, ARM has TrustZone, Intel has Boot Guard. However, these are left for an exercise for the reader (and myself) to do a different day.

In order to test for these types of misconfigurations, there is an amazing tool that will automate a large amount of this stuff for you: chipsec. So, strap this in and see what you find!