Use and Abuse of Palo Alto's Remote Access Solution

Use and Abuse of Palo Alto's Remote Access Solution

Speaker: Alex (Security Engineer; former pen tester and red teamer), with research contributions from Graham

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=6IGmNLs4tk8

Reading time: ~9 minutes

Type: Briefing

TL;DR

Security researcher Alex uncovered multiple vulnerabilities in Palo Alto's GlobalProtect VPN client on macOS and Linux — including DNS-spoofing-based tunnel bypasses, forged IPC message attacks, and a local privilege escalation chain — revealing that the product's architecture places critical security decisions in an unprivileged process where attackers already operate. Most vulnerabilities have since been patched, but the underlying design flaws persist, and one DNS spoofing bypass remains unpatched by vendor choice.

Introduction

GlobalProtect is Palo Alto's flagship remote access product, combining core VPN functionality with enterprise features such as SSL traffic inspection, fine-grained egress controls, and data-leakage detection. It is deployed across a huge number of corporate endpoints worldwide — making it an exceptionally high-value target for attackers who have already landed a low-privileged shell on a machine.

The research, conducted by Alex and his colleague Graham, aimed at two goals: bypassing the VPN tunnel entirely, and escalating privileges on the host system. What emerged was not a series of isolated bugs but a structural critique of how GlobalProtect separates privileged and unprivileged operations — and what happens when that boundary is trusted more than it should be.

The DNS Spoofing Tunnel Bypass

GlobalProtect supports a split-tunnel configuration that lets administrators whitelist certain domains — for example, *.zoom.us — so that traffic destined for those hosts bypasses the VPN and goes directly to the internet. This is common practice for latency-sensitive applications like video conferencing.

▶ Watch: DNS Spoofing Attack Demo (04:00)

To implement this feature at the IP layer, GlobalProtect's kernel-level network extension monitors DNS traffic. When it sees a query for a whitelisted domain resolve to a particular IP address, it adds a direct route for that IP, bypassing the tunnel. The fundamental problem: DNS has no authentication. A low-privileged attacker with a foothold on the machine can send a DNS query for anything.zoom.us to an attacker-controlled resolver, which responds with the IP address of the attacker's C2 server. GlobalProtect dutifully adds a direct route for that IP, and the attacker's outbound traffic — including command-and-control communications and exfiltrated data — bypasses all corporate monitoring.

The bypass is also persistent: the direct route is cached for approximately one minute after DNS queries stop, giving a window of unmonitored connectivity even if the DNS request sequence is short. The speaker reported this issue to Palo Alto in April 2024. As of the presentation date, it remains unpatched — Palo Alto has stated they do not consider it a vulnerability in the macOS app.

Additional complications are inherent to the feature's design: DNS does not authenticate, CDN providers like Cloudflare use anycast so a single IP may serve dozens of domains, and there is no reliable way to bind an IP to a specific domain at the network layer. An open issue filed six years earlier against the OpenConnect VPN client identified identical concerns when a developer proposed implementing the same feature.

Breaking the IPC Trust Boundary

GlobalProtect's on-endpoint architecture consists of two key components: pan-gps, the privileged daemon that sets up the tunnel and modifies routes, and pan-gpa, the unprivileged UI component visible to the user. They communicate over a local TCP port (4767) using an AES-encrypted IPC channel.

▶ Watch: IPC Architecture and Encryption (08:00)

The encryption offered little real protection. On macOS the AES key is a function of a string stored in the login keychain — accessible to any low-privileged user. The initialization vector is hard-coded to all zeros. On Linux the key is hard-coded to a static string (global35protect). A CrowdStrike blog published years earlier had already documented this scheme. In both cases, any process running as the current user can encrypt and send arbitrary IPC messages to pan-gps.

To prevent replay and spoofing attacks, pan-gps checks which process is connecting to port 4767 using lsof. If the path of the connecting process is not inside the trusted Applications/GlobalProtect directory, the connection is dropped. However, this check had multiple bypasses.

Race-condition bypass (macOS): By timing a redirect on the port while lsof runs, an attacker can make lsof report a trusted GlobalProtect binary as the process holding the socket, while the actual malicious process connects moments later and sends the forged disconnect command. The demo showed successful disconnection and subsequent access to Dropbox — bypassing the corporate tunnel.

▶ Watch: Race-Condition IPC Bypass Demo (14:01)

Fail-open logic bypass (macOS): Reverse engineering the is_connected_by_pan function revealed a fail-open control flow: if any step in the process-verification chain encounters an error, verification passes rather than fails. By ensuring no process was connected to the port at the moment of the check, the function errored at every stage and returned success, allowing any process to send commands.

LD_PRELOAD bypass (Linux): Linux lacks macOS's System Integrity Protection, so LD_PRELOAD environment variable injection works against pan-gpa. By preloading a malicious shared library into the trusted pan-gpa process, the library executes code in a trusted context and sends the forged disconnect command.

Privilege Escalation via SUID and Child Processes

The second research goal was local privilege escalation. pan-gps has the SUID bit set, meaning it executes as root regardless of which user launches it. This is an acknowledged anti-pattern — many Linux distributions are actively removing SUID bits from system binaries — but it appears to be required because GlobalProtect uses a launch agent (which runs in user context) rather than a launch daemon.

▶ Watch: Privilege Escalation Chain (26:02)

pan-gps checks whether it was launched by launchd using ps to retrieve the parent process command. Because ps reads the command from argv in the parent's memory space, an attacker can craft a wrapper process that sets argv[0] to /sbin/launchd, fooling the check. Once pan-gps is running, it sanitizes the PATH environment variable to a hard-coded list of trusted directories — blocking simple PATH-hijacking attacks. It also ignores OPENSSL_CONF when running as a SUID binary, per standard security policy.

The breakthrough came from examining child processes. pan-gps spawns two child processes related to its host-information feature. Because pan-gps itself has real UID 501 (the user), it ignores OPENSSL_CONF. But those child processes are launched as root — with both real and effective UID 0 — meaning they do evaluate OPENSSL_CONF. An attacker can set OPENSSL_CONF to point to a configuration file containing a malicious engine (an arbitrary shared library) that executes as root. Combined with the argv[0] spoofing trick to start pan-gps, this chain achieved a root shell.

The fundamental design problem is that pan-gps runs with SUID rather than as a proper launch daemon. A launch daemon launched by launchd with root privileges would eliminate the SUID requirement and make the privilege escalation chain considerably harder to exploit.

Vendor Response and Patch Quality

Palo Alto was notified of the vulnerabilities in a phased disclosure process. The DNS spoofing bypass reported in April 2024 remains unpatched at vendor discretion. The IPC forged-message vulnerabilities were patched approximately one month before the talk — but initial retesting by the researchers found the patches ineffective.

▶ Watch: Patch Analysis (30:04)

The first patched version removed the lsof-based process check entirely rather than fixing it, meaning any process could send disconnect messages without restriction. Investigation of the new check revealed it was querying the wrong side of the TCP connection — identifying pan-gps itself (the server) rather than the connecting client — so the "trusted" binary it always found was GlobalProtect's own daemon. After further disclosure, a corrected patch was issued, and nearly all vulnerabilities are now successfully remediated. However, the plist-based configuration bypass — where an attacker modifies the user-readable preferences file to change the connect_method from with-passcode to allowed — and the broader architectural concerns around the SUID bit remain outstanding.

Notable Quotes

"This feature is based on misplaced trust. There's trust in the DNS server — how do we know we're speaking to the authoritative DNS server? Plain old DNS doesn't have authentication." — Alex, 06:00

"If at any of the stages something goes wrong, the verification passes. This really is contrary to the secure design principle that systems should fail in a secure state." — Alex, 14:01

"Bad design can't be patched — it needs to be rebuilt. True fixes really come from tackling root causes, not the symptoms." — Alex, 32:06

"Security software — it's still just software. Just because it's labeled as security doesn't inherently make it more secure. And actually, these tools often run with elevated privileges and might expand the attack surface of wherever they're installed." — Alex, 32:06

Key Takeaways

• DNS-based split-tunnel whitelisting is inherently untrustworthy. Any endpoint with an attacker-controlled DNS resolver can redirect split-tunnel traffic to arbitrary IPs. Organizations using *.domain.com wildcard split-tunnel rules should evaluate their exposure — this bypass still works in GlobalProtect for macOS.
• IPC channels between privileged and unprivileged components are a prime attack surface. When a security control lives in an unprivileged process (like pan-gpa), an attacker already in that process space can subvert it. The security decision of whether to disconnect must be made by the privileged daemon, not the UI.
• Fail-open error handling in security controls is dangerous. A verification function that returns success when checks fail creates an exploitable race condition. Security controls must default to the more restrictive state on error.
• SUID bits are a legacy anti-pattern. macOS launch daemons offer a cleaner, more auditable model for running privileged services. The GlobalProtect architecture would benefit from migrating away from SUID.
• Patches must address root causes. Removing a flawed check without replacing it with a correct implementation leaves the system more vulnerable than before. The first patches issued for the IPC vulnerabilities were regression steps.

Slides

No slides PDF was available for this talk. The speaker noted a detailed white paper or blog post would be published on their website following the conference.