Marc Barrantes posted interesting articles about Windows Local Privilege Escalation. Initially I felt a little overwhelm. So I have decided to dig a deeper.

Read the advisory here

BLUF: A low-privilege user can escalate their privileges using a repair functionality of Palo Alto's Global Protect Windows App.

The exact steps by the author are as below.

To trigger this vulnerability, an attacker is required to initiate the repair functionality of the MSI installer (available in C:\Windows\Installers), then, by placing an OpLock on a DLL loaded by the PanGPS.exe service binary, you could halt execution when the console host (conhost.exe) window was visible. Since this conhost.exe was running as SYSTEM in Session 1 and was visible to the user, it's possible to open a web browser by clicking the hyperlink in the properties tab of the window, and from there open any application as SYSTEM.

1. Let's understand the lingo

1.1. What is an MSI installer?

An MSI installer is a type of installer specific to Windows systems. Generally, .exe files can serve the same purpose, but MSI installers handle the task a bit differently. The MSI package includes .exe, .dll, and other files, and it allows only one instance of the installation to run at a time. In contrast, .exe files can be customized and may contain .exe, .msi, or .dll files, but MSI files cannot include another MSI.

For more details, see this reference.

These installer files are stored in C:\Windows\Installer. Since these are cache files, you might wonder if they can be deleted to free up space. The short answer is no.

According to a response on Microsoft Answers:

The installer cache is used to maintain (remove/update) applications and patches installed on the machine. The installer files keep track of file versions and registry dependencies involved in a particular installation, which ensures that applications can be properly uninstalled or updated.

1.2 OpLock?

According to Microsoft, an Opportunistic Lock (OpLock) is a mechanism that allows a client to place a lock on a file residing on a server.

Honestly, this description didn't help me much. To simplify, Luca Barile explains:

In short, an Opportunistic Lock (OpLock) is a mechanism that allows to temporarily block access to a certain file. In general, access to a file, can be done in order to execute, read, write or delete it (or a combination of these operations); with an opportunistic lock we can block one or more of these types of access.

There are two types of OpLocks: Exclusive and Shared OpLocks. Here's a helpful analogy from this StackOverflow post:

When a teacher is writing (exclusive lock) on the board:

1. Nobody can read it because it's still being written and she's blocking the view => If an object is exclusively locked, shared locks cannot be obtained.
    
2. Other teachers can't start writing on the same board, as it would confuse students => If an object is exclusively locked, other exclusive locks cannot be obtained.

When students are reading (shared locks) what is on the board:

1. They can all read the board together => Multiple shared locks can co-exist.
    
2. The teacher must wait for them to finish before erasing the board => If shared locks exist, exclusive locks cannot be obtained.

2. What is happening?

When a user initiates the repair functionality of the GlobalProtect app, PanGPS.exe is executed as part of the repair process. During this process, a DLL with higher privileges is loaded. This vulnerability allows an attacker to exploit the elevated privilege of the DLL to execute a privilege escalation attack. Normally, the PanGPS.exe process terminates after use, but by using OpLock, an attacker can intercept the command-line interface (CLI).

2.1. Useful tools for finding and analyzing vulnerable DLLs:

• Dependency Walker
• ProcMon
• Open-Handle Tools
• ProcDump
• Process Explorer
• Ghidra

Sure! Here's the updated section with 2.2 added:

2.2. How a researcher could find this vulnerability (Assumptions):

Finding such a vulnerability typically involves a combination of understanding application behavior, reverse-engineering, and dynamic analysis. Here are some steps the researcher might have taken:

1. Initial Application Behavior Analysis:

   • The researcher likely began by observing the behavior of the GlobalProtect app using tools like ProcMon and Process Explorer. These tools would show how the app operates during normal execution, especially during MSI repair operations. Noticing that certain processes like PanGPS.exe were launched with elevated privileges could have triggered suspicion.

2. Investigating MSI Installer and Repair Functionality:

   • The researcher might have focused on how the MSI installer works, especially the repair functionality. They could have analyzed how MSI repair processes load DLLs by using tools like Dependency Walker to identify which DLLs are loaded during this process and what privilege level each operates at.

3. OpLock and Race Condition Exploration:

   • To further investigate, the researcher may have tried manipulating the loading sequence by applying an Opportunistic Lock (OpLock) on one of the loaded DLLs. This is a common technique to exploit Time-of-Check to Time-of-Use (TOCTOU) race conditions, where the state of a file or resource changes between when it's checked and when it's used.

4. Conhost.exe Running as SYSTEM:

   • By observing processes like conhost.exe, the researcher likely discovered that this process, running as SYSTEM in Session 1, is exposed to the user interface. From here, they could have theorized about using this process to elevate privileges through user interactions, such as clicking hyperlinks in the console window properties, leading to full SYSTEM access.

5. Experimenting with Privilege Escalation Techniques:

   • Once they had control of conhost.exe, the researcher could test opening other applications with SYSTEM privileges. They might have used tools like ProcDump or Ghidra to dump memory and analyze how the process was operating in the SYSTEM context, confirming their suspicion that it could lead to full privilege escalation.

6. Static and Dynamic Code Analysis:

   • The researcher might have used reverse-engineering tools like Ghidra or IDA Pro to statically analyze the GlobalProtect binaries and find potential weaknesses in how the MSI installer and repair functionality are handled. They would look for improper privilege checks or insecure DLL loading mechanisms that could be exploited.

#DependencyWalker #oplock #windowsPE