Are you preparing to patch all your Linux, Windows and other devices today? No? Well, you should. Researchers at Eclypsium have announced BootHole. It is a vulnerability that affects virtually every Linux distribution, Windows and many other operating systems.
Eclypsium first found BootHole in April 2020. It informed all affected OS vendors allowing them to develop patches to resolve the problem. It says: “We expect to see advisories and/or updates from the following affected parties:
- UEFI Security Response Team (USRT)
- Red Hat (Fedora and RHEL)
- Canonical (Ubuntu)
- SUSE (SLES and openSUSE)
- Various OEMs
How dangerous is BootHole?
BootHole allows an attacker to evade the Secure Boot process and install their own bootloader. The bootloader verifies all the hardware and drivers required to start a computer and get it to the point where the operating system can take over. By installing their own bootloader, an attacker would gain near-total control over a device and compromise any OS installed on that device. It also allows them to install other malware and make a device unusable.
Another attack vector, and one that would appeal to state-sponsored attackers, is to use a compromised machine as a base camp. From here, the attacker could begin to compromise other machines and move laterally through a network.
To exploit BootHole, however, an attacker will first need admin privileges. That requirement for a machine to already be compromised is the only reason this is not being rated a critical vulnerability. However, before anyone gets complacent, privilege escalation attacks are on the rise.
One potential attack route against Windows servers would be to combine BootHole and SIGRed. There are still many Windows servers that have not been patched yet. An attacker combining the two attacks could use SIGRed to enable a BootHole attack which would allow them to stay on the machine, even when SIGRed is patched.
Attackers already in systems could use BootHole as a secondary attack. Take Ransomware. A company is hit, pays the ransom and gets its systems back. Meanwhile, the attackers have used BootHole to install a new bootloader. Even if the IT department increases its scans of software and adds additional protection, they are doing so on an already compromised system. The attacker can return later or sell the access on.
Cybercriminals already working on exploits
Another reason to patch immediately is that cybercriminals are already discussing potential exploits online. Overnight, on several Hacking as a Service (HaaS) and Malware as a Service (MaaS) forums, there have been questions as to how soon exploit code will be available. There is no question that a lot of effort will be put into developing and then marketing attacks over the next few days.
BootHole exposes other GRUB2 problems
While the focus today will be on BootHole, the fixes from vendors will also address several secondary issues with GRUB2. A search of the Common Vulnerability and Exposures (CVE) database shows that in 2020, there are seven other entries for GRUB2 in addition to BootHole (CVE-2020-10713).
This is not an unusual situation. Whenever a serious flaw is discovered in any piece of software, a complete review of all the code should be the norm. In this case, the review of BootHole uncovered several related issues that vendors will be patching.
A full solution could be some time away
In the Eclypsium blog, it sounds a serious warning that there is no quick fix for BootHole.
“However, full deployment of this revocation process will likely be very slow. UEFI-related updates have had a history of making devices unusable, and vendors will need to be very cautious. If the revocation list (dbx) is updated before a given Linux bootloader and shim are updated, then the operating system will not load. As a result, updates to the revocation list will take place over time to prevent breaking systems that have yet to be updated. There are also edge cases where updating the dbx can be difficult, such as with dual-boot or deprovisioned machines. When any OS is installed or launched, the bootloader and OS need to be updated before the revocation is applied to the system.
“Further complicating matters, enterprise disaster recovery processes can run into issues where approved recovery media no longer boots on a system if dbx updates have been applied. In addition, when a device swap is needed due to failing hardware, new systems of the same model may have already had dbx updates applied and will fail when attempting to boot previously-installed operating systems. Before dbx updates are pushed out to enterprise fleet systems, recovery and installation media must be updated and verified as well.”
What should you do?
Here are the five things that Eclypsium says organisations should start doing immediately.
- Right away, start monitoring the contents of the bootloader partition (EFI system partition). This will buy time for the rest of the process and help identify affected systems in your environment. For those who have deployed the Eclypsium solution, you can see this monitoring under the “MBR/Bootloader” component of a device.
- Continue to install OS updates as usual across desktops, laptops, servers, and appliances. Attackers can leverage privilege escalation flaws in the OS and applications to take advantage of this vulnerability, so preventing them from gaining administrative level access to your systems is critical. Systems are still vulnerable after this, but it is a necessary first step. Once the revocation update is installed later, the old bootloader should stop working. This includes rescue disks, installers, enterprise gold images, virtual machines, or other bootable media.
- Test the revocation list update. Be sure to specifically test the same firmware versions and models that are used in the field. It may help to update to the latest firmware first in order to reduce the number of test cases.
- To close this vulnerability, you need to deploy the revocation update. Make sure that all bootable media has received OS updates first, roll it out slowly to only a small number of devices at a time, and incorporate lessons learned from testing as part of this process.
- Engage with your third-party vendors to validate they are aware of, and are addressing, this issue. They should provide you a response as to its applicability to the services/solutions they provide you as well as their plans for remediation of this high rated vulnerability.
Enterprise Times: What does this mean?
BootHole is a serious threat to a lot of technology users from enterprises to individuals. Its ability to hijack the bootloader process makes it hard to detect, and the level of compromise it offers makes it highly attractive to cybercriminals and state-sponsored threat actors.
While there is no working exploit in the wild, as of the time of writing, it won’t be long before one emerges. For those organisations who are already compromised, it is one more weapon attackers can deploy for future attacks. Those who have yet to be compromised can expect to see increased activity once a working exploit appears.
Of great concern is the statement by Eclypsium that a full solution will take time to develop and deploy. It requires elevated levels of monitoring of the boot process. This is something that a lot of organisations and security software do not do by default. It means that this is an attack that will sit around for some time and create increased risk for organisations.