FinSpy UEFI and MBR BootKit
After examining the depths of device firmware and hardware security for many years, yesterday’s publication of FinSpy bootkit activity comes as no surprise. This development is simply one more reason why firmware is the new battleground for cybersecurity. The nature of firmware is to be invisible, which makes it a natural target for attacks.
Check out John’s quick take on what’s important about the recent FinSpy bootkit.
What happened?
The toolkit FinSpy (a.k.a. FinFisher and Wingbird) was revealed by Kaspersky to include bookit capabilities for modern UEFI-based boot loaders as well as the older “legacy boot” mechanism using the Master Boot Record (MBR). The FinSpy bootkit capability uses this persistence mechanism to alter code as it is loaded and executed during the boot process. True to form, they split up the infection process into multiple payloads that enable specific targeting and avoid systems that are likely to be used for malware analysis.
Why is this happening?
Over recent decades, the world has steadily increased its attention on the security of operating systems, applications, and networks. However, the firmware that inherently makes all of this work as we expect has remained invisible. No one wants to think about each component on a motherboard when powering on a device, and since firmware usually works, we don’t have to. The consequence, however, is that firmware did not get the same level of attention as cybersecurity became an important aspect of everything we do. Now, the people who monitor and protect systems often lack basic visibility into firmware and hardware. As a result, attackers move their activities to these invisible places to make detection and response more difficult.
What can I do to protect my systems?
Eclypsium researchers (in partnership with a great community of others) have been working on these challenges for a long time. Since this technique is not even close to the first of its kind, there are some easy defense mechanisms that organizations can apply to their systems. Defenders simply need to know they exist and ensure that they are working correctly.
First, the latest versions of UEFI firmware and common OS boot processes have incorporated signed bootloaders in a process known as UEFI Secure Boot. While there have been numerous vulnerabilities in this process (not the least of which is BootHole), UEFI Secure Boot was intended as a defense mechanism against this technique. To ensure that protections are properly enforced, organizations should verify that UEFI boot (not legacy boot) is in use and UEFI Secure Boot is enabled in BIOS settings. Eclypsium users can filter for systems with the Secure Boot security feature disabled in the device list. While not directly related to FinSpy, it is important to manually update the revocation list for UEFI Secure Boot in order to address vulnerabilities in this process.
Second, investigate and understand the cause for unexpected Bitlocker recovery events or other indications of boot integrity changes. Eclypsium users should consider creating alerts on changes to bootloader and MBR and confirm that such changes are the result of an authorized update. Of course, these can all be captured in the overall integrity policy and detection of a device integrity failure.
While the process of booting computers may be complicated and obscure, it isn’t much different from all the other complex software we try to secure. There is no reason for firmware to continue to be invisible and unprotected. Sign up to chat with one of our technical experts about this or other firmware and hardware security issues.