The computers and systems we use at
work and at home have to be secure. We work on confidential, sensitive
projects, and have PII on these every single day. This data being released into
the wild or for sale on the dark web would be a truly bad thing for everyone
involved. For business, there is also liability and fines which may be a
concern. These can be rather significant with certain industries (e.g.
healthcare). There is not a way around this. With the systems, the
cybersecurity has to be in place from the beginning of the operation. There can’t
be a lag. Any time this is not in place, the attack surface expands for the
attacker to examine. As the system starts, the boot process kicks in and begins
the operations. A recent attack focused on this part of the process. The new
exploit is a bootkit, since it resides in the bootloaders. The new attack has
been named “There’s a Hole in the Boot”.
The problem
at hand is with the bootloader process of the enterprise OS. In Linux systems,
the vulnerability is in the Grand Unified Boot Loader (GRUB). Most programs use
a program (i.e. shim) to extend the trust from the firmware to other programs securing
early during the boot process. The particular issue is with the configuration
parser in GRUB2 (grub.cfg) not properly exiting when there are errors present.
This is exploitable when you increase the size of a token with the grub.cfg.
This results in a heap-based buffer overflow. This acts to break the chain of
trust. At this point, the attacker may download a non-signed (e.g. malicious)
programs during this time in the boot process.
In Microsoft
systems, the successful attack allows arbitrary code to be executed and UEFI
(Unified Extensible Firmware Interface) Secure Boot restrictions bypassed. In
the Microsoft systems, the UEFI was engineered by the UEFI Consortium to
protect the boot process from attacks. This ensures only the immutable and
signed software is uploaded during the boot process and not malicious code,
which in theory makes it “secure”. The attack allows the attacker to execute
arbitrary code and bypass the UEFI Secure Boot restrictions.
Secure
boot has two steps, which are checking the allow (DB) and disallow (DBX)
databases. These are just as they appear. The allow database (DB) holds the
hashes and keys for the trusted loaders and EFI applications. These are allowed
to be loaded onto the machine’s firmware. Naturally, the disallowed database
(DBX) holds the revoked, compromised, and hashes/keys that are no longer
trusted. The boot process fails when any signed code on the DBX is presented.
The attack affects many different
systems and versions. In particular, this is targeted to Enterprise Linux 7 and
8, Red Hat Atomic Host, Openshift Container Platform 4 (RHEL CoreOS), Windows
10, 8.1, Server 2012, Server 2019, Server 1903, Server 1909, and Server 2004.
Issue
This is
a rather significant issue. This was researched by the security vendor
Eclypsium. As the responsible cybersecurity researchers, they did coordinate
the disclosure of the issue. The firm notified Microsoft, Linux distributors
(Red Hat, SuSE, Canonical/Ubuntu, and Debian), Citrix, VMware, computer original
equipment manufacturers, and software developers. This may seem like a rather
broad brush with notifying all of the organizations and groups. The risk with
the issue is rather large though. Nearly every Windows and Linux system using
secure boot is at risk. This also affects network appliances, proprietary gear
specific to healthcare, financial and other industries, internet-of-things
(IoT), operational technology (OT), and SCADA equipment in industrial
environments. Once this is exploited, the attackers are able to bypass the
secure boot process that is supposed to guard the system and disable other code
integrity checks. Once this is done the attackers are able to load arbitrary
executables and drivers. The attacker, once this is done, could nearly take
over the complete system.
To hack or not to
hack, that is the question
This appears to be a rather serious
problem, with billions of devices at risk. This attack is not as easy as other
attacks. To exploit this, you would need to have admin rights/root OR physical
access to a system. If an unauthorized person has access and admin rights or
physical access to a live system, you probably have larger systemic problems
than this. This also has a limited level of relevance for most cloud computing
uses, data centers, and personal devices. This has a limited application unless
the system is already pwned
Mitigation
There are updates available for Ubuntu 20.04, 18.04, 16.04,
and 14.04, and other systems. SuSE and Debian have released patches for this
issue. Red Hat recommends updating their GRUB 2 packages. Red Hat clients using
Secure Boot need to update the kernel, fwupdate, fwupd, shim, and dbxtool packages
with the newly validated keys and certificates.
While these are great, this is not a
quick fix. The mitigations will be a multi-step process and will take a long
process and take significant time to complete the patches. In the interim, the admins
need to monitor the contents of the bootloader partition (EFI system partition)
for their OS, test the revocation list updates, deploy revocation updates, and
engage with your third-party vendors to understand how they are addressing this
issue
Resources
Auscert. (2020,
July 30). There’s a hole in the boot. Retrieved from https://www.auscert.org.au/blog/2020-07-30-theres-a-hole-in-the-boot
Blinde, L. (2020,
July 31). NSA warns of GRUB2 BootHole vulnerability. Retrieved from https://intelligencecommunitynews.com/nsa-warns-of-grub2-boothole-vulnerability/
Brink. (2020,
July 29). BootHole vulnerability in secure boot affecting Linux and windows.
Retrieved from https://www.tenforums.com/windows-10-news/161603-boothole-vulnerability-secure-boot-affecting-linux-windows.html
Canonical. (2020,
July 29). USN-4432-1: GRUB 2 vulnerabilities. Retrieved from https://ubuntu.com/security/notices/USN-4432-1
Cimpanu, C.
(2020, July 29). ‘BootHole’ attack impacts windows and Linux systems using
GRUB2 and secure boot. Retrieved from https://www.zdnet.com/article/boothole-attack-impacts-windows-and-linux-systems-using-grub2-and-secure-boot/
Debian. (2020). GRUB2
UEFI SecureBoot vulnerability-‘BootHole’. Retrieved from https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/
Germain, J.M.
(2020, July 29). New security hole puts windows and Linux users at risk.
Retrieved from https://www.technewsworld.com/story/86778.html
Goodin, D. (2020,
July 29). New flaw neuters secure boot, but there’s no reason to panic. Here’s
why. Retrieved from https://arstechnica.com/information-technology/2020/07/new-flaw-neuters-secure-boot-but-theres-no-reason-to-panic-heres-why/
Goetting, B.
(2020, July 29). BootHole GRUB2 bootloader security exploit discovered, affects
billions of windows and Linux devices. Retrieved from https://hothardware.com/news/eclypsium-boothole
Ilascu, I. (2020,
July 29). BootHole GRUB bootloader bug lets hackers hide malware in Linux,
windows. Retrieved from https://www.bleepingcomputer.com/news/security/boothole-grub-bootloader-bug-lets-hackers-hide-malware-in-linux-windows/
Kovacs, E. (2020,
July 30). Companies respond to ‘BootHole’ vulnerability. Retrieved from https://www.securityweek.com/companies-respond-boothole-vulnerability
Kumar, M. (2020,
July 29). Critical GRUB2 bootloader bug affects billions of Linux and windows
systems. Retrieved from https://thehackernews.com/2020/07/grub2-bootloader-vulnerability.html
Meissner, M.
(2020, July 27). SUSE addresses BootHole security exposure. Retrieved from https://www.suse.com/c/suse-addresses-grub2-secure-boot-issue/
Microsoft. (2020,
July 29). ADV200011|Microsoft guidance for addressing security feature bypass
in GRUB. Retrieved from https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011
Monathan, J.
(2020, July 29). “Boothole” bootloader flaw breaks security on most Linux,
windows devices. Retrieved from https://securityledger.com/2020/07/boothole-bootloader-flaw-breaks-security-on-most-linux-windows-devices/
Murphy, I. (2020,
July 30). BootHole exposes billions of devices to attack. Retrieved from https://www.enterprisetimes.co.uk/2020/07/30/boothole-exploits-a-vulnerability-in-the-secure-boot-process-affecting-virtually-every-linux-distribution-windows-machine-and-other-operating-systems/
Red Hat Customer
Portal. (2020, July 29). Boot hole vulnerability: GRUB 2 boot loader-CVE-2020-10713.
Retrieved from https://access.redhat.com/security/vulnerabilities/grub2bootloader
/78
Saarinen, J.
(2020, July 30). Boothole GRUB2 bug breaks secure boot on Linux and windows.
Retrieved from https://www.itnews.com.au/news/boothole-grub2-bug-breaks-secure-boot-on-linux-and-windows-551050
Seals, T. (2020,
July 29). Billions of devices impacted by secure boot bypass. Retrieved from https://threatpost.com/billions-of-devices-impacted-secure-boot-bypass/157843/
Sheridan, K.
(2020, July 29). ‘BootHole’ vulnerability exposes secure boot devices to
attack. Retrieved from https://www.darkreading.com/vulnerabilities---threats/boothole-vulnerability-exposes-secure-boot-devices-to-attack/d/d-id/1338487
Solomon, H.
(2020, July 30). IT admins being warned of vulnerability in secure boot process
in Linux, windows. Retrieved from https://www.itworldcanada.com/article/it-admins-being-warned-of-vulnerability-in-secure-boot-process-in-linux-windows/433860
SUSE. (2020).
Security vulnerability: “Boothole” grub2 UEFI secure boot lockdown bypass.
Retrieved from https://www.suse.com/support/kb/doc/?id=000019673
No comments:
Post a Comment