Versions Tested:

• GlobalProtect App < 5.1.4 on Windows
• GlobalProtect App < 5.0.10 on Windows

Product:
https://www.paloaltonetworks.com/products/globalprotect

Security Advisories:
https://security.paloaltonetworks.com/CVE-2020-2032

CVE Numbers:
CVE-2020-2032

CVSS Score:
7.0

CWE:
CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition

NIST:
N/A

OWASP:
N/A

Summary:

A race condition vulnerability in the Palo Alto Networks GlobalProtect app on Windows allowed a local limited Windows user to execute programs with SYSTEM privileges. This issue can be exploited only while performing a GlobalProtect app upgrade.

Details:

­The Global Protect App Windows MSI installer executes as SYSTEM and uses a predictable path to create and execute a batch file from a location writable by all users. Prior to the update, a low privileged user could create a file named C:WindowsTemppostupdt.bat which is called by PanVcrediChecker.exe during the install/update.  The application overwrites the contents of the batch file. However, the ownership by the low privileged user was retained. A TOCTOU race condition exists, allowing a low privileged user to overwrite the file prior to the execution.

All users have permission to create new files in C:WindowsTemp and some applications store transient files here. The folder is like how /tmp is used on Linux systems, but the permissions are different. On Linux, file listing is allowed by low privileged users while, on Windows, a low privileged user cannot list the files.

Using a command shell, the low privilege user attempts to list the files under C:windowstemp and “File Not Found” is returned. This message is deceiving because files exist, but the user does not have the proper permission to list them.

Though a low privileged user cannot view the listing of files, it does have permission to create a new file. Using an administrator command shell and executing cacls to view the access control list shows that BUILTINusers have a few specific permissions. FILE_WRITE_DATA allows all users to create new files.

Windows has many file permissions and the names can be misleading. Fortunately, the permissions are documented on Microsoft.com. Included below are descriptions of the relevant permission descriptions for BUILTINUsers. Visit Standard Access Rights, and File Access Rights Constants for additional details.

Constant/ValueDescriptionSYNCHRONIZEThe right to use the object for synchronization. This enables a thread to wait until the object is in the signaled state. Some object types do not support this access right.FILE_WRITE_DATAFor a file object, the right to write data to the file. For a directory object, the right to create a file in the directory (FILE_ADD_FILE).FILE_APPEND_DATAFor a file object, the right to append data to the file. For a directory object, the right to create a subdirectory (FILE_ADD_SUBDIRECTORY).FILE_EXECUTEFor a native code file, the right to execute the file. This access right given to scripts may cause the script to be executable, depending on the script interpreter.

With a basic understanding of how C:WindowsTemp is used, we can look for potential vulnerabilities. Some installers still use C:WindowsTemp for temporary files. My favorite utility for discovering file-based vulnerabilities is Sysinternals Process Monitor. Start the process monitor as an administrator and set the filter to the following. As an example, this filter will limit output to system users accessing files under C:WindowsTemp.

During the install/update, PanVcrediChecker.exe creates C:WindowsTemppostupdt.bat and then executes it. Note that some operations were excluded for brevity purposes.

An alternate view of the same data uses a process tree. This view can be accessed by using the Tools | Process Tree menu.

Drilling down on the event shows the following properties.

Armed with the knowledge learned through dynamic testing, a proof of concept can be developed. The goal is to create the postupdt.bat file, initiate the upgrade, and then continuously overwrite the file and attempt to win the race.

Steps to Reproduce:

Assumptions:

• All steps are executed as a low privileged user
• GlobalProtect client is a lower version than the VPN server
• The C:WindowsTemppostupdt.bat file does not exist which is should not if an update has not been run recently.

1.  Create C:WindowsTemppostupdt.bat with the following contents. The first line should be the arbitrary command to execute. The PanGPS.exe -benice is the command normally executed and is included to ensure the installation process does not fail.

whoami &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt; c:windowssystem32woot.txt&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/pre&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
“C:Program FilesPalo Alto NetworksGlobalProtectPanGPS.exe” -benice

2.  Create loop.cmd with the following contents and execute it. This will overwrite the target file using an infinite loop.

:loop&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/pre&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
@echo f | xcopy postupdt.bat c:WindowsTemppostupdt.bat /y /f

goto loop

3.  Connect to the Global Protect server with a higher-level version. This should automatically prompt to update the client. Click the “Yes” button. If there is no prompt, right-click the system tray application and click About.

4.  Click the “Check for Updates” button on the About window.

5.  Click the “Yes” button when the update message is displayed.

6.  After the update process has completed, c:windowssystem32woot.txt will exist with the contents set to “nt authoritysystem“.

A quick dive into static analysis. I originally found the vulnerability using Process Monitor, but I wanted to understand what was happening behind the scenes using IDA.

Build the path using GetTempPathA() which returns c:Windowstemp. Concatenate postupdt.bat and store it in the File variable.

Append PanGPS.exe -benice to the GlobalProtect App installation path.

Write the batch script contents, close the file, and execute it via ShellExecuteA() passing c:windowstemppostupdt.bat for the lpFile parameter.

Timeline:
04/22/2020  – Vulnerability reported
05/22/2020  – Vendor confirmed the vulnerability
06/10/2020  – Vendor advisory published

Credit:
Discovered by Rich Mirch, Senior Adversarial Engineer at TEAMARES