Don’t Freak Out. Scary Firmware Bugs Are Not Invincible.

Don't Freak Out

This October, the kids might show up looking like an unpatchable firmware bug in critical systems. It’s a good choice because that costume can look like anything. In this post, we will walk through a couple of examples of scary bugs and discuss each weakness. 

We can start by walking through selected techniques from MITRE’s ATT&CK framework. In particular, focusing on techniques for Persistence, Privilege Escalation, and Defense Evasion. Many of the in-the-wild attacks use common methods, often based on social engineering, for initial access. They follow this up with normal executables or scripts for execution. In cases like these, normal defense mechanisms have good coverage, but this context allows attackers to slip into the noise and show up at your doorstep. What comes next is the scary part. Dun, dun, DUN!!!!!

The Pre-OS Technique

While there are many techniques available to attackers, we will focus on techniques commonly used in bootkits. The unique part here is mostly covered in pre-OS boot. This provides a way of accomplishing techniques like auto-start executables/scripts and creating/modifying system processes. Usually, we expect this with file modifications on disk or in-memory modification as code is loaded for execution. Even with good code integrity protections built into a system, certain pieces of code are responsible for enforcing this integrity property, and they need to be tamper-proof. If the initial loading and execution of that module are compromised, however, that property will be almost impossible. That’s where the Pre-OS Boot technique comes in.

So, what runs in the “Pre-OS” stage of boot? The answer is, “more than you might think”. Initial hardware setup usually occurs early after the system is powered on. This can involve many modules that depend on each other to enumerate and configure the attached devices and components. Then, a bootloader runs to load the operating system. Then the operating system takes over control of the system and runs it in a familiar fashion.

Every operating system has various security enforcement functions, which  include deciding when to run an executable and what kind of privileges to allow. For kernel-mode executables, also known as drivers, this is especially important, since they have ultimate privilege to anything. If it is securely operating, only specific, authorized code can run in kernel mode. 

However, there are always ways to turn off or otherwise disable security. In the worst case, the kernel itself can be modified to ignore such checks. If OS files on disk were modified, that would often be detected quickly. If the modification happens in memory, there is only a short window of time to detect the change. If that in-memory change happens before the rest of the system is running, then other tools may not even have a chance to see what is happening. That’s the scary idea behind bootkits that tamper with the OS. The OS doesn’t have to be flawed in any way. The flaw and the attack both happened before they had a chance to defend themselves.

Perhaps the spookiest part about this is the amount of recent examples that have started to surface this year. FinSpy and ESPecter bootkits used malicious bootloaders to accomplish this. Lojax and MosiacRegressor attacks dug deeper into UEFI firmware, but didn’t even bother to make in-memory changes. Instead, they dropped files to disk in a Startup folder that will be automatically executed by Windows. 

Leveraging a pre-OS boot technique enables all the usual suspects for making malicious software run. A remote access trojan might simply launch as a normal executable file, or it may be hidden inside an obfuscated script that runs with a signed interpreter in order to complicate detection. Given the multitude of signed software and methods of obfuscation, these techniques usually work well, as most red team organizations can attest. This puts a lot of pressure on detecting pre-OS changes before they happen, often using a combination of firmware and OS features in a complicated secure boot process. That’s where firmware bugs can haunt us.

Sometimes Unpatchable. Never Unstoppable. 

Because the pre-OS boot process is outside of end-user administrator control, there are some frustrating constraints. Devices may use the same firmware/hardware features, but not provide all the configuration options that are technically possible. Sometimes this is even considered a security feature so that users don’t inadvertently disable security or make systems unusable. Devices also contain dozens of components that interact with each other using their own, independent firmware. An update to one component can, therefore, affect the operation of other components, making some potential firmware upgrades fail. As a result, a manufacturer may not release all the upgrades or all the configurations. Depending on supplier relationships, they may not even be able to control certain components. This can leave you with known vulnerabilities and no obvious solution. 

Sometimes the solution does not need to be obvious, though. Firmware is just software, but we do interact with it differently. Since we don’t have the same controls in firmware, we are forced to test our assumptions more. We need to verify first, and we need to continuously re-verify. When applied to devices, this merges aspects of inventory, vulnerability management, and threat detection. As with most real-world infrastructures, the internal firmware and hardware components of a device are unlikely to be fully inventoried and fully patched all the time in every instance. 

Eclypsium’s comprehensive platform does this by frequently collecting attributes of firmware and hardware components and developing device profiles. Some profile properties indicate vulnerabilities or weak configurations. Others simply help identify what is in the device. Anomalies in the profile are cause for further investigation, sometimes revealing a new or uncommon version, but other times indicating an unauthorized change or malicious event. This allows a reasonable threshold of risk to be set and enforced given a fixed investment of resources.