One of the needs during CVE-2024-3400 testing (read this: was the ability to test against a live non-production vulnerable instance. We opted for the Palo Alto NGFW AWS Marketplace AMI. Although the AMI is patched against CVE-2024-3400, we found it relatively straightforward to create an EC2 instance from a patched AMI and then downgrade to a vulnerable version (Device > Software):

Although getting GlobalProtect setup is a blog post to itself, we eventually had our vulnerable instance going:

However, we still needed access to the filesystem to verify our files were being written. As stated elsewhere the PanOS CLI is limited. Furthermore, this AMI does not allow you to detach and mount the volume onto other instances. But there is another option. First, we take a snapshot of the running instance:

Then we used the tool by RhinoSecurityLabs to download the AWS snapshot:

dsnap get snap-151111aa340189a

With a local copy of the snapshot as an img file we now needed to move it into a VM. Although dsnap recommends using Vagrant+VirtualBox or Docker, neither seemed to be a viable option on an M2. Instead we can use qemu-convert to create a parallels compatible drive from the img file:

qemu-img convert -f raw -O parallels snap-151111aa340189a.img palo-10.2.9.hdd

Next we can mount the hdd files in Parallels as additional hard drives:

When we boot up the system, all of the Palo Alto directories are then mounted locally:

When you downgrade a Palo Alto NGFW it keeps both the old and new versions of the device. From our VM we can check in the panrepo mount to see that the active instance of the firewall symlinked to sysroot1 which symlinks to 10.2.9 (vulnerable) and the previous version symlinked as 10.2.9-h1:

Running an md5sum on the exploit point of dt_curl for example shows patched difference:

md5sum sysroot*/usr/local/bin/dt_curl
0a81d92a78b603fe2c73bcbe2863b0ff sysroot0/usr/local/bin/dt_curl
f3c7e9e3ea416b5f14a333abfecb317c sysroot1/usr/local/bin/dt_curl

Diff’ing between these versions we could see the changes highlighted by Rapid7 and others:

Obviously we could locally review the code as well:

With the drives mounted there was verification on the arbitrary file write artifacts from our test instance:

There you have it. From Twitter to Exploit.

In this 2 part series, we walked through a fairly typical lifecycle of 0-days, Tweets, cURL, and our approach at Sprocket. A 24-hour turnaround isn't bad either. During this testing exercise, we identified several areas where we can increase our speed. It's this constant, iterative approach that helps keep the Service Delivery & Research team and how we protect our customers.

We'll see you next 0-day :)