In this blog post, we will explore how the computer security landscape has expanded to reach below the operating system levels, aiming to address areas that are often overlooked or completely neglected in cybersecurity. Attackers have discovered techniques to establish long-term persistence in compromised hosts by injecting malicious code to run before the operating system loads in areas commonly referred to as Basic Input Output System (BIOS).
The Wake-Up Call for Firmware Security
The genesis of this story unfolded nearly two decades after IBM's introduction of the BIOS to its original PC back in 1980, progressing to the moment when the initial widespread infection began to focus its attention on this technology. Chernobyl (CIH) copied itself and remained dormant until April 26, 1999. The objective was not to maintain persistence, rather the intention was to crash the machines rendering them unusable by erasing the contents of Flash ROM memory, the place where the BIOS resides in the motherboard, and overwriting the Master Boot Record (MBR) sector from the hard disks. This was only possible in some motherboard models that did not have locking the BIOS write-protection enabled by default. At the same time Intel had been working on its own specifications known as Extensible Firmware Interface (EFI), which would be the base blocks of the UEFI.
Figure 1: Traditional Boot Process (Source: NIST)
UEFI's Evolution
It was only in 2005 that the UEFI Forum was formed by a group of hardware manufacturers, firmware developers, and software vendors, aiming to promote and develop the UEFI specifications as the successor of EFI and the traditional BIOS. UEFI-based systems brought significant improvements over the BIOS standard. Along with a new graphical interface, UEFI introduced the Global Unique Identifier (GUID) Partition Table (GPT), which allowed for larger disk sizes and a greater number of partitions.
Another notable improvement came with UEFI 2.1 from 2007, the introduction of Secure Boot. This feature aimed to enhance pre-OS security by ensuring that only trusted operating system loaders, which have been signed with valid digital signatures, are allowed to run during the boot process. Secure Boot mitigates the risk of malware or unauthorized operating systems compromising the system's integrity at start-up.
Figure 2: UEFI based Boot Process (Source: NIST)
The Emergence of Bootkits
It was not until a few years later that a complete lack of adoption of the newer security resource’s usage like Secure Boot or pre-boot authentication, along with several vulnerabilities in the implementation of some UEFI components affected virtually all known vendors, and new techniques to maintain sticky persistence emerged.
One of the initial bootkits to be publicly revealed, came to light through a leaked source code attributed to an Italian company called Hacking Team, that specialized in the sale of surveillance and offensive cybersecurity tools. Vector-EDK's source code revealed the methodology of overwriting the SPI Flash memory registering a new DXE driver in UEFI that could ultimately write executable files inside Windows start-up folders. This technique was later used in several other bootkits like MosaicRegressor, MoonBounce and CosmicStrand.
In 2018, a high severity persistent artifact appeared compromising computers at a pre-boot phase. Related to Computrace LoJack, a software that was legitimately created to assist with laptop theft recovery, acted like a rootkit but at the same level of the bootloaders and had the capability to make the OS (Operating Systems) call back to its Command and Control (C&C). It allowed users to track, manage, and remotely delete data on their devices, even if the hard drive was replaced or reformatted. The Computrace software was embedded in the firmware and had vulnerabilities that allowed malicious actors to repurpose the software to keep the malware persistent. It was dubbed LoJax.
Infecting EFI System Partition (ESP) is a method first observed in the wild around 2019. The technique involved patching the file bootmgfw.efi from Windows Boot Manager located within the ESP, thus enabling the implementation of a chain of hooks that ultimately would be executed by the operating system kernel with the highest privileges, providing attackers administrative control. ESPecter and FinSpy were examples of bootkits using this method, this could have been prevented if Secure Boot were enabled, because patching a signed file would invalidate the signature causing the boot to fail, which later was found to be easily circumvented simply by self-signing the files. Not too long ago, a generic source code demonstrating how this technique could be implemented appeared online. It was named Bootlicker.
Raising the Bar for System Resilience.
As a result of the successful attacks, stakeholders have responded by ramping up their efforts to improve and expand pre-OS security technologies. These advancements aim to make the technologies more accessible, easily configurable, and most importantly, enabled by default. With the increase in maturity and a growing user base, the overall panorama of pre-OS security has evolved significantly, like Pre-Boot Authentication, Hardware Root of Trust, Cryptographic Services and Authorization Framework.
One notable development is the UEFI scanner, which enhances the protection offered by Microsoft Defender ATP. This scanner brings pre-OS security to a new level, providing a robust defense against threats targeting the boot phase. Microsoft has highlighted this advancement in their Security Blog, emphasizing the importance of protecting systems at the firmware level.
Furthermore, tools like the IDA plugin efiXplorer appeared allowing vulnerabilities to be addressed in bulk. This enables identification of firmware vulnerabilities through automation, contributing to overall system security and resilience.
Baton Drop (CVE-2022-21894)
More recently, a vulnerability named ‘Baton Drop’ exposed a flaw in the Windows Boot Manager, which allowed local attackers to discover and overwrite the memory address ranges of the Boot Configuration Database (BCD) permitting local threats to disable the policy for the requirement of Secure Boot.
Figure 3: Timeline showing bootkit related occurrences along with UEFI historical improvements
BlackLotus
BlackLotus is a UEFI bootkit module that exploits UEFI Secure Boot on fully updated Windows 11 systems. It took advantage of the Baton Drop vulnerability that had not been patched properly at the time. The bootkit was capable of evading security by adding its key to the Machine Owner Key (MOK) list, causing its boot loader to be considered signed and allowing it to deploy its own payloads. It has been sold on hacking forums since October 2022 and was the first-known malware to bypass Secure Boot protections, enabling the execution of malicious code before Windows loads.
The bootkit uses various anti-analysis techniques. The installation process involves deploying files to the EFI System Partition and communicating with a Command and Control (C2) server. The C2 server sends commands to the targets to download and execute additional payloads. More recently an alleged source code of the tool has been published in a github repository. Upon analysis it was identified that the method used to the C&C communication captured in the wild differs from the one published, indicating that the threat actors enhanced the module capabilities by adding more fields to improve visibility of resources like total amount of memory, CPU and GPU power. It was also notable that the bootlicker technique is being used instead of Baton Drop.
Figure 4: The Command and Control user interface from the alleged BlackLotus source code.
Response
Microsoft initially released a patch to address the Secure Boot bypass bug (Baton Drop) exploited by the BlackLotus bootkit in January 2023. The patch required several signatures used to sign bootloaders to be revoked, rendering older bootable media unusable. Microsoft rolled out the updates revoking the keys gradually over the course of few months to avoid sudden disruptions, with subsequent updates until the fix on May 9, 2023, and the Windows July 2023 Security Updates, almost a year after the first detected event. During this period, a new CVE-2023-24932 was assigned to address the issue related to the remaining keys still to be revoked. This incident highlights the challenges of patching low-level Secure Boot and UEFI vulnerabilities.
Summary
The objective here was to bring this topic to light to stimulate awareness for the security of this area. It is not possible to ignore the fact that the enhancement of this kind of technology has shifted to consider exploitation by ill-intentioned actors, and because it was not done proactively, it had to be implemented reactively after weaknesses were demonstrated and weaponized. It is not hard to foresee that development and improvements will need to take security into account and find newer ways to allow corrections to be rolled out easily, in a timely manner and without disruptions.
