Booting “Most people, I think, don’t even know what a rootkit is, so why should they care about it?” ~Head of Sony BMG’s global digital business.

Overview MBR/BIOS GPT/UEFI HELL Attacking the Boot Process Example Boot Process Attacks and Malware

Rationale It is important to learn the process by which OSes are loaded because, Many attackers exploit certain aspects of this process to gain access to a machine. You need to recover the boot sector of a corrupted drive Create your own forensic tools that take advantage of the boot sequence Understand limitation placed on forensic tools due to different boot processes Understand why your removable media is not booting Understand persistence mechanisms malicious software uses Less important but useful: usually asked during an interview for a technical position and more...

MBR/BIOS Boot Process First instruction stored at a fixed address in read-only-memory (ROM) On 32 bit systems ROM/NOR stores Basic Input/Output System (BIOS) BIOS - Contains low level functions for accessing some basic system devices (disk I/O, reading the keyboard, etc.) as well as code to load a stage 1 boot loader BIOS Process Power-on self-test (POST) Detect the video card’s chip BIOS and execute its code to initialize the video hardware

MBR/BIOS BIOS Process (ctd) Detect any other device BIOSes and invoke their initialize functions Display the BIOS start-up screen Perform a brief memory test Set memory and drive params Configure Plug & Play devices (traditionally PCI bus devices) Assign resources (Direct Memory Access (DMA) channels & Interrupt Request Lines) Identify the boot device Once the boot device is identified BIOS reads block 0 from that device into memory and jumps there

MBR/BIOS Boot Process Disk Block 0 is called the Master Boot Record and contains the first stage bootloader Review, How large is this block? The bootloader is 16 bit code This block also contains the Disk signature and the disk partition table Because bootloaders would have to load information about file systems, and other information

MBR/BIOS Boot Process The MBR scans through it’s partition table and loads the Volume Boot Record for that partition. The VBR identifies the partition type and size that contains an Initial Program Loader (IPL) The IPL loads additional blocks that comprise the second stage boot loader On Windows NT derived systems (server 2003, windows xp) the IPL loads a program called NTLDR. This then loads the OS Why can’t BIOS or MBR just jump right into loading the OS? Because bootloaders would have to load information about file systems, and other information

MBR/BIOS Boot Process NTDLR Accesses the FS on the device If windows was put in the hibernation state, the contents of the hiberfil.sys are loaded into memory and the system resumes where it left off. Otherwise it reads boot.ini and prompts the user with the boot menu accordingly. If a non NT-based OS is selected: NTDLR loads the associated file listed in boot.ini and gives it control If an NT-based OS is selected NTDLR runs ntdetect which gathers information about the computer's hardware Then it starts Ntoskrnl.exe Because bootloaders would have to load information about file systems, and other information

MBR/BIOS Boot Process BOOTMGR (Windows 7 and above) It now uses bcdedit to edit boot files and to manage Multiboot OSes BCD (Boot Configuration Data) file From Microsoft, “BCD replaces the traditional Boot.ini text file in BIOS-based systems. Storing boot parameters in a text file, however simple, was considered to be too vulnerable to malicious attacks to justify its use.” More info: https://docs.microsoft.com/en-us/windows- hardware/drivers/devtest/boot-options-in-windows Because bootloaders would have to load information about file systems, and other information

MBR/BIOS Boot Process BOOTMGR (Windows 7 and above) You can manage BCD remotely and manage BCD when the system boots from media other than the media on which the BCD store resides. Similar to NTDLR but uses winload.exe to load essential device drivers It uses winresume.exe when loading a hibernation file Then starts ntoskrn.exe Because bootloaders would have to load information about file systems, and other information

BCD Malware Side Note: Some BCD using malware https://blog.malwarebytes.com/threat-analysis/2016/05/7ev3n- ransomware/ https://www.pcworld.com/article/228955/new_malware_targets_6 4_bit_windows.html and more..

MBR/BIOS EXAM

MBR/BIOS Address of first instruction is stored in a fixed location and is executed BIOS is loaded and performs POST BIOS scans for boot device MBR is loaded from the boot device MBR scans for bootable partition and loads the Volume Boot Record for that partition The VBR identifies the partition type and size and contains an Initial Program Loader which then loads a second stage boot loader NTDLR/BOOTMGR loads the OS kernel, which then starts the OS

Catching up to the Present Day

GPT/UEFI(Unified Extensible Firmware Interface) Why? We now had 64-bit architectures and we are still using a MBR that requires 16-bit code and 20-bit memory addressing? We can do better than that.

GPT/UEFI(Unified Extensible Firmware Interface) EFI supported features BIOS components - power management (Advanced Configuration and Power Interface), and system management components Support for larger disks BIOS 2.2 TB partitions… UEFI 9.4 ZB partitions No need to start in 16-bit real mode UEFI device drivers (architecture independent EFI byte code). OS still uses its own drivers Boot Manager No longer need a dedicated bootloader, simply place bootable files into the UEFI boot partition This boot partition is formatted as a FAT file system Extensibility

GPT/UEFI Much larger than legacy BIOS Often is used in conjunction with a TPM Trusted Platform Module - “A tamper-resistant integrated circuit built into some computer motherboards that can perform cryptographic operations (including key generation) and protect small amounts of sensitive information, such as passwords and cryptographic keys” More of a spec rather than a circuit

GPT/UEFI

GPT/UEFI

GPT/UEFI Boot Process Notes Stage 1 bootloader no longer needed (goodbye MBR and simplistic stage 1 boot loader) UEFI can parse a file system and load files on it’s own Fixed Address stored in flash memory to call UEFI code Pre verification of CPU init, Chipset Init, Board Init Code (SEC - Security phase, this is a misnomer) POST → “Platform Initialization” (Pre EFI Initialization, Driver Execution Environment) Boot Device Select

GPT/UEFI Boot Process Transient System Load UEFI reads the GUID (Globally Unique Identifier) Partition Table (GPT), which resides in block 0 with the MBR, which is there for legacy reasons UEFI identifies the EFI system partition This partition contains boot loaders for all OSes that are installed on other partitions Windows Boot Manager bootmgr.efi for windows, IA64ldr for older 64-bit NT systems, for linux there are many options but probably going to be EFI aware GRUB( grub.efi) Jumps to bootloader code Provide Run Time interface for OS

GPT/UEFI EXAM

GPT/UEFI SEC - Security phase (misnomer) PEI - Pre EFI Initialization DXE - Driver Execution Environment BDS - Boot Device Select TSL - Transient System Load (Selects and loads the appropriate boot loader) RT - Run time (provides OS access to some UEFI services) AL - After Life (shutdown process)

Forensic Tool Limitations Due to UEFI May have issues booting from external media (often used in forensics investigations) UEFI often comes with a TPM (trusted platform module) and potentially full disk encryption Hardware vendors may build-in varying degrees of UEFI support on a model- by-model basis. They may also include setup menus that enable UEFI features to be turned off, with the intention of allowing access, or even boot access, to non-UEFI boot media. The terminology for these options may vary, but can include “Compatibility Support Mode (CSM) mode” or “legacy mode”. The result is that it may be possible, in some cases, to turn off UEFIbased external boot restrictions while maintaining access to the subject device’s original boot media.

This is Fun! Let’s Go Deeper...

Some Terminology Malware - software that is intended to damage or disable computers and computer systems. Rootkit - a set of software tools that enable an unauthorized user to gain control of a computer system without being detected. Bootkit - Advanced form of rootkits that take the basic functionality of a rootkit and extend it with the ability to infect the MBR or VBR for MBR/BIOS systems and other parts of the boot process for GPT/UEFI.

UEFI vs. BIOS Firmware Storage

UEFI Firmware Volumes PEI and DXE code will often exist on separate volumes

Signed Code Signed BIOS requirements did not address malicious boot loaders Bootkit Evil Maid Attacks So, Secure Boot was introduced

We are all safe now...

Or so we thought... The signature check on target EFI executables doesn’t always occur Depending on the origin of the target executable, the target may be allowed to execute automatically In the EDK2, these policy values are hard coded Attack 1: If attackers compromise these devices, there is no code signing mechanism in place to protect these drivers.

Or so we thought... Attack 2: There is a UEFI setup variable and is accessible by Boot Services and Runtime Services This variable contains the UEFI secure boot ON/OFF switch Furthermore there are policy bytes for removable media probably set to DENY_EXECUTE_ON_SECURITY_VIOLATION, the OS can change this to ALWAYS_EXECUTE Read more here https://cansecwest.com/slides/2014/AllYourBoot_csw14-mitre-final.pdf

UEFI Variables Keys If the flash system isn’t locked down properly attackers can overwrite the keys UEFI variables rely solely on SMM to protect them UEFI variables must be kept writeable because at some point the system is going to need to write to them

That’s Enough Low Level Nemesis - Suite of malware. Used in 2015 with a bootkit and targeted banks and payment card processors. It was able to legitimately modify the VBR. This allowed nemesis to survive across OS reboots Nemesis hijacks the normal boot sequence using an installer dubbed "BOOTRASH." It invokes a multi-step process that involves the creation of a virtual file system that stores malicious components in unallocated space between partitions. The bootkit intercepts several system interrupts to assist with the injection of the primary Nemesis components during the boot process.

Remediation/Mitigation Wipe your drive completely and reinstall the OS Mitigation GPT/UEFI - Does not work on a GPT/UEFI setup We now know how safe this is ;)

Questions?

Relevant Links Some UEFI malware exploits (multiple examples, 2016) https://2016.zeronights.ru/wp- content/uploads/2016/12/1_2_UEFI_Rootkits_ZN_2016.pdf Malware VBR Hijacking https://arstechnica.com/information- technology/2015/12/nemesis-malware-hijacks-pcs-boot-process-to- gain-stealth-persistence/ Boot Process https://www.cs.rutgers.edu/~pxk/416/notes/02-boot.html

Relevant Links UEFI Specification: Don’t worry I skimmed this for you. http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_7 _A%20Sept%206.pdf Beyond BIOS: Developing with the Unified Extensible Firmware Interface 2nd Edition by Zimmer et al. https://www.amazon.com/Beyond-BIOS-Developing-Extensible- Interface/dp/1934053295 https://www.blackhat.com/docs/eu-14/materials/eu-14-Kovah- Analyzing-UEFI-BIOSes-From-Attacker-And-Defender-Viewpoints.pdf

Relevant Links All Your Boot Are Belong To Us https://cansecwest.com/slides/2014/AllYourBoot_csw14-mitre-final.pdf For you RE’s out there https://www.youtube.com/watch?v=R-5UO6jLkEI #Analyzing UEFI code Windows 7 Boot Process - https://social.technet.microsoft.com/wiki/contents/articles/11341.the- windows-7-boot-process-sbsl.aspx TPM and UEFI http://resources.infosecinstitute.com/uefi-and-tpm/#gref