Palo Alto Exploit Analysis of CVE-2024-3400

Recently a vulnerability was disclosed in Palo Alto PAN-OS software. More details were provided by the NIST NVD as below.

• Python Script Sample - Download Link

A command injection vulnerability in the GlobalProtect feature of Palo Alto Networks PAN-OS software for specific PAN-OS versions and distinct feature configurations may enable an unauthenticated attacker to execute arbitrary code with root privileges on the firewall. Fixes for PAN-OS 10.2, PAN-OS 11.0, and PAN-OS 11.1 are in development and are expected to be released by April 14, 2024. Cloud NGFW, Panorama appliances, and Prisma Access are not impacted by this vulnerability. All other versions of PAN-OS are also not impacted.

The overall severity is marked a HIGH which had brought it intot he limelight.

Rapid7 has provided more details on the affected version of the PAN-OS and which softwares/applications were affected by this vulnerability.

In this article, we are going to get throught the vulnerability and will take a look on one of the samples available to have more technical intelligence around the same.

About CVE-2024-3400

This CVE is assigned to a command injection vulnerability in Palo Alto Networks PAN-OS software enables an unauthenticated attacker to execute arbitrary code with root privileges on the firewall

Complete list of functionalities can be checked on the below link.

https://docs.paloaltonetworks.com/compatibility-matrix/globalprotect/what-features-does-globalprotect-support

No official statement can be seen so far now stating which API/Application functioanlity was compromised.

However, taking a look at one of the exploits available on GitHub provide more details.

https://github.com/deFr0ggy/CVE-2024-3400/blob/main/exploit.py

The exploit mentions the API endpoint of PAN-OS XML based APIs.

Validating the same on the official website proves that the API endpoint is correct.

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-panorama-api/get-started-with-the-pan-os-xml-api/explore-the-api/use-the-cli-to-find-xml-api-syntax#id4a54bd95-27d2-43d6-920a-cf194a5380d1

The vulnerability lies in the cmd parameter where code type and code value can be defined.

In the exploit above, the value of code= attribute can be changed to any working command on the operating system while the payload provided as the value will eventually gets executed by the program on the operating system.

So far, no actual command and exploit profile has been shared in the community. Thus, it is unsure how the exploit landed on the OS.

Recently a python file has been shared on MalwareBazaar, which might give us more information. So far, we are assuming that the threat actors were able to push this file via the API directly onto the operating system externally.

The other misconfigration which can be observed from the exploit code and the information provided on the official website is that the exploit code does not includes the API KEY however, in the code snipper provided on the official website API KEY is required to be within the request body/URL.

Malicious Python Script - Analysis

Initials

Taking a look onto the malicious python script, it can be seen that it is pretty basic and is encoded in base64.

Decoding the first part of encoded sample reveals another base64 encoded data.

Finally the functioncode variable value is also base64 encoded.

Closer Look - 1st Stage

Starting with the initial analysis of the python script, the script is being added to the system.pth so that when the python starts up on the machine, it looks for all the modules in the path and loads them up automatically rather than specifying it specifically.

systempth = "/usr/lib/python3.6/site-packages/system.pth"

When system.pth is found the scripts write the payload and then using the os methods atime and mtime i.e. Last Accessed Time and Last Modified Time it changes the Last Accessed and Modified time of the script to make it look like it was part of the initial installation of the python.

Finally, using the unlink to delete the files in the below path and ending with PA_VM.

os.unlink(glob.glob("/opt/pancfg/mgmt/licenses/PA_VM`*")[0])

Closer Look - 2nd Stage

In the second stage i.e. the first base64 encoded payload, we can observe it stats a process with the base64 encoded payload.

But before the process is started, the script searches for a binary /usr/local/bin/monitor mp in the /proc/self/cmdline if its running and then replaces the null bytes with a SPACE to confirm the exection and finally executed the process.

Finally the protect function validates if the system.pth exists. If it exists, all good and if it does not it created the file and tags the SIGTERM.stop for a graceful stop to ensure the script executed successguly.

The protect() function is executed first and then it executed the check() function.

Final Stage

This stage is all about executing the commands onto the PANOS and saving the results of those commands.

The script checks for the valid CSS file on the PANOS at the below location.

/var/appweb/sslvpndocs/global-protect/portal/css/bootstrap.min.css

Opens up the file for writing the output of the commands execution.

In order to run the commands, the script uses REGEX img tage and verifies if there are entries in the /var/log/pan/sslvpn_ngx_error.log file.

For each of the entires matching the regex which is base64 encoded. The script decodes it and executes it on the shell, reading the output of command execution and writing it as a comment into the CSS file using CSS comments.

   f.write("/*"+output+"*/")

Thus, the results of the commands are appended into the CSS file which is exposed over the internet and is publicly accessible eventually giving away all the information to the threat actors.

Finally, the Last Accessed time and Modified time is updated along with the CSS file to be restored to its original state i.e after every 15 seconds to be more persistent during the time.

Strange Things

The commands which are executed on the OS level are captured from the SSLVPN-NGX-ERROR-LOGS and are completely in base64. So it proves that threat actors are somehow adding the commands using the application in a base64 format into the logs. There can be two ways as i think about this.

1. The app was exploited first and then this python script was dropped.
2. Threat Actors tested the site to make sure the base64 encoded data is being written into the logs and then the script was executed as intended.

The other way, from point 2 to 1.

Threat Attribution

Volexity has attributed the CVE-2024-3400 exploitation to a state-sponsored threat actor it tracks as ‘UTA0218’, which appears to be highly capable “with a clear playbook of what to access to further their objectives”.

https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/

The above article is more thorough into the post exploitation phase of the threat actor exploiting this vulnerability successfuly.

As per Volexity, the post compromise scripts are different for different victims. Thus, one script might not be applicable. However, the nature and motives remain the same throughout.