A lesson on UEFI 101 and why you need it scanned for security

In the rapidly evolving world of security software development, recent research has shown that UEFI scanning has transformed from a "nice to have" into a "must have" feature. Initially deemed a theoretical threat, there was little information about real-world UEFI attacks in the wild. However over time, enough data was collected and analyzed by cybersecurity vendors to conclude that UEFI protection is now required.

From BIOS to UEFI

Let's begin with some basics. UEFI stands for Unified Extensible Firmware Interface. This is the part of your computer system that gets things started when you turn it on, the boot process. You might have learned that, for PCs, this was handled by something called the BIOS or Basic Input/Output System, and in fact that used to be the case. However, today's PCs use UEFI instead, even though some vendors still refer to it as "BIOS".

Like many other parts of a computer system, UEFI can be attacked in an effort to gain unauthorised access to the system and its data. The role of a UEFI scanner is to detect and remove threats that potentially launch before the operating system boots up. These threats, often referred to as rootkits or bootkits, target vulnerabilities in the UEFI and are highly persistent, even surviving after an operating system is reinstalled. In short, UEFI scanners are designed to prevent these types of attacks.

UEFI's predecessor, BIOS, was originally designed for 8-bit computers way back in 1975. It is unlikely that anyone expected the BIOS to be used into the next century, but some technologies outlive expectations. This was partly because no one knew what to replace BIOS with but they did know that the replacement should be something with more capabilities, better security, and easier to update and expand without having to write assembly language code.

Despite its benefits, early implementation of UEFI was limited. Widespread industry support was needed and someone had to take the initial leap. Eventually, Intel created the Extensible Firmware Interface (EFI) for its then-new, 64-bit Itanium processors, because BIOS could not support 64-bit. To get more adoption, Intel opened EFI up by creating the UEFI Forum which then published a specification for everyone to build to.

Issues with latitude

Note that UEFI is a specification, not really an implementation, meaning that, as long as you stay within the lines – digitally speaking – you have a lot of latitude to put in the features you want. And, the industry did just that, with many hardware and BIOS vendors rolling out their own versions.

The adoption of UEFI was boosted by Microsoft which was a fan of the newly-available options. It declared that, as of Windows 8, UEFI would be a logo requirement for new 64-bit computers. After all, UEFI provides some interesting security features that simply weren't possible with the BIOS of yesteryear.

Unfortunately, the "roll your own" aspect of UEFI led to some systems breaking. It took time to test all the potential variations in which it was deployed, but the test coverage just didn't seem to be that complete, so many corner cases (for better or worse) broke.

Additionally, a generation of techs raised with BIOS didn't have the tools or training to fix UEFI, mostly because the tools didn't really exist, or weren't widely available, which is still true to some extent.

Security concerns

Since hacking UEFI could ensure persistence and be largely undetectable with traditional methods, hackers have looked for ways to gain access, escalate user privileges, and write directly to the UEFI Serial Peripheral Interface or SPI, the flash memory that holds all the binaries that are trusted to make the host computer boot. Success here would give hackers access to more system resources when loading their binaries.

Clearly, protecting the SPI was a high priority. Internally, this was handled largely by SMM (System Management Mode). The SMM is supposed to be the security watchdog for SPI, designed to ensure the integrity of the code to be loaded through code-signing technologies. However, SMM itself was found to be vulnerable, potentially allowing the execution of arbitrary code. Significant effort has been made in trying to get all the vendors up to speed on assessing their own code for vulnerabilities, although often they believe theirs to be vulnerability-free.

Remember, UEFI is just a guideline, with vendors releasing their own version of what they think is best for the operating system and their own hardware. That means there are wide variations between different vendors' gear. And, as always, the rush to market tends to trump the rush to security.

Advent of UEFI scanning

As witnessed in many cyber attacks, the first exploit attempts, especially successful ones, are usually a harbinger of things to come. Once attackers find the "killer app" for UEFI abuse, we'll see more exploits in the wild, unless a combination of hardware and software vendors make patches available.

With hacker toolkits becoming more robust and extensible for UEFI, and while the wild variation of patch levels persists, it is inevitable that cybercriminals slowly set their sights on UEFI vulnerabilities. As such, effective UEFI scanning and threat blocking should now be a key requirement of any cybersecurity strategy.