A patched Windows attack surface is still exploitable
On August 8, 2023, Microsoft finally released a kernel patch for a class of vulnerabilities affecting Microsoft Windows since 2015. The vulnerabilities lead to elevation of privilege (EoP), which allows an account with user rights to gain SYSTEM privileges on a vulnerable host. The root cause of this attack surface, according to a 2015 blog, is the ability of a normal user account to replace the original C: drive with a fake one by placing a symlink for the system drives in the device map for each login session. This fake drive will be followed by the kernel during impersonation instead of the original system drive. More than five months after the patches for these vulnerabilities were released, we’re still seeing some of their exploits in the wild because it’s a very easy way to get a quick NT AUTHORITYSYSTEM and that’s why it may be favored by well-known threat actors.
We discussed these findings at the BlackHat MEA conference in November 2023, and in December 2023 and January 2024, we found two exploits that could still use this attack surface in the unpatched version of Windows. Both exploits are packed in UPX. After analyzing the first one, we saw that it was a packed version of a Google Project Zero PoC sample. The other sample was a packed version of an SSD Secure Disclosure public PoC, even using the same NamedPipe “\\.\Pipe\TyphoonPWN” without modifications. The PDB paths for both samples are:
C:UsersAdministratorsourcereposexpx64Releaseexp.pdb
C:VVS-RroCVEsspoolBitsPocsrcx64ReleasePoC_BITs.pdb
Below we will highlight the key points and then focus on how to check if any of the vulnerabilities have been exploited or if there have been any attempts to exploit them, and enumerate popular CVEs included in this vulnerable surface.
Affected processes and services include native Windows services that run by default on most versions of the operating system. These include:
CSRSS
Windows Error Reporting (WER)
File history service
Background intelligence transfer service (BITS)
Print Spooler
The exploits affecting this attack surface share a common logic or pattern, including:
Searching for a DLL that runs with system integrity.
The DLL has an isolation-aware manifest file.
The ability to change the C: root to a writable directory via symlinks.
CSRSS | CVE-2022-22047
This Activation Context Cache Poisoning vulnerability leads to local privilege escalation. It’s one of the CVEs that was actively exploited by a threat actor called KNOTWEED | Denim Tsunami.
Reversing the in-the-wild exploit for the CVE-2022-22047 shows:
The exploit crafts a call into CSRSS.
The call requests an activation context for a privileged executable and specifies a malicious manifest.
The manifest uses an undocumented manifest XML attribute named loadFrom. This attribute allows unrestricted redirection of DLLs to any location on a disk, including locations outside of the normal search path, without even having to change the C: root drive.
Here is a detailed blog post by ZDI explaining CSRSS Cache Poisoning.
CSRSS | CVE-2022-37989
The second vulnerability, involving CSRSS Cache Poisoning, was a workaround for the first CVE-2022-22047. After patching the undocumented “LoadFrom” attribute, there was another attribute that could be abused to load a manifest file from a user-controlled path by declaring a dependent assembly using path traversal in the name attribute.
The patch for the CVE-2022-37989 was simple: check if the name attribute of the dependency contains any forward or backward slashes, and set a flag to stop caching this suspicious manifest if name path traversal is detected. This CVE was discovered by ZDI.
Print Spooler | CVE-2022-29104
Print Spooler is a service that runs by default in almost all versions of Windows. It’s responsible for managing paper print jobs sent from a computer to a printer or print server. Reversing in-the-wild exploits of the CVE-2022-29104 Print Spooler vulnerability shows that it’s a .NET sample that creates a symbolic link from C: to the fake root C:Imprint. The sample was uploaded to VirusTotal.
Fake C: drive structure:
C:ImprintWindowssystem32
C:ImprintWindowsWinSxS
All folders inside the Imprint folder are writable, allowing an attacker to control their contents.
Path traversal is added to “AssemblyIdentity” to point to the Imprint writable path.
The vulnerability analysis shows that:
An attacker can remap the root drive (C:) for privileged processes during impersonation.
During impersonation, all file accesses are performed using the DOS device map of the impersonated process.
CSRSS uses a user-modified side-by-side manifest for generating the activation context instead of the manifest in the WinSxS folder C:WindowsWinSxS.
The WinSxS folder stores multiple copies of system files and components.
The WinSxS folder provides a central location for storing different versions of system files that are shared by multiple applications and processes.
The WinSxS folder provides system stability and compatibility by allowing different applications to use the specific versions of files they need.
WinSxS avoids DLL hell, a problem that occurs when different applications require different versions of the same DLL.
The Windows operating system uses the application manifest to determine which version is appropriate for which app.
The application manifest is stored in XML format and describes:
The dependencies associated with the application.
What permissions the application requires.
What compatibility settings the application supports.
CSRSS mitigation was enabled for spoolsv.exe and printfilterpipelinesvc.exe to stop impersonation while loading external resources, and then to resume impersonation after the external resources are loaded.
Print Spooler | CVE-2022-41073
After CVE-2022-29104 was patched, another vulnerability affecting Print Spooler was discovered – CVE-2022-41073. Reversing the in-the-wild exploit of this vulnerability shows some XML manipulation using path traversal to a writable path containing a modified version of prntvpt.dll that is loaded by Print Spooler.
According to Project Zero, mitigation was added to CSRSS, the patch simply stopped any impersonation prior to the LoadLibraryExW call in winspool!LoadNewCopy, and then resumed it.
After that the LoadLibraryExW call returned:
+ if (RevertToProcess(&TokenHandle, x) >= 0) {
lib = LoadLibraryExW(arg1, 0, dwFlags);
+ ResumeImpersonation(TokenHandle);
+ }
NtOpenFile is called with the OBJ_IGNORE_IMPERSONATED_DEVICEMAP flag. It will stop impersonation when loading any external resources while using the LoadNewCopy API. Stopping impersonation means that privileged processes will not use the fake root implemented with the medium integrity process, and instead it will use the original C: drive root to avoid loading untrusted or malicious resources.
Windows Error Reporting | CVE-2023-36874
Windows Error Reporting (WER) is a privileged service that analyzes and reports various software issues in Windows. The root cause for the exploitation of the CVE-2023-36874 vulnerability is CreateProcess API when a crash happens, because CreateProcess API can be tricked into following the fake root and creating the process from this writable fake root in the context of the privileged WER service, leading to privilege escalation.
CVE-2023-36874 was exploited in the wild and has several published PoCs. The exploit interacts with the IWerReport COM interface and calls SubmitReport, then UtilLaunchWerManager is called, which calls CreateProcess. CreateProcess API is then vulnerable to DoS device modification.
Once the exploit to submit a fake crash report is executed, it will end up calling the vulnerable CreateProcess API.
File History Service | CVE-2023-35359
File History Service can be used to automatically back up personal folders and files such as documents, pictures and videos. Reversing the in-the-wild exploit shows that when File History Service starts, it impersonates the current user and then loads a DLL called fhcfg.dll under impersonation. This DLL has an “application aware manifest config” that attempts to load another resource called msasn1.dll. The exploit starts with the usual technique of changing the C: root to a fake writable root.
Windows Error Reporting – 2nd exploit | CVE-2023-35359
After patching the first Windows Error Reporting vulnerability, which used the CreateProcess API inside the privileged WER service and follows the fake root to create a process. The patched WER service started using CreateProcessAsUser instead of CreateProcess API. However, after that patch, adversaries found another way that could lead to the use of CreateProcess again under certain conditions, which was considered a new vulnerability. For example, if the WER service was marked as disabled on a system and there was a privileged process impersonating a medium-integrity user on that system, and an unhandled exception occurs during impersonation that results in a crash, that crash tries to enable the WER service for reporting. The detailed analysis for this CVE shows that it does not appear to be exploitable.
BITS | CVE-2023-35359
The Background Intelligence Transfer Service (BITS) is responsible for facilitating the asynchronous and prioritized transfer of files between a client and a server. BITS operates in the background, which means it can perform file transfers without interrupting a user or consuming all of the available network.
You may notice that the number CVE-2023-35359 has not changed for the last three CVEs because Microsoft decided in the last patch to assign the same CVE to all vulnerabilities of this type. So there are different vulnerabilities in different processes/services but with the same CVE number.
How was the patch for this attack surface applied?
The patch was applied to ObpLookupObjectName to check if the loaded resource is a file object and the call to ObpUseSystemDeviceMap succeeds. It then ignores the impersonation and uses SystemDevice.
ObpLookupObjectName checks FileObjectType followed by a call to ObpUseSystemDeviceMap.
The ObpUseSystemDeviceMap function checks for the SystemDevice to be used instead of the impersonated device.
How to check if a vulnerability was exploited or any attempts were made to exploit it?
When analyzing most of the exploits targeting this attack surface, we observed a common behavior that could be used as an indicator of whether there were any attempted exploits:
Most of the in-the-wild exploits create a writable folder inside the C: drive, and the structure of this folder mimics the structure of the original C: drive, for example:
C:WindowsSystem32 → C:FakeFolderWindowsSystem32
C:WindowsWinSxS → C:FakeFolderWindowsWinSxS
So finding a writable folder that mimics the C: drive folder structure may be an indicator of an exploitation attempt.
Copying the manifest files from the original WinSxS folder in C:WindowsWinSxS to a writable directory and modifying them could be a good indicator of an exploitation attempt.
Manifest files that contain undocumented XML attributes such as “LoadFrom” or manifest files that contain path traversal in the “name” attribute could be a valid sign of an exploitation attempt.
Creating a symbolic link from the original system drive to a writable directory, especially from processes with medium integrity using the RPC Control object directory.
About The Author
