Palo Alto Networks PAN-OS命令执行漏洞（CVE-2020-2038）

# Swarm of Palo Alto PAN-OS vulnerabilities Written by [Mikhail Klyuchnikov](https://swarm.ptsecurity.com/author/mikhail- klyuchnikov/ "Posts by Mikhail Klyuchnikov") and [Nikita Abramov](https://swarm.ptsecurity.com/author/nikita-abramov/ "Posts by Nikita Abramov") on February 11, 2021  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](https://security.paloaltonetworks.com/CVE-2020-2037) and [CVE-2020-2038](https://security.paloaltonetworks.com/CVE-2020-2038) * DoS by an unauthorized user -- [CVE-2020-2039](https://security.paloaltonetworks.com/CVE-2020-2039) * Reflected Cross Site Scripting (XSS) -- [CVE-2020-2036](https://security.paloaltonetworks.com/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](https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-panorama-api/pan- os-xml-api-request-types/pan-os-xml-api-request-types-and-actions.html) and [Run Operational Mode Commands (API)](https://docs.paloaltonetworks.com/pan- os/9-0/pan-os-panorama-api/pan-os-xml-api-request-types/run-operational-mode- commands-api.html). 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 | < 8.1.16 | [Web Application Security](https://swarm.ptsecurity.com/tag/web-application- security/) Previous [Vulnerabilities in McAfee ePolicy Orchestrator](https://swarm.ptsecurity.com/vulnerabilities-in-mcafee-epolicy- orchestrator/) [Twitter](https://twitter.com/ptswarm) [GitHub ](https://github.com/ptswarm) Copyright (C) 2020 - 2021 PT SWARM Positive Technologies Offensive Team