Critical pre-auth RCE revealed in Palo Alto Networks' GlobalProtect

Wait, what? (Patch this one urgently...)

A critical (CVSS 9.8) new Palo Alto Networks vulnerability allows for unauthenticated remote code execution (pre-auth RCE), said US security startup Randori, disclosing it on November 10 -- adding that it had identified over 10,000 internet-facing vulnerable instances, in a finding likely to send klaxons blaring across enterprise security teams. The Palo Alto Networks vulnerability has been assigned CVE-2021-3064 and was patched November 10.

It affects Palo Alto Networks GlobalProtect portal and gateway interfaces: a "next-generation" platform that includes a firewall and VPN setup that has thousands of large enterprise users around the world. Worryingly, Palo Alto Networks says that "due to the nature of the vulnerability, there is no reliable indicator of compromise" (IOC) but says there is no evidence it has been actively exploited in the wild. (At least, not maliciously...)

Controversially, however, Randori did not disclose it to Palo Alto networks for a whopping 10 months after identifying it -- and repeatedly used the vulnerability in Red Team (simulated attack) engagements for clients. (The company provides an adversary platform that aims to "mirror" the behaviour of attackers).

"If we utilize a 0day our customers must learn to deal with the reality that they cannot patch. Then, they realize they can implement multiple layers of visibility and introspection to detect *any* 0day" - Randori Principle Scientist Aaron Portnoy

Randori said: "Exploitation of the vulnerability chain has been proven and allows for remote code execution on both physical and virtual firewall products. Publicly available exploit code does not exist at this time... Public exploit code is likely to surface as VPN devices are attractive targets for malicious actors, and exploitation of PA-VM virtual devices in particular is made easier due to their lack of Address Space Layout Randomization (ASLR)."

The Waltham, Massachusetts company said it will not dislose further technical details for 30 days, but "bad actors" will be reverse engineering the patch rapidly and proof of concepts (POCs) likely to follow.

What Randori has disclosed is this:

  • "The vulnerability chain consists of a method for bypassing validations made by an external web server (HTTP smuggling) and a stack-based buffer overflow.
  • It affects Palo Alto firewalls running the 8.1 series of PAN-OS with GlobalProtect enabled (specifically versions < 8.1.17).
  • Exploitation of the vulnerability chain has been proven and allows for remote code execution on both physical and virtual firewall products.
  • Publicly available exploit code does not exist at this time. 
  • Patches are available from the vendor.
    • PAN Threat Prevention Signatures are also available (IDs 91820 and 91855) to block exploitation of the issue.
  • Public exploit code is likely to surface as:
    • VPN devices are attractive targets for malicious actors, and
    • Exploitation of PA-VM virtual devices in particular is made easier due to their lack of Address Space Layout Randomization (ASLR)."

Palo Alto Networks vulnerability: Pre-auth RCE as root

It began using the vulnerability chain in Red Team engagements in December 2020 and disclosed it to Palo Alto networks in October (the buffer overflow component) and November (the HTTP smuggling element).

One critic noted on Twitter: "Pretty syre [sic] that if we contracted a supplier and it turned out they had been sitting on a 0-day for something we used for so long, their ethics would be seriously questioned..."

Responding to criticism that the company had been irresponsible using an 0day in Red Team engagements (an approach that many observers found bizarre, given the ostensible aim of such engagements is to reveal to commissioning organisations where their security holes are; something that can't be done if a "secret" 0day is being used in the security testing, Randori's Aaron Portnoy responded on Twitter: "The ability to validate designed procedures that have never been activated is a fundamental benefit to testing with [an] authentic 0day. We are acutely aware of the risks associated with maintaining these capabilities. We actively weigh the risks and attempt our best at balancing them...

"If we utilize a 0day our customers must learn to deal with the reality that they cannot patch. Then, they realize they can implement multiple layers of visibility and introspection to detect any 0day."

https://twitter.com/jayjacobs/status/1458557384704602116

While some eyebrows were raised at Randori's approach, one security expert, Matthew Hickey, the CEO and co-founder of Hacker House, defended the company's approach, noting on Twitter: "Palo Alto developed the software, introduced the bug, didn't detect it being exploited in their devices and if hadn't been notified the exploit would continue to be used. If Randori found it and went undetected, criminal threat actors could've found it and exploited it too... Ultimately the team disclosed the issue rather than sell. There is no right or wrong answer to these debates, but remember that Randori only pointed out how broken Palo Alto's software, the software fault and errors are the vendors responsibility."

He aded: "As for using 0day on an engagement, it's perfectly valid and acceptable - providing the risk scoring is adjusted to reflect that it requires advanced specialist knowledge and that the scope includes reviewing other defenses like EDR / logs / firewalls / design etc. Any good exploit developer will be able to tell you mitigations or configuration changes that can be applied to limit exploitation, even if a bug is 0day there are additional layers that should be applied to your network for detection and auditing purposes alongside mitigations."

Palo Alto described CVE-2021-3064 as a memory corruption vulnerability in Palo Alto Networks GlobalProtect portal and gateway interfaces that "enables an unauthenticated network-based attacker to disrupt system processes and potentially execute arbitrary code with root privileges. The attacker must have network access to the GlobalProtect interface to exploit this issue [as per the above, there are tens of thousands of organisations that have exposed network access to the interface]. This issue impacts PAN-OS 8.1 versions earlier than PAN-OS 8.1.17."

Exploitation is likely to follow in short order.

An Apache HTTP Server vulnerability (CVE-2021-41773) reported in October has already shot into the top 10 list of most exploited vulnerabilities, according to data this week from security firm Check Point, as POCs proliferate. CVE-2021-41773, disclosed on October 4, 2021, is a directory traversal vulnerability introduced through a recent changedesigned to improve performance in the URL validation in Apache HTTP server 2.4.49. It gives full unathenticated remote code execution (pre-auth RCE) powers by an attacker over the open-source HTTP server, which is the second-most popular web server, used by 31.6% of all websites as of November 11.

The rapid, industrial-scale abuse of the vulnerability is a fresh reminder that pre-auth RCE vulnerabilities start getting exploited stupendously fast and aggressively.

See also: 7 free enterprise cybersecurity tools to be aware of