Local Privilege Escalation in Palo Alto's GlobalProtect

During my research on VPN solutions, I uncovered an anomaly in the behavior of one solution in particular, which is Palo Alto Networks’ GlobalProtect VPN client. This led me down a rabbit hole of extensive analysis and research, which got me to discover a high-severity local privilege escalation vulnerability (CVE-2023-0009).

This vulnerability enabled users to elevate their privileges to SYSTEM using token impersonation by abusing named pipes. Furthermore, it allowed for the capture of a domain-joined machine’s NTLMv1/NTLMv2 hash over the network, which can be then abused for relay attacks such as the infamous Shadow Credentials relay technique.

Disclaimer: I’ll do my best to explain how to replicate the discovery of the vulnerability, but I’ll have to cut a bit off the exploitation steps for obvious reasons. It can be considered as it is left for the reader as a challenge ;)

CVE Details

• Affected Vendor: Palo Alto Networks

• Affected Software: GlobalProtect for Windows

• Affected Version: <6.1.1, <6.0.5, <5.2.13

• Date Published: 2023-06-14

• Vulnerability: Local Privilege Escalation (PE)

• Severity: High

• Identifiers: CVE-2023-0009 / GPC-16078

• Reference: https://security.paloaltonetworks.com/CVE-2023-0009

GlobalProtect Architecture

VPN solutions often employ a dual-component architecture, featuring a privileged component running in the form of a service (or a driver) for network operations, and a user-friendly component for users to interact with. GlobalProtect VPN client uses this dual-component as follows:

1. PanGPA (GlobalProtect Application): A process running in the user-context which provides the user with a graphical user interface (GUI) to interact with and configure profiles to initiate and manage VPN connections.

2. PanGPS (GlobalProtect Service): A service running in the SYSTEM-context which is responsible for setting up network interfaces and applying proper configurations to establish a VPN connection.

GlobalProtect utilizes Interprocess Communication (IPC) over TCP (Port: 4767) to enable the exchange of data between PanGPA and PanGPS. This data includes the portal address, username, password, and other VPN settings. To ensure the security of this communication, encryption is typically implemented, thus preventing direct access.

Vulnerability Discovery

An easy method to take a peak at the IPC data is to simply intercept the data in the process of PanGPA.exe using API Monitor, or more precisely, by looking at the parameters passed to and the values returned from the encryption and decryption API calls.

Looking at the monitored calls, I observed that the EVP_EncryptUpdate function handles the encryption of traffic outgoing to PanGPS.exe, whereas the EVP_DecryptUpdate function handles the decryption of traffic incoming from PanGPS.exe using the IPC channel.

After analyzing the plaintext IPC traffic, which is mostly in XML format, some elements were interesting and very tempting to be played with, such as <path>.

To assist with tampering with the XML data, I used Frida to hook EVP_EncryptUpdate as well as ProcMon to monitor for any anomalies in the process behavior.

Starting with writing a javascript skeleton code for Frida to print out the data:

//Snippet code to hook EVP_EncryptUpdate and print the XML data.
var hooked_function = Module.findExportByName("libeay32.dll", "EVP_EncryptUpdate");
console.log("## Hooked EVP_EncryptUpdate in PanGPA.exe ##"); 
Interceptor.attach(hooked_function, {
    onEnter: function(args)
    {
		var xml_buffer = Memory.readCString(args[3]);
		console.log("XML Data" + xml_buffer);
	}
});

And then running the script with Frida on the PanGPA process:

While watching ProcMon, I observed that after the IPC traffic is communicated, PanGPS.exe is attempting to open a file with SYSTEM integrity in the GlobalProtect folder in the user’s AppData.

This matches the path that is sent over IPC in the XML data, which gives a possibility that it can be controlled by tampering with the <path> element before it is sent to the PanGPS. To do so, I modified the Frida script to replace the AppData path to C:\SomeWhereElse\:

//Snippet code to replace the path element in the XML data.
if(xml_buffer.includes("<path>")) {
	var buf = Memory.allocAnsiString(plaintext.replace("C:\\Users\\User\\AppData\\Local\\Palo Alto Networks\\GlobalProtect\\", "C:\\SomeWhereElse\\"));
	this.buf = buf;
	args[3] = buf;
	console.log("XML Path variable was found and replaced.");
}

Now comes the moment of truth, running the Frida script and checking ProcMon.

Voilà! The PanGPS.exe service is now accessing our tampered path, confirming that it is possible to alter the location it tries to access… Now what if this was abused by providing a UNC path instead? Yup :D

Vulnerability Exploitation

I’ll outline two exploitation vectors on a high level, but there are likely additional possibilities to be explored:

• Authenticating to a local named pipe leads to token impersonation of SYSTEM.
• Authenticating to a remote SMB file share to capture and/or relay the NTLMv1/NTLMv2 hash.

Local Named Pipes

Similar to abusing the famous Potato genre exploits (Hot, Rotten, Lonely, Juicy, Rogue), this vector requires an impersonation privilege (e.g. SeImpersonate, SeAssignPrimaryPrivilege).

The exploit works by creating a named pipe, and then redirecting the SYSTEM access to it by tampering with the path element (e.g. \\.\pipe\arman\PanUAC_<hash>.dat). This will force an authentication to the named pipe and allow impersonating the SYSTEM token which was part of the negotiation process. This process can be done through a series of Windows API calls.

The hash in the name of the PanUAC file can be known, as it is the md5-checksum of the user-controlled string <portal>_<username>. (source)

Relaying the NTLMv1/NTLMv2 hash

A more practical (and more severe) vector that does not require additional privileges would be tampering with the path to a remote SMB location (e.g. using Impacket/Responder), and then capturing the NTLMv1/NTLMv2 hash for offline-cracking, and more importantly relay it… Shadow Credentials anyone? ;)

Implementing the full steps of the Shadow Credentials relay attack is out of the scope of this post, but you can read more about it here. Also, it is possible to combine the exploitation steps done in Frida by utilizing the Windows C-Library named detours in your exploit code.

Conclusion

As fun as researching for red team operations can be, there’s nothing more satisfying than finding a zero-day while doing it, especially on a piece of software that A LOT of enterprises rely on.

The methodology used can be applied against other VPN solutions and be as effective. Examining IPC traffic has a high potential for finding anomalies that may lead to the discovery of vulnerabilities.

The approach of using API Monitor and ProcMon as a combination saved a lot of time in reverse engineering the low-level functionalities, and using Frida to build a Proof-of-Concept made verification, validation, and exploitation as simple as writing a few lines of JavaScript.

Overall, the lack of validation in the IPC traffic between PanGPA and PanGPS allowed for privilege escalation. This was exploited by leveraging token impersonation privileges and by forcing an authentication to a remote location, which can be used for relay attacks.

Special thanks to my team at Zurich Insurance for their ongoing support. I hope that you have enjoyed reading this post, as much as I have enjoyed discovering and reporting this vulnerability.