And the Moon Bounced Over a Dumpster Fire: Three “Critical Truths” About Firmware Security
Last week’s revelation of the MoonBounce UEFI implant in the wild continues an ongoing trend of attacks on firmware (see a few recent examples like iLOBleed in HPE servers, Meris botnet in Mikrotik routers and the FinPSy UEFI bookit in Windows systems… the list grows continually.) Firmware security is complicated by multiple unique implementations and obscure hardware configuration details. Worse yet, vulnerabilities below the operating system (VBOS, as CISA calls them) are increasingly common and invisible to most security tools. This presents an attack surface that undermines normal defenses and keeps organizations from being alerted to the threat until it’s far too late.
While Eclypsium researchers have pioneered this area for many years, there remain a number of misconceptions about firmware security that can look like an ongoing dumpster fire hiding just below the operating system. To help clear these misconceptions, here are some critical truths about this attack vector and how to defend it.
- Secure Boot Protects the Bootloader, Not UEFI firmware itself
When firmware issues come up, one common recommendation is to use Secure Boot. But the details matter with firmware, and in the case of MoonBounce, Secure Boot is irrelevant. The purpose of Secure Boot is to check for modifications to the bootloader and PCI option ROMs from outside the built-in system firmware. That system firmware, itself, is trusted. Even if it weren’t, the checks being performed are implemented in the firmware, so the firmware would simply be checking itself.
Bottom line, Secure Boot is relevant to bootloader attacks like FinSpy and ESPecter but it does not offer any meaningful protection against UEFI implants like MoonBounce, MosaicRegressor, or Lojax. A false sense of security – e.g. the belief that a particular strain of technology can defend us against a specific attack – can be worse than no security at all.
- TPM, Boot Guard, and Other Technologies May Not Detect UEFI implants
Alteration of UEFI Firmware is both persistent and invisible. A common recommendation in the face of this stealthiness is to use the Trusted Platform Module (TPM), which stores hashes of code executed during the boot process. This usually begins with a Static Root of Trust for Measurement (SRTM), which is system firmware (eg. UEFI) that initializes the TPM and starts the process of hashing boot code into its Platform Configuration Registers (PCRs). These PCRs then show whether or not the boot process has been changed. Unfortunately, when the system firmware itself is compromised, it has a powerful counter: it can simply lie about these measurements.
If platform designers are paying a lot of attention, a hardware root of trust like Intel Boot Guard can be a useful detection mechanism for such changes. When securely configured (which has not always been the case), it prevents booting with altered firmware. Do your systems use Boot Guard securely? Figuring this out requires complex parsing of the firmware image and hardware registers, which is not exposed in any normal Windows or Linux configuration. Even when it is enabled, a secure configuration of Boot Guard will prevent you from using your computer at all until an authorized firmware image is restored. While this is a great way to prevent a stealthy and persistent attack, it unfortunately opens a door to the next Critical Truth:
- Disruptive Attacks on UEFI Firmware Can (and DO) Brick Systems
As our research has repeatedly demonstrated, access to change firmware grants the power to transform a perfectly fine computer into an expensive paper weight. The MoonBounce implant uses solid techniques to maintain stealth. Instead of dropping code to be executed by the OS (like the HackingTeam VectorEDK or Lojax implants), it modifies the OS in memory.
However, any mechanism used to install altered UEFI code would similarly allow for corrupting or erasing the firmware image. This means that firmware-based reconnaissance tools like TrickBoot and implants like MoonBounce can become extraordinarily disruptive by not only destroying data, but by breaking devices in a way that most organizations are unable to repair.
Putting Out the Dumpster Fire
The dumpster fire is fueled by blind faith. Every time a single manufacturer or technology can hide or bypass security, it becomes a single point of failure. In contrast, the Eclypsium approach to firmware security does not rely on any one party or technology. The Eclypsium Platform uses a continuous Identify, Verify, Fortify process to secure firmware across the enterprise. This process continually collects information about devices and the components inside them, including UEFI firmware, catalogs them, verifies them against known-good images or configurations, and assists in updating and patching these mostly inaccessible – but increasingly critical – bits of code.
The “Identify, Verify and Fortify” process provides the oversight and intelligence that turns disparate technologies, like Secure Boot, Boot Guard, TPMs and more, into a strategic and common-sense approach to fighting a growing string of dumpster fires.
Whether the device uses the latest and greatest technology (perhaps from an untrusted supply chain) or contains hardware and firmware that has been around the block a few times, critical information about the inventory, risks, and integrity of the device is readily available.
This puts you back in control of your devices and mitigates risk to your organization through intelligent risk decisions and continuous monitoring. Contact us any time for a demonstration.
