LocalPotato_CVE-2023-21746

A local privilege escalation (LPE) vulnerability in Windows was reported to Microsoft on September 9, 2022, by Andrea Pierini (@decoder_it) and Antonio Cocomazzi (@splinter_code). The vulnerability would allow an attacker with a low-privilege account on a host to read/write arbitrary files with SYSTEM privileges.

While the vulnerability in itself wouldn't directly allow executing commands as SYSTEM, we can combine it with several vectors to achieve this result. Conveniently, on February 13, another privilege escalation PoC was published by BlackArrowSec that abuses the StorSvc service, allowing an attacker to execute code as SYSTEM as long as they can write a DLL file to any directory in the PATH.

The LocalPotato PoC takes advantage of a flaw in a special case of NTLM authentication called NTLM local authentication to trick a privileged process into authenticating a session the attacker starts against the local SMB Server. As a result, the attacker ends up having a connection that grants him access to any shares with the privileges of the tricked process, including special shares like C$ or ADMIN$.

The process followed by the exploit is as follows:

• The attacker will trigger a privileged process to connect to a rogue server under his control. This works similarly to previous Potato exploits, where an unprivileged user can force the Operating System into creating connections that use a privileged user (usually SYSTEM).
• The rogue server will instantiate a Security Context A for the privileged connection but won't send it back immediately. Instead, the attacker will launch a rogue client that simultaneously initiates a connection against the local SMB Server (Windows File Sharing) with its current unprivileged credentials. The client will send the Type1 message to initiate the connection, and the server will reply by sending a Type2 message with the ID for a new Security Context B.
• The attacker will swap the Context IDs from both connections so that the privileged process receives the context of the SMB server connection instead of its own. As a result, the Privileged client will associate its user (SYSTEM) with Security Context B of the SMB connection created by the attacker. As a result, the attacker's client can now access any network share with SYSTEM privileges!

By having a privileged connection to SMB shares, the attacker can read or write files to the target machine in any location. While this won't allow us to run commands directly against the vulnerable machine, we will combine this with a different attack vector to achieve that end.

Note that the vulnerability is in the NTLM protocol rather than the SMB Server, so this same attack vector could be theoretically used against any service that leverages authentication through NTLM. In practice, however, some caveats must be dealt with when selecting the protocol to attack. The PoC uses the SMB Server to avoid some extra protections in place for other protocols against similar attack vectors and even implements a quick bypass to get the exploit to work against the SMB Server. Original exploit author's post - (https://decoder.cloud/2023/02/13/localpotato-when-swapping-the-context-leads-you-to-system/)

So far, we have used LocalPotato to write arbitrary files to the target machine. To get a privileged shell, we still need to figure out how to use the arbitrary write to run a command.

Recently, another privilege escalation vector was found, where an attacker could hijack a missing DLL to run arbitrary commands with SYSTEM privileges. The only problem with this vector was that an attacker would need to write a DLL into the system's PATH to trigger it. By default, Windows PATH will only include directories that only privileged accounts can write. While it might be possible to find machines where the installation of specific applications has altered the PATH variable and made the machine vulnerable, the attack vector only applies to particular scenarios. Combining this attack with LocalPotato allows us to overcome this restriction and have a fully working privilege escalation exploit.

StorSvc and DLL Hijacking As discovered by BlackArrowSec (https://github.com/blackarrowsec/redteam-research/tree/26e6fc0c0d30d364758fa11c2922064a9a7fd309/LPE via StorSvc), an attacker can send an RPC call to the "SvcRebootToFlashingMode" method provided by the "StorSvc" service, which in turn will end up triggering an attempt to load a missing DLL called "SprintCSP.dll". If you are not familiar with RPC, think of it as an API that exposes functions so that they can be used remotely. In this case, the StorSvc service exposes the SvcRebootToFlashingMode method, which anyone with access to the machine can call. Since StorSvc runs with SYSTEM privileges, creating SprintCSP.dll somewhere in the PATH will get it loaded whenever a call to SvcRebootToFlashingMode is made.

Compiling the Exploit Exploit link - (https://github.com/decoder-it/LocalPotato) To make use of this exploit, you will first need to compile both of the provided files:

• SprintCSP.dll: This is the missing DLL we are going to hijack. We will need to change the command to run a reverse shell.
• RpcClient.exe: This program will trigger the RPC call to SvcRebootToFlashingMode. Depending on the Windows version you are targeting, you may need to edit the exploit's code a bit, as different Windows versions use different interface identifiers to expose SvcRebootToFlashingMode. The projects for both files can be found in the directory "LPE via StorSvc".

Let's start by dealing with "RpcClient.exe". As previously mentioned, we will need to change the exploit depending on the Windows version of the target machine. To do this, we will need to change the first lines of "LPE via StorSvc\RpcClient\RpcClient\storsvc_c.c" so that the correct operating system is chosen. This will set the exploit to use the correct RPC interface identifier. Now that the code has been corrected, let's open a developer's command prompt and build the project by running the following command: Commands: C:\LPE via StorSvc\RpcClient> msbuild RpcClient.sln C:\LPE via StorSvc\RpcClient> move x64\Debug\RpcClient.exe C:\Users\user\Desktop\ (The compiled executable will be found on your desktop.)

Now to compile "SprintCSP.dll", we only need to modify the "DoStuff()" function in "C:\LPE via StorSvc\SprintCSP\SprintCSP\main.c" so that it executes a command that grants us privileged access to the machine. For simplicity, we will make the DLL add our current user to the Administrators group. We can also get a reverse shell from that target to our machine. We now compile the DLL by running the following command and move the result back to our desktop: Commands: C:\LPE via StorSvc\SprintCSP> msbuild SprintCSP.sln C:\LPE via StorSvc\SprintCSP> move x64\Debug\SprintCSP.dll C:\Users\user\Desktop\

We are now ready to launch the exploit. Make sure you have the "LocalPotato.exe" exploit, the "RpcClient.exe" and the "SprintCSP.dll" files.