I guess I’m going to keep reading the same old stories about the same old hacks because we’re using the same old systems.
FireEye recently published a report on a malware package called Nemesis, which exploits the classic Master Boot Record (MBR) boot process. This isn’t surprising since MBR bootkits & rootkits have been a virus attack vector since the days of “Insert Disk in A: and Press ENTER to Continue.” What is surprising is how many critical systems are still susceptible to this form of attack.
I’ve written about firmware security before, typically under two circumstances:
- Someone claims a firmware security technology isn’t built for a realistic threat model.
- Someone publishes an article about an attack vector that would have been stopped by a firmware technology that was previously described as useless.
UEFI Secure Boot has commonly been included in this discussion cycle, which is relevant because attacks like Nemesis BOOTRASH and GrayFish specifically attack MBR-based OS loaders. Yes, GrayFish is the attack I referred to in my February post on firmware security. It’s not an anomily (hello Carberp and friends). The techniques have been expanded to modify the VBR in addition to (or instead of) MBR to avoid detection, but the basic technique isn’t new.
In fact, the technique is so old that it can’t work on UEFI. Example:
Prior to installation, the BOOTRASH installer gathers statistics about the system, including the operating system version and architecture. The installer is capable of deploying 32-bit or 64-bit versions of the Nemesis components depending on the system’s processor architecture. The installer will install the bootkit on any hard disk that has a MBR boot partition, regardless of the specific type of hard drive. However, if the partition uses the GUID Partition Table disk architecture, as opposed to the MBR partitioning scheme, the malware will not continue with the installation process.
— Thriving Beyond The Operating System: Financial Threat Group Targets Volume Boot Record [fireeye.com]
A Windows system formatted using a GUID Partition Table (GPT) is likely to be based on Microsoft Windows 8 or Microsoft Windows 10, and the underlying firmware will be based on UEFI (legacy BIOS won’t boot to GPT). BOOTRASH relies on a legacy disk interrupt (INT 13h) that won’t exist on a system booting with UEFI, and UEFI Secure Boot signature checking would block an equivalent bootkit on a subsequent boot.
In other words, this form of attack doesn’t work on new laptops or desktops pre-installed with Microsoft Windows 8 or Microsoft Windows 10 (they ship with UEFI Secure Boot on and the CSM off). But for hackers, that’s not where the money is … literally and figuratively.
New variations of MBR attacks keep popping up because so many critical systems rely on older platforms. Microsoft Windows 7 and Microsoft Windows XP are still used in the financial services sector … banking, payment processing and lots of other places I’d rather not have hackers poking around while I’m saving up for the holidays. The “embedded” versions of these operating systems are a big part of how the modern era shops and banks.
I could go on about to use UEFI Secure Boot, even on Linux, to build custom security solutions … or give examples of companies that have done just that. But that’s not going to work if the solution doesn’t work on outdated platforms. Security isn’t just installing virus protection or updating standards documents, it has to be a full stack approach. If you’re not willing to upgrade the bottom of that stack, then expect to be featured in a security journal sometime soon.