Palo Alto Networks next-generation firewall (NGFW) is one of the leading enterprise firewalls used by companies around the world to protect against various cyber-attacks. It runs on its own operating system «PAN-OS».
In this article, we will analyze the vulnerabilities that lead to:
- Arbitrary OS command execution by an authorized user — CVE-2020-2037 and CVE-2020-2038
- DoS by an unauthorized user — CVE-2020-2039
- Reflected Cross Site Scripting (XSS) — CVE-2020-2036
Using these vulnerabilities, an attacker can gain access to sensitive data, disrupt the availability of firewall components or gain access to internal network segments.
Authorized RCE #1
The first vulnerability was detected during a black-box analysis of the firewall web management interface and occurs due to the lack of user input filtering. PHP scripts handle user requests and then forward all relevant data to a service listening on a local port. It parses the data and the results are returned to the user of the web application.
To exploit the CVE-2020-2037 vulnerability, we first log in to the web management interface.
The login page of the firewall web management interface
On the Objects tab, go to External Dynamic Lists.
“External Dynamic Lists” section
Now we need to add a new list source and enter our payload in the Source field. It’s important to note that this vulnerability is a blind OS command injection. An external service or an out-of-band payload are required to view the results.
Exploiting the vulnerability
The step-by-step discovery of the blind command injection:
| Payload | Server response |
|---|---|
http://myServer/ | URL access error |
http://myServer/' | cannot open file |
http://myServer/'' | URL access error |
http://myServer/'||' | URL is accessible |
http://myServer/'`sleep 5`' | URL access error (after 5 seconds) |
Product status
| Versions | Affected |
|---|---|
| PAN-OS 10.0 | None |
| PAN-OS 9.1 | < 9.1.3 |
| PAN-OS 9.0 | < 9.0.10 |
| PAN-OS 8.1 | < 8.1.16 |
Authorized RCE #2
Another vulnerability involved insufficient filtering of user inputs.
A detailed examination of the web directory revealed the folder /var/appweb/htdocs/php/rest comprised of PHP files. The file RestApi.php contained a class describing a client’s interactions with PAN-OS via RestApi requests (XML queries). On thorough examination of the script, the execute method of the RestApi class was found.
Сlass RestApi. The primary method which executes a request
Authentication was a prerequisite for the use of this method. Meeting all the prerequisites enabled the user to work with different types of requests. We found the descriptions of these requests in the official Palo Alto Networks documentation at PAN-OS XML API Request Types and Action and Run Operational Mode Commands (API). This information significantly facilitated our analysis.
Our primary interest was the op (operational mode command) request that called the buildOpRequest (private method) handler and allowed the performing of certain diagnostic system calls. The request content was checked for required cmd parameters:
Class RestApi. Builds an op command request
Presumably, this method assembled an XML request that was sent to a third-party server for execution. Analysis of the PAN-OS internals allowed to identify the recipient: the mgmt service. This service was responsible for the subsequent processing of our request.
By looking through the official documentation and running strings on the binaries, we were able to find the library responsible for parsing and analyzing system commands. Now we knew the handler of interest. It was then determined that the values of the command arguments in the xml were extracted as-is and inserted, with the help of a format strings, into commands passed to /bin/sh -c <сmd> for execution.
However, things turned out to be trickier than expected. As we discovered later, at one point the request contents were filtered and checked for correctness. This stopped us from directly executing the commands that we sent, although they were still being extracted without any restrictions.
We ultimately overcame this setback thanks to a certain subtlety in the handling of XML content that finally allowed us to call arbitrary system commands.
Executing “id” command
Product status
| Versions | Affected |
|---|---|
| PAN-OS 10.0 | < 10.0.1 |
| PAN-OS 9.1 | < 9.1.4 |
| PAN-OS 9.0 | < 9.0.10 |
| PAN-OS 8.1 | None |
Unauthenticated DoS
The following vulnerability allows any unauthenticated user to conduct DoS attacks. As a result, the Palo Alto Networks NGFW web mangement panel may become fully unavailable.
The firewall uses the nginx web server. The main nginx configuration file is located at /etc/nginx/nginx.conf.
...
upstream backend_mgmt {
server 127.0.0.1:28250;
}
...
set $gohost "backend_mgmt";
set $devonly 0;
set $gohostExt "";
...
include conf/locations.conf;
include conf/server*.conf;
The main configuration includes additional configuration files. We are particularly interested in the file /etc/nginx/conf/locations.conf.
...
location /upload {
error_page 402 =200 @upload_regular; return 402;
}
...
location @upload_regular {
upload_pass @back_upload_regular;
include conf/upload_default.conf;
}
location @back_upload_regular {
proxy_intercept_errors on;
include conf/proxy_default.conf;
proxy_pass http://$gohost$gohostExt;
}
...
Here we see the handling of the /upload URL.Requests to this URL are redirected internally to the named location upload_regular. The request body is passed to back_upload_regular and the /etc/nginx/conf/upload_default.conf configuration file is included, which we will discuss a bit later. Finally, the request is proxied to http://$gohost$gohostExt (http://127.0.0.1:28250), which turns out to be a local Apache web server. Now let’s look at upload_default.conf more closely.
upload_pass_args on;
# Store files to this directory
# The directory is hashed, subdirectories 0 1 2 3 4 5 6 7 8 9 should exist
upload_store /opt/pancfg/tmp;
# Allow uploaded files to be read only by user
upload_store_access user:rw;
# Set specified fields in request body
upload_set_form_field "FILE_CLIENT_FILENAME_${upload_field_name}" "$upload_file_name";
upload_set_form_field "FILE_CONTENT_TYPE_${upload_field_name}" "$upload_content_type";
upload_set_form_field "FILE_FILENAME_${upload_field_name}" "$upload_tmp_path";
# Inform backend about hash and size of a file
upload_aggregate_form_field "FILE_MD5_${upload_field_name}" "$upload_file_md5";
upload_aggregate_form_field "FILE_SIZE_${upload_field_name}" "$upload_file_size";
upload_pass_form_field "(.*)";
upload_cleanup 400 404 499 500-505;
This file configures nginx-upload-module. The module obtains files from the user and stores them on the system. In our case, the module can be accessed at the URL /upload. Note the upload_cleanup directive, which deletes uploaded files if codes 400, 404, 499, or 500–505 are returned.
By sending a POST request to /upload, we can see that Apache responds with code 301 (visible in the response body) and the nginx proxy responds with 200. These particular codes do not trigger the deletion of an uploaded file.
Uploading of the test file
To verify the vulnerability, we tried to upload a large number of files to the server. Initially, the main disk had 15 GB of free space.
Free space on the disk before the attack
After our attack, it was 100% full.
The disk does not have a free space
We tried to open the web management interface but could not log in. Most likely, this happened because PHP failed to create a session file on disk, due to the lack of disk space available.
As a result, we were able to conduct a DoS attack on Palo Alto NGFW components acting as an unauthenticated user.
Product status
| Versions | Affected |
|---|---|
| PAN-OS 10.0 | < 10.0.1 |
| PAN-OS 9.1 | < 9.1.4 |
| PAN-OS 9.0 | < 9.0.10 |
| PAN-OS 8.1 | < 8.1.16 |
Reflected XSS
The last vulnerability was discovered in the script /unauth/php/change_password.php.
Vulnerable part of code
The script makes use of the $_SERVER['PHP_SELF'] variable, which is user-controlled. This variable is inserted into an attribute value in the form tag without any filtering, thus making the XSS vulnerability easily exploitable.
Successful exploitation of the XSS
Product status
| Versions | Affected |
|---|---|
| PAN-OS 10.0 | None |
| PAN-OS 9.1 | None |
| PAN-OS 9.0 | < 9.0.9 |
| PAN-OS 8.1 |
Author
Mikhail Klyuchnikov : Twitter
ikita Abramov : Twitter