read: 2
At the 2024 RSA Conference, researcher Martin Smolar shared topics about UEFI Secure Boot and Bootkits. UEFI Secure Boot is designed to ensure that the code started by the computer's UEFI firmware is authentic, thereby protecting the system from malicious code being loaded and executed during the boot process before the operating system is loaded. Previous series of articles have introduced the basics of secure boot (1)(2), and this article will focus on the keys involved in secure boot, potential security vulnerabilities, and hardening methods.
1. What is UEFI Secure Boot?
Personal computers have been plagued by viruses, worms, and other malware for decades. Some of the earliest PC viruses spread as boot sector viruses: they were stored as code in the boot sector of a floppy disk and spread from one computer to another when the user started the computer using an infected DOS floppy disk. Although other methods of virus transmission have emerged as floppy disks have become less important and Internet connections have become more common, pre-boot malware has always been attractive to hackers. By executing before the operating system kernel gains control of the computer, malware can “hide” in a way that it cannot once the operating system gains control. As a result, pre-boot malware is difficult to detect (except by rebooting to an unaffected emergency system).
Figure 1 UEFI firmware location
BIOS/UEFI does little to prevent pre-boot malware; during the BIOS/UEFI boot process, the system trusts any program executed by the boot loader by default. Until the end of 2012, most EFI implementations were also like this. Traditional system boot is divided into the following steps: turn on the power – UEFI firmware – operating system (boot loader, kernel) on the hard disk.
Figure 2 UEFI boot process
During system startup, the UEFI firmware determines the boot order based on the Boot variables and executes the UEFI application in the ESP partition of the disk. As shown in the figure below, an attacker may modify the Boot order and the binary files in the ESP partition.
Figure 3 UEFI potential attack points
Secure Boot is designed to add a layer of protection to the pre-boot process. When Secure Boot is enabled, the firmware checks for the presence of a signature for any EFI program that is executed. If the signature does not exist or does not match the key in the computer's NVRAM or is blacklisted in NVRAM, the firmware will refuse to execute the program. A trusted EFI boot loader must continue to boot in a secure manner, ultimately achieving a secure operating system.
Important concepts in secure boot are the allowed signature database (db) and the forbidden signature database (dbx). The allowed signature database stores hashes and certificates of trusted boot loaders and EFI applications that the machine firmware allows to load. The forbidden signature database (dbx) stores revoked, compromised, and untrusted hashes and certificates. Any attempt to load signed code with the forbidden dbx key, or in the case where the hash matches a forbidden dbx entry, will result in a boot failure. Signing db and dbx requires the use of the Key Enrollment Key Database (KEK) and the Platform Key Database (PK).
These keys are used to sign boot loaders, drivers, firmware, and other software that runs. Most commodity PCs sold today contain keys controlled by Microsoft.
Figure 5 Keys involved in secure boot
2. Is a system with secure boot enabled absolutely safe?
Is a system absolutely safe as long as secure boot is enabled? We have summarized several types of vulnerabilities involving UEFI secure boot bypass.
Memory-related vulnerabilities: In January 2022, researchers discovered a secure boot vulnerability called “baton drop” (CVE-2022-21894) (3). Windows boot applications allow secure boot to be bypassed by setting “truncatememory” to remove memory blocks containing serialized data. The truncatememory BCD element removes all memory contents above the specified physical address from the memory map. The attacker performs this operation on each boot application during initialization before reading the serialized secure boot policy from memory. Although Microsoft quickly fixed this vulnerability, the “baton drop” attack was still exploitable for a long time because the affected UEFI binaries were not revoked, resulting in related vulnerabilities (4). It was not until May 2023 that Microsoft provided handling recommendations (5).
Figure 6 Microsoft repair process
Privileged commands and revocation list-related vulnerabilities: In 2020, researchers discovered that attackers could bypass secure boot by loading an unsigned grub module via insmod(6)(7). It took Microsoft several months to completely remove this vulnerability. Similarly, there are a large number of sensitive commands in the UEFI shell, and these commands must be disabled in devices with secure boot enabled(8)(9). In addition, some third-party PEs have also been found to have security risks. They load and run arbitrary UEFI binaries from hard-coded addresses(10).
Figure 7 The process of Microsoft repairing the related vulnerabilities
Debug-related vulnerabilities: ESET researchers found that the UEFI firmware of some brands of laptops has security risks. Attackers can directly create NVRAM variables from the OS to disable UEFI secure boot or restore factory settings (11).
Figure 8 UEFI secure boot vulnerability
3. How to control the secure boot keys to prevent Bootkits?
Traditional solutions, such as “updating to the latest version of the system, updating firmware, enabling secure boot, installing security software, etc.” are often not enough. This is because Bootkits often take months to completely remove, the removal may not be complete, and the signing process is not transparent. Therefore, we need to intervene as early as possible, for example, we can block any attempt to modify the ESP partition file, which can be achieved through a whitelist. In addition, secure boot can also be customized: fully customized and partially customized.
A fully customized secure boot removes all secure boot keys and uses only the user's own keys. All boot components are signed by the customer's keys. A fully customized secure boot is often difficult for users to maintain.
Some customized secure boot allows users to add their own keys to the PK and KEK databases. When a security vulnerability is discovered, users can take a step ahead and write the hash of the malicious program into dbx, avoiding the lengthy response from Microsoft/OEM manufacturers. For users who only use Linux, they can also remove the Windows UEFI CA from the db database to reduce the attack surface.
From the above custom secure boot, we can see that its essence is to regain control of the secure boot key. The author summarizes the benefits as follows:
Remove risks from default keys
In theory, secure boot should prevent malware from running. On the other hand, there is always the possibility that an attacker could trick Microsoft into signing malware, or that signed software could have vulnerabilities, such as the Boot Hole vulnerability discovered in 2020. If a shim with the default key is used and dbx is not updated accordingly, the computer will still be vulnerable to these threats.
Removing Risk from Release Keys
Similar to the previous case, it is also possible that the distribution key could be leaked, in which case an attacker could distribute malware signed with the leaked key.
Eliminate the need for MOK
Both the Shim and PreLoader tools rely on Machine Owner Keys (MOKs), which are similar to Secure Boot keys but easier to install. Because they are easier to install, they are more easily abused by social engineering or other means. Especially when managing a fleet of desktops used by other people, eliminating MOKs can increase security.
If you want to develop your own boot manager, you may want to test the signed version of the software in a simulated environment. However, the process of signing the binary with Microsoft's Secure Boot key is cumbersome and time-consuming, so you may want to use your own key to sign the binary yourself. When the software runs as expected, you can send it to Microsoft for signing.
In a dual-boot scenario, some computers will only boot into Windows by default; although you can temporarily boot into Linux and use efibootmgr to set Linux as the default boot loader, you will then find yourself booting back into Windows because the firmware has been setting Windows as the default. If the Linux boot entry is still there but is “downgraded”, setting your own boot key can solve this problem by removing Microsoft's key from the normal secure boot list and then adding it to the MOK list.
In the past few years, for Linux users, secure boot was somewhere between “not important” and “very troublesome”. Although secure boot has the potential to improve security, the related security risks have not been taken seriously. Therefore, although secure boot has theoretical benefits, it is unclear whether secure boot has practical benefits for computers that only use Linux. With the emergence of bootkits, people are paying more and more attention to the security risks caused by secure boot and corresponding vulnerabilities. Since manufacturers are unable to add malware to the revocation list in a timely manner, many vulnerabilities have appeared in the wild. Signing your own boot loader to use your own key can provide maximum security and flexibility. NSFOCUS will continue to pay attention to the progress of secure boot, and interested readers are welcome to continue to pay attention.
references
(1) https://mp.weixin.qq.com/s/wucSVNYYeg5d5fQ1I1cnAQ
(2) https://mp.weixin.qq.com/s/showAKatT3TsN11aWRD9GQ
(3) https://nvd.nist.gov/vuln/detail/CVE-2022-21894
(4) https://nvd.nist.gov/vuln/detail/CVE-2023-24932
(5) KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 – Microsoft Support
(6) https://nvd.nist.gov/vuln/detail/CVE-2020-7205
(7) https://nvd.nist.gov/vuln/detail/CVE-2020-26200
(8) https://nvd.nist.gov/vuln/detail/CVE-2022-343010
(9) https://nvd.nist.gov/vuln/detail/CVE-2022-34303
(10) https://nvd.nist.gov/vuln/detail/CVE-2022-34302
(11) https://nvd.nist.gov/vuln/detail/CVE-2022-3431
GIPHY App Key not set. Please check settings