Using signed bootloaders to bypass UEFI Secure Boot protection

Russian version of this article.

Introduction

Firmwares of modern computer motherboards work according to the UEFI specification, and since 2013 they support the authentication technology of downloadable programs and Secure Boot drivers, designed to protect the computer from bootkits . Secure Boot blocks the execution of unsigned or untrusted program code: .efi-files of programs and operating system boot loaders, additional hardware firmware (OPROM video cards, network adapters).
Secure Boot can be disabled on any store motherboard, but a mandatory requirement for changing its settings is physical presence at the computer. It is necessary to enter the UEFI settings when the computer boots, and only then it will turn out to disable the technology or change its settings.

Most motherboards come only with Microsoft keys as trusted, which makes the boot software creators have to contact Microsoft to sign the bootloaders, go through the audit procedure, and justify the need to globally sign their file if they want the drive or flash drive to run without having to disable Secure Boot or add their key manually on each computer.
Microsoft has to sign loaders with Linux distributions, hypervisors, antivirus boot disks, and computer recovery programs.

I wanted to make a bootable USB flash drive with various computer recovery software that would boot without disabling the Secure Boot. Let's see how this can be implemented.
')

Signed loader downloaders

So, to boot Linux with Secure Boot enabled, you need a signed bootloader. Microsoft has forbidden to sign software licensed under GPLv3 because of the ban on licensing rules, therefore GRUB will not be able to sign .
In response to this, the Linux Foundation released PreLoader , and Matthew Garrett wrote shim , the small boot loaders that verify the signature or hash of the next downloadable file. PreLoader and shim do not use UEFI db certificates, but contain a database of allowed hashes (PreLoader) or certificates (shim) inside.
Both programs, in addition to automatically downloading trusted files, allow you to download any previously untrusted files in Secure Boot mode, but require the physical presence of the user: the first time you run, you must select the certificate to be added or the file to be hashed in the graphical interface, after which the data is entered into a special variable NVRAM motherboard that is not available to change from the loaded operating system. Files become trusted only for these pre-loaders, and not for Secure Boot in general, and it will still not be possible to run them without PreLoader / shim.


Actions required when the untrusted program is first run via shim.

All modern popular Linux distributions use shim, because of certificate support, which makes it easy to update the next bootloader without the need for user interaction. As a rule, shim is used to launch GRUB2 - the most popular bootloader in Linux.

GRUB2

To prevent intruders quietly from doing business with the help of a signed distro bootloader, Red Hat made patches for GRUB2 that block “dangerous” functions when Secure Boot is enabled: insmod / rmmod, appleloader, linux (replaced by linuxefi), multiboot, xnu, memrw, iorw. The chainloader module, which loads arbitrary .efi-files, added its own .efi (PE) loader, without using the UEFI LoadImage / StartImage commands, as well as the validation code of the loaded files via shim, in order to preserve the ability to load files trusted for shim but not trusted in terms of UEFI. Why they did it this way is not clear; UEFI allows you to override (hook) the function of checking the loaded images, this is how PreLoader works, and in shim itself there is such a function , but it is disabled by default.

One way or another, using the signed GRUB from some Linux distribution will fail. To create a universal bootable flash drive that would not require adding the keys of each downloaded file to the trusted files, there are two ways:

• Using a modified GRUB that loads EFI files on its own, without verifying a digital signature, and without blocking modules;
• Using your own pre-bootloader (second), redefining UEFI digital signature verification functions (EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState, EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication)

The second option is preferable - downloaded untrusted programs will also be able to download untrusted programs (for example, you can upload files through the UEFI Shell), and in the first version only GRUB itself can download everything. Modify the PreLoader by removing the extra code from it and allowing the launch of any files.

Total, the architecture of the flash drive turned out the following:

______ ______ ______ ╱│ │ ╱│ │ ╱│ │ /_│ │ → /_│ │ → /_│ │ │ │ → │ │ → │ │ │ EFI │ → │ EFI │ → │ EFI │ │_______│ │_______│ │_______│ BOOTX64.efi grubx64.efi grubx64_real.efi (shim) (FileAuthentication (GRUB2) override) ↓↓↓ ↑ ↑ ______ ↑ ╱│ │ ║ /_│ │ ║ │ │ ═══════════╝ │ EFI │ │_______│ MokManager.efi (Key enrolling tool) 

This is how Super UEFIinSecureBoot Disk appeared .

Super UEFIinSecureBoot Disk is a disk image with GRUB2 bootloader designed for easy launching of unsigned efi-programs and operating systems in the UEFI Secure Boot mode.

The disk can be used as a basis for creating a USB drive with computer recovery utilities, running various Linux live distributions and WinPE, booting over the network without disabling Secure Boot in the motherboard settings, which can be convenient when servicing foreign computers or corporate laptops, for example, when a password is set to change UEFI settings.

The image consists of three components: the Fedora shim preloader (signed by the Microsoft key preinstalled on the overwhelming majority of motherboards and laptops), the modified PreLoader preloader from Linux Foundation (to disable signature verification when loading .efi-files), and the modified GRUB2 loader.

During the first boot of a disk on a computer with Secure Boot, you must select a certificate through the MokManager menu (it starts automatically), after which the bootloader will work as if the Secure Boot is disabled: GRUB downloads any unsigned .efi file or Linux kernel loaded by EFI programs can run other programs and drivers with missing or untrusted signatures.

To demonstrate the performance, Super Grub Disk is present in the image (scripts for searching and booting installed operating systems, even if their boot loader is damaged), GRUB Live ISO Multiboot (scripts for conveniently downloading Linux LiveCD directly from ISO, without first unpacking and processing), One File Linux (kernel and initrd in one file, for system recovery), and several UEFI utilities.

The disk is compatible with UEFI without Secure Boot, as well as with old computers with BIOS.

Signed Downloaders

I was wondering if it is possible to somehow get around the need to add a key through shim on the first run. Maybe there are some signed downloaders that allow you to do more than the authors expected?
As it turned out - there are such loaders. One of them is used in Kaspersky Rescue Disk 18 - a boot disk with anti-virus software. GRUB from disk allows you to load modules (the insmod command), and modules in GRUB - the usual executable code. The pre-loader has its own disk.

Of course, just because GRUB from disk will not load untrusted code. It is necessary to modify the chainloader module so that GRUB does not use the UEFI LoadImage / StartImage functions, but instead self-loads the .efi file into memory, performs relocation, finds the entry point and navigates through it. Fortunately, almost all the necessary code is in the Red Hat GRUB repository with support for Red Hat Secure Boot , the only problem: the PE header parsing code is missing, the parsit header returns shim, in response to a function call via a special protocol. This is easily fixed by porting the appropriate code from the shim or PreLoader to GRUB.

This is how the Silent UEFIinSecureBoot Disk appeared. The resulting disk architecture looks like this:

  ______ ______ ______ ╱│ │ ╱│ │ ╱│ │ /_│ │ /_│ │ → /_│ │ │ │ │ │ → │ │ │ EFI │ │ EFI │ → │ EFI │ │_______│ │_______│ │_______│ BOOTX64.efi grubx64.efi grubx64_real.efi (Kaspersky (FileAuthentication (GRUB2) Loader) override) ↓↓↓ ↑ ↑ ______ ↑ ╱│ │ ║ /_│ │ ║ │ │ ═══════════╝ │ EFI │ │_______│ fde_ld.efi + custom chain.mod (Kaspersky GRUB2) 

Conclusion

In this article, we found out that there are not enough reliable bootloaders signed by the Microsoft key that allows operation in Secure Boot mode.
Using signed Kaspersky Rescue Disk files, we achieved a “silent” download of any untrusted .efi-files with Secure Boot enabled, without the need to add a certificate to UEFI db or shim MOK.
These files can be used both for good deeds (for booting from USB flash drives) and for evil ones (for installing bootkits without the knowledge of the computer owner).
I assume that the Kaspersky certificate will not last long, and it will be added to the global list of revoked UEFI certificates , which will be installed on computers running Windows 10 through Windows Update, which will disrupt the download of Kaspersky Rescue Disk 18 and Silent UEFIinSecureBoot Disk. Let's see how soon this happens.

Download Super UEFIinSecureBoot Disk: https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk
Download Silent UEFIinSecureBoot Disk on the ZeroNet Git Center : http://127.0.0.1:43110/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/