When ESET announced that improvements to the latest version of its endpoint protection product for consumers included a UEFI Scanner, there were two main reactions. Some folks said “Great!” and others said “What’s a UEFI Scanner?” This article provides answers to that question – I think we can assume that the people who said “Great!” are keen followers of developments in computer security and know that there are issues with this thing called 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 this was handled by something called BIOS or Basic Input/Output System, and in fact that used to be the case. However, today’s computers use UEFI instead, even though some still call it BIOS.
Like many other parts of a computer system, UEFI can be attacked in an effort to gain unauthorized 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, including rootkits and ransomware, target vulnerabilities in the UEFI and are highly persistent, even surviving after an operating system is reinstalled. In short, the ESET UEFI Scanner is designed to prevent these types of attacks.
UEFI’s predecessor, , was originally designed for 8-bit computers way back in 1975. I don’t think anybody expected it to be used into the next century. But occasionally, a technology resonates and outlives anyone’s expectations (mouse, anyone?). 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 and better security, something that was easier to update and expand without having to write assembly language code.
A more practical factor in the demise of BIOS was the need to support large hard drives. In 1975 nobody cared what happened when you had a hard drive larger than 2TB, which was large enough at the time to sound infinite. Not anymore!
Not only that, but wouldn’t it be nice if you had built-in network support in case you needed to download an update before booting. Also a better interface that was easier to understand and more extensible would be nice, as would some space to hold all this, possibly by storing it all on a hard drive, USB key, or some such, rather than the BIOS chip itself, with its relatively tiny capacity?
While this all sounds good, it turns out the implementation was hard. Widespread industry support was needed and someone had to take the initial leap. Eventually, Intel plunged in and created the EFI for their under-appreciated (and now discontinued) 64-bit Itanium processors, because BIOS just doesn’t do 64-bit. But to get more adoption, Intel opened EFI up by creating the (Universal Extensible Firmware Interface) , which then published a specification available for everyone to build against.
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 (in C code, thank you very much). And, the industry did just that: with everyone rolling out their own versions.
The adoption of UEFI was boosted by Microsoft which was a fan of the newly available options. The company declared that, as of Windows 8, UEFI would be a logo requirement for new 64-bit computers (older computers without 64-bit support can still be upgraded). 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 things breaking. As with any new technology, especially a potentially powerful, low level, trusted, and far-reaching one used to drive many of the newer computers coming to market, some things just didn’t work. 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 cornerstone 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. On top of this, UEFI has a bunch of complex steps (see the diagram below).
UEFI PI-based Boot Process (Zimmer, Dasari, & Brogan, 2009, p. 16)
Since hacking UEFI could ensure persistence and be largely undetectable with traditional methods, hackers looked for ways to gain access, escalate user privileges, and write directly to the UEFI Serial Peripheral Interface or SPI, the chunk of flash that holds all the binaries that are basically trusted to make your computer boot. Success would mean hackers had access to more system resources when loading their binaries, so some nasty low-level shenanigans could result.
Clearly, protecting the SPI was high priority. Internally, this is 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 binaries that get loaded against certificates, but SMM itself was found to be vulnerable, potentially allowing the execution of arbitrary code, and CVEs released against it. Significant effort has been expended trying to get all the vendors up to speed on assessing their own code for vulnerabilities, though often they don’t believe they may be vulnerable.
Remember, UEFI is just a guideline, and each vendor released its own version of what it thought was best for the operating system and their own hardware. That means there’s wild variation between different vendors’ gear. Furthermore, some vendors thought it might be interesting to release some binaries of their own, which were of debatable value to the consumer, but very difficult to remove for the average (or experienced) user. And as always, the rush to market tends to trump the rush to security.
In the world of security software development, the potential for new abuse vectors arising from UEFI meant that the need to scan UEFI innards became increasingly important. As a result, ESET embarked on scanning and understanding potential threats. Initially, there was little information about real world UEFI threats in the wild, but because ESET has a very wide footprint and intelligence system, it began to collect, vet and analyze potential threat vectors to protect this growing space.
In some ways this still seemed like a theoretical threat, until samples that were collected in the wild were analyzed, and later published. As with any new technology, 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.
As the hacker toolkits become more robust and extensible for UEFI, and the wild variation of patch levels persist, UEFI will continue to be a target. The need for effective UEFI scanning and threat blocking will only increase.
To read more about UEFI on We Live Security, see the following articles and papers:
(October 19, 2017)
(June 15, 2016)
(September 30, 2014)
(September 2014)
(June 3, 2013)
A white paper: (October 9, 2012)