Palo Alto Networks firewalls have UEFI flaws, Secure Boot bypasses – Source: www.csoonline.com

Researchers have discovered that next-generation firewalls from Palo Alto Networks contain years-old known vulnerabilities in their UEFI firmware — a finding that provides yet more evidence of a broader issue with specialized devices today. Increasingly built on commodity hardware, specialty devices share the same UEFI vulnerabilities as general-purpose PCs and laptops, inheriting similarly slow firmware patching cycles.

“We purchased multiple Palo Alto Networks security appliances, expecting a high level of security and resilience,” researchers from firmware security firm Eclypsium wrote in a new report. “Instead, what we found under the hood was commodity hardware, vulnerable software and firmware, and missing security features.”

The researchers tested the PA-3260, PA-1410, and PA-415 models of Palo Alto’s enterprise firewall devices, all of which are fully supported, although the PA-3260 is no longer actively sold. The discovered issues included UEFI vulnerabilities and insecure configurations that have been known for years, and that could be exploited by attackers with root access on the devices to implant malicious code into the low-level firmware or bootloader.

Known vulnerabilities that defeat Secure Boot

A standardized specification for firmware in systems with x86, x86-64, and ARM architectures, UEFI is the modern equivalent to BIOS and includes the low-level code responsible for initializing a computer’s hardware before loading the operating system installed on the hard drive.

Most motherboard manufacturers use UEFI implementations from one of three independent BIOS vendors (IBVs) — Insyde, AMI, and Phoenix — which they then configure and customize to their needs. This is also the case for the Palo Alto Networks firewalls tested by Eclypsium.

UEFI’s built-in Secure Boot is a security mechanism designed to prevent the loading of malicious or unauthorized code during booting processes. The feature uses certificates stored in firmware to check whether software components loading during boot, such as the OS bootloader, are digitally signed with trusted keys.

Palo Alto’s firewall device operating system, PAN-OS, is based on Red Hat Linux, which uses Grand Unified Bootloader version 2 (GRUB2). The company signs its GRUB2 bootloader and other components with its own certificates, which are stored in the UEFI certificate store to establish the chain of trust.

However, in 2020, researchers from Eclypsium found a critical buffer overflow vulnerability in the way GRUB2 parsed content from its configuration file, grub.cfg. Designed to be edited by administrators with various boot configuration options, grub.cfg is not digitally signed. But because attackers could now edit grub.cfg to trigger a buffer overflow and achieve arbitrary code execution inside the bootloader, they had a way to defeat Secure Boot and execute malicious code during boot time. This vulnerability, tracked as CVE-2020-10713, was dubbed BootHole.

At the time, Palo Alto Networks published an advisory about BootHole’s impact on its devices, saying that “this vulnerability is exploitable only when an attacker already compromised the PAN-OS software and gained root Linux privileges on the system,” noting that “this is not possible under normal conditions.”

That is because under normal conditions, a customer or admin user in the PAN-OS management interface is not meant to have direct root access on the underlying operating system. However, that doesn’t mean gaining root access through another vulnerability isn’t possible. For example, in April 2024, an APT group exploited a zero-day command injection vulnerability in PAN-OS (CVE-2024-3400) that allowed it to execute arbitrary commands as root. In November 2024, another group of attackers combined two other vulnerabilities, an authentication bypass (CVE-2024-0012) and another command injection (CVE-2024-9474), to achieve the same result.

Palo Alto Networks said at the time that it was working on a fix to prevent attackers from exploiting BootHole even when they had root access. But Eclypsium researchers have now found that the company never updated the DBX database in UEFI that can be used to disallow specific file hashes from being loaded, such as vulnerable versions of the GRUB2 bootloader. The researchers created a video of their proof-of-concept exploitation of BootHole and execution of a malicious payload during boot on the tested Palo Alto devices.

“The Palo Alto Networks Product Security Incident Response Team evaluated this potential vulnerability,” Palo Alto Networks told CSO via email. “It determined that the scenarios required for successful exploitation do not exist on up-to-date PAN-OS software under normal conditions with secured management interfaces deployed according to best practice guidelines. Palo Alto Networks is not aware of any malicious exploitation of these issues. We stand by the quality and integrity of our technology.”

Additional device-specific UEFI flaws

But even if Palo Alto patched BootHole, other flaws could allow attackers to defeat Secure Boot on some tested models. For example, the PA-3260 firewall, which uses Insyde Software’s InsydeH20 UEFI, is also vulnerable to LogoFAIL, a set of memory corruption vulnerabilities in the image parsing libraries used in UEFI implementations from all three major IBVs.

LogoFAIL flaws can be exploited by placing maliciously crafted images with a specific name on the EFI disk partition, which is mountable and writeable with root privileges.

“Exploitation occurs in the Driver Execution Environment (DXE), a very early stage of the boot process, allowing arbitrary code execution before the operating system and security agents load, allowing for much of the same attacks described above,” Eclypsium’s researchers said.

The PA-3260 UEFI also has a series of vulnerabilities in the code that controls the System Management Mode (SMM). These flaws have been known since 2021 and allow for privilege escalation and arbitrary code execution.

SMM is an operating mode called during a computer’s early boot process to load proprietary drivers and chipset configurations or to configure features such as power management. It does so by executing special firmware code stored inside protected memory accessible only from this mode. SMM is then locked when later parts of UEFI and the OS bootloader take over.

By exploiting these vulnerabilities, attackers can escalate privileges to some of the highest levels available, bypass Secure Boot and other security features, install persistent and stealthy malware, modify system configurations, and access protected memory regions, the Eclypsium researchers reported.

Meanwhile, the UEFI in the PA-1410 and PA-415 devices are vulnerable to PixieFail, a set of vulnerabilities found last year in the DHCPv6 implementation of the Preboot Execution Environment (PXE), an UEFI feature that allows booting a system from an image over the network, also known as network boot or netboot. These vulnerabilities enable denial of service, information leakage, remote code execution, DNS cache poisoning, and network session hijacking.

The PA-415 device also has misconfigured access controls for the SPI flash memory chip that holds the UEFI firmware. This could allow attackers to modify UEFI and bypass other security mechanisms, the researchers wrote. In addition, its Trusted Platform Module (TPM) 2.0 code has known vulnerabilities.

The PA-1410 device is impacted by the Intel Boot Guard keys leaked in 2022 as a result of a source code breach at Lenovo. Intel Boot Guard is an Intel hardware-based technology that uses cryptographic verification to prevent the execution of non-authorized UEFI code.

“While the conditions required to exploit these vulnerabilities are not available to users or administrators of PAN-OS software, we are working with the third-party vendor to develop any mitigations that may be needed,” Palo Alto Networks told CSO. “We will provide further updates and guidance to impacted customers as they become available.”

Earlier this month, Eclypsium researchers reported similar vulnerabilities and misconfigurations in the UEFI code of a DNA gene sequencer from Illumina. Even though it was a specialized device for medical laboratories, it used commodity x86 hardware made by a third-party OEM with a very outdated implementation of UEFI firmware.