Views: 2915
Normally, Secure Boot prevents the UEFI from running all subsequent files unless they bear a digital signature certifying those files are trusted by the device maker. The exploit bypasses this protection by injecting shell code stashed in a malicious bitmap image displayed by the UEFI during the boot-up process. The injected code installs a cryptographic key that digitally signs a malicious GRUB file along with a backdoored image of the Linux kernel, both of which run during later stages of the boot process on Linux machines.
The silent installation of this key induces the UEFI to treat the malicious GRUB and kernel image as trusted components, and thereby bypass Secure Boot protections. The final result is a backdoor slipped into the Linux kernel before any other security defenses are loaded.
Diagram illustrating the execution flow of the LogoFAIL exploit Binarly found in the wild. Credit: Binarly
In an online interview, HD Moore, CTO and co-founder at runZero and an expert in firmware-based malware, explained the Binarly report this way:
The Binarly paper points to someone using the LogoFAIL bug to configure a UEFI payload that bypasses secure boot (firmware) by tricking the firmware into accepting their self-signed key (which is then stored in the firmware as the MOK variable). The evil code is still limited to the user-side of UEFI, but the LogoFAIL exploit does let them add their own signing key to the firmware’s allow list (but does not infect the firmware in any way otherwise).
It’s still effectively a GRUB-based kernel backdoor versus a firmware backdoor, but it does abuse a firmware bug (LogoFAIL) to allow installation without user interaction (enrolling, rebooting, then accepting the new MOK signing key).
In a normal secure boot setup, the admin generates a local key, uses this to sign their updated kernel/GRUB packages, tells the firmware to enroll the key they made, then after reboot, the admin has to accept this new key via the console (or remotely via bmc/ipmi/ilo/drac/etc bios console).
In this setup, the attacker can replace the known-good GRUB + kernel with a backdoored version by enrolling their own signing key without user interaction via the LogoFAIL exploit, but it’s still effectively a GRUB-based bootkit, and doesn’t get hardcoded into the BIOS firmware or anything.
Machines vulnerable …
Related
Discover more from 25finz, L.L.C
Subscribe to get the latest posts sent to your email.
No comments yet. Be the first to comment!
You must be logged in to post a comment. Log in