Finding a Fix for Firmware Vulnerabilities
By Aviram Shemesh
One of the foundational transitions in computing during the last decade has occurred in the firmware used to perform functions like hardware initialization during boot and runtime services during regular OS operation. As the usability and performance of generations of firmware raced ahead, their security often lagged behind, leaving the firmware world too slow for the threats it faces. Hackers have taken notice and escalated their attacks in both frequency and sophistication. The National Institute of Standards and Technology’s (NIST) National Vulnerability Database (NVD) shows that attacks on firmware have risen by 500% since 2018, and survey data from a new Microsoft report show that 83% of enterprise IT decision-makers have had their systems hit with a firmware attack in the last two years but that only 29% of the average security budget is dedicated to protecting the firmware level. This is unsustainable. A new solution is necessary in order to end this cat and mouse game altogether.
Firmware threats have found success from the very start
Pioneered in 1975 by IBM, BIOS, which stands for basic input/output system, refers to the physical chip on which CPUs run their firmware. The name legacy BIOS is used to refer to the original firmware running on that physical BIOS component. This legacy firmware is used to perform hardware initialization during the booting process (power-on startup) and to provide runtime services for OS and programs. BIOS firmware was initially stored on the BIOS chip on the motherboard but was later moved to the flash memory so it could be rewritten without removing a chip from the motherboard. This allowed for easy end-user updates to BIOS for adding new features or troubleshooting. This ease of access and alterability by end-users was popular but it also made BIOS vulnerable to bootkits. On top of that, it opened the door for attackers to issue malicious updates to the BIOS or to brick a motherboard entirely, intentionally or otherwise.
These vulnerabilities were exploited by BIOS threats like WinCIH, ACPI rootkit, Icelord rootkit, Mebromi, and Rakshasa, many of which rose to prominence in the late 90’s. Several of these attacks worked by preventing infected computers from booting, taking advantage of the fact that widespread OS’s at the time allowed direct hardware access for all programs. Modern systems do not allow users direct hardware access so many of these early generation threats grew obsolete. That said, BIOS attacks are prevalent enough that an improvement in firmware security was necessary.
Within the last decade or so, engineers began designing devices that swapped out the BIOS firmware for Unified Extensible Firmware Interface (UEFI) firmware that replaces the runtime interface of BIOS and addresses technical limitations by quickening speed of startup and shutdown, improving the interface, and supporting larger hard drives. UEFI firmware improved many different aspects in the firmware capbilities but what’s mostly important feature to our case here is the major emphasis on firmware and boot time security. The UEFI enabled OS vendors to intrduce the Secure Boot concept to the world, a priority given one of the primary strategies that BIOS attacks utilized was to corrupt the boot process. To give a brief description of Secure Boot, when a PC turns on, cryptographical safe process involving, TPM and\or chain of trust algorithms enables the system to ensure only the valid operating system bootloader will load (the UEFI Secure Boot ensures that a bootloader was signed by a trusted certificate before starting it), sequentially load a valid OS. It is an umbrella term for a complete set of features that are responsible to securing and attesting a modern OS boot process from power-on to actual user login. Without Secure Boot, it will just use whatever boot firmware is there without any sort of verification of whether that firmware should be trusted. Despite this important progress, much like other great security initiatives, the adoption rates of UEFI in general and secure boot in particular are far from being satisfying and many different platforms, especially legacy servers and IoT devices, still use legacy BIOS as before. Some of these platforms won’t be able to transition into UEFI at all.
Though the Secure Boot enabled by UEFI firmware offered an improvement over what legacy BIOS firmware was able to deliver, weaknesses remain. Hackers have discovered that if they could gain access into the UEFI firmware, they would subsequently be able to corrupt trusted platform measurements (that may be stored inside systems TPMs) used for remote attestation purposes, since these platforms relied on the UEFI firmware that enabled Secure Boot in the first place. In simpler terms, it’s a chicken and egg problem problem. Because UEFI and secure boot are controlled by the same system and OS they wish to protect, hackers rooting the system can easily gain control into the UEFI firmware. Subsequently everything that relied on that same UEFI firmware which is the OS and system itself is subject to compromise.
One famous piece of “in-the-wild” malware that specifically targets the UEFI firmware in this way is called “Lojax,” which works by infiltrating the LoJack anti-theft tracking software embedded in the UEFI flash.
Breaches into firmware like the Lojax malware are far more difficult to detect and resolve from higher layers in the stack. Not only do application-layer tools provide inadequate visibility and response tools for acting against firmware attacks to begin with, but once inside the firmware, attackers have the ability to disable these tools easily, achieving the highest level of permissions and control of every aspect of the system firmware and software levels alike. From there, they can then seize data or even infect other devices operating on the same network.
Software solutions like modern secure boot algorithms aren’t an adequate fix even if they are fully deployed either, recent cases like BootHole vulnerabilities, found within the Linux bootloader project or as evidenced by the recent exploitation of Surface Pro 3 convertible laptops and the Device Health Attestation (DHA) feature Microsoft introduced to validate BIOS, TPM, and Secure Boot, are becoming more common. In the more recent case of the DHA vulnerability, devices like the Surface store measurements from Platform Configuration Registers (PCRs) in a bank for health and attestation checks. These measurements about the device and software configurations during power-on events are made to ensure that the boot process is secure. However, according to Microsoft’s vulnerability report, certain devices do not feature any measurements of their PCR banks (e.g. Latest Ubuntu Linux). This is problematic because it allows arbitrary, false measurements to be made which means if crafty hackers can acquire a legitimate measurement log from a similar device, they can use it to enter copied measurements into the PCR bank of their target device. From there they can introduce malicious devices within enterprise networks and defeat the device attestation mechanism. Such vulnerabilities exist in the first place since all measurements and their configurations rely on an OS specific implementation they eventually wish to protect. This is software, which means it is accessible and therefore alterable.
These sorts of firmware and software attack strategies are often a vector for ransomware. With ransomware attacks on the rise, IT decision-makers must address this glaring vulnerability by moving the crown jewels off the firmware to somewhere attackers cannot reach – or even see.
Transitioning to an Isolated Security Processor
In order to secure a system against ever more ambitious and creative attackers, a Root of Trust (RoT) is necessary as an entity against which to check every layer of the stack from hardware boot to firmware load, OS runtime up until the running applications, throughout the entire stack. The only way for a computing component to be trustworthy in this way is for it to be immutable, a condition that eliminates any sort of software solution as an option. Attacks that exploit the RoT when it is hosted on UEFI firmware reveal firmware solutions are inadequate as well. A hardware solution is therefore necessary, and novel solutions like Kameleon’s Proactive Security Processing Unit (ProSPU) offload the RoT to an isolated security chip that is physically separate from the CPU to enable remote attestation for all motherboard components but also any peripheral device connected to the system.
Under this approach, attackers are unable to access (and thus corrupt) the RoT, meaning the integrity of its attestations is preserved. Isolated security chips like the ProSPU are also a good place to store keys, credentials, sensitive data, and security programming, as attackers will be unable to even see the assets and defenses they seek to exploit. Isolated SPUs are also more convenient to manage, as UEFI firmware authentication introduces logistical issues that can lock a CPU to a particular platform, which limits the ability to upgrade or change a CPU on the motherboard. Using a separate hardware solution for RoT authentication solves this issue.
All told, what CIOs, CISOs, and IT decision-makers need to realize is that their systems are very much vulnerable – especially at the firmware level. What is needed is a hardware root of trust that can be used to authenticate and authorize any alteration of any stack level, while remaining flexible enough to adapt to new vulnerabilities and enable security applications. Firmware attacks will only increase as hackers grow more ambitious – it’s long past time we all did something about it.