Windows arbitrary file deletion vulnerabilities should no longer be considered mere annoyances or tools for Denial-of-Service (DoS) attacks. Over the past couple of years, these vulnerabilities have matured into potent threats capable of unearthing a portal to full system compromise. This transformation is exemplified in CVE-2023-27470 (an arbitrary file deletion vulnerability in N-Able’s Take Control Agent with a CVSS Base Score of 8.8) demonstrating that what might initially seem innocuous can, in fact, expose unexpected weaknesses within your system.

As a follow up to the Escalating Privileges via Third-Party Windows Installers blog post, this post will delve further into the realm of file-based local privilege escalation attacks. We will unravel and showcase how Time-of-Check to Time-of-Use (TOCTOU) race condition vulnerabilities could enable attackers to delete files on a Windows system and demonstrate how they can subsequently be leveraged to secure an elevated Command Prompt. Furthermore, we will equip software developers with the knowledge to counteract these potential threats. 

CVE-2023-27470

Analyzing Processes with ProcMon

One of the most efficient methods for dynamically analyzing and debugging Windows processes is by using Microsoft’s Process Monitor, often referred to as ProcMon. This tool offers users a wealth of information that can unveil interesting discoveries, including detection artifacts and local privilege escalation vulnerabilities. In the Escalating Privileges via Third-Party Windows Installers blog post, we delved into ProcMon filters for investigating insecure file operations conducted by NT AUTHORITY\SYSTEM processes. CVE-2023-27470 was initially identified through the implementation of these very ProcMon filters, shown in Figure 1. As a reminder, standard users have write privileges to the system's C:\Windows\Temp and C:\ProgramData folders and may sometimes have excessive privileges to their subfolders due to permission inheritance.

Time Of Check to Time Of Use (TOCTOU) Race Condition

When analyzing the Take Control Agent 7.0.41.1141 (BASupSrvcUpdater.exe) process behavior with ProcMon, it was found that every 30 seconds the application made attempts to access a non-existent folder at C:\ProgramData\GetSupportService_N-Central\PushUpdates from an NT AUTHORITY\SYSTEM context. This behavior is illustrated in Figure 2. Since standard users possess write permissions to C:\ProgramData\GetSupportService_N-Central due to permission inheritance, as depicted in Figure 3, we further investigated BASupSrvcUpdater.exe’s behavior in cases where the PushUpdates folder did exist.

The ProcMon output shown in Figure 4 demonstrates that BASupSrvcUpdater.exe queried the contents of the newly created PushUpdates folder. However, as the folder was empty, no additional actions were carried out.

Upon creating an arbitrary file (aaa.txt) in PushUpdates, we observed that BASupSrvcUpdater.exe proceeded to enumerate the folder’s content, initiated the deletion of our created file (utilizing the SetDispositionInformationEx operation), and then logged this deletion event in a log file located at C:\ProgramData\GetSupportService_N-Central\Logs\BASupSrvcUpdater_[DATE].log. There was nothing particularly noteworthy about this behavior, until we added two arbitrary files to the PushUpdates folder.

When we created two files (aaa.txt and bbb.txt), we observed BASupSrvcUpdater.exe log file deletion events between each delete action, as depicted in Figure 6. This process of logging between checks and deletions was susceptible to a Time-of-Check to Time-of-Use (TOCTOU) race condition attack. To put it simply, while BASupSrvcUpdater.exe logged the deletion of aaa.txt, an attacker could swiftly replace the bbb.txt file with a symbolic link, redirecting the process to an arbitrary file on the system. This action would cause the process to unintentionally delete files as NT AUTHORITY\SYSTEM.

Object Manager Symbolic Links and Oplocks

However, unlike in Unix, standard users on Windows are unable to create symbolic links on the filesystem due to the requirement of the SeCreateSymbolicLinkPrivilege privilege. As an alternative, standard users can create symbolic links in a writable object directory within the Object Manager, such as in \RPC CONTROL, and combine it with an NTFS junction to generate a “pseudo-symlink”. Using a pseudo-symlink is advantageous because it can allow an attacker to trick an NT AUTHORITY\SYSTEM process into performing an action on a file or directory other than the one it intended to target.

To exploit the TOCTOU race condition, an attacker would require sufficient time to replace the bbb.txt file with a pseudo-symlink. This is where an opportunistic lock (oplock) can prove valuable. An oplock is a locking mechanism applied to a file that notifies the locking process whenever other processes attempt to access the same file. It also temporarily restricts access by those processes, allowing the locking process to ensure the file is in a suitable state before releasing the lock. If an oplock were established on the log file, BASupSrvcUpdater.exe would be incapable of logging the deletion of aaa.txt until the lock is removed. This would cause the process to halt, providing an attacker ample time to substitute the bbb.txt file with a pseudo-symlink.

To assess the TOCTOU race condition attack, we utilized tools from symboliclink-testing-tools to target the C:\ProgramData\GetSupportService_N-Central\BASupSrvc.xml file that standard users did not have permission to delete, as illustrated in Figure 7. Our first step involved creating the PushUpdates folder and placing two files within it. Then, we applied an oplock to the log file using SetOpLock.exe, as depicted in Figure 8. Once BASupSrvcUpdater.exe deleted aaa.txt, the oplock halted the BASupSrvcUpdater.exe process from logging the event until the oplock was released, which gave us ample time to exploit the race condition.

During the oplock period, the PushUpdates folder was deleted and recreated it as a junction to the \RPC Control object directory using CreateMountPoint.exe. Then, a pseudo-symlink was created with CreateSymlink.exe that pointed bbb.txt to the BASupSrvc.xml file we aimed to delete, as illustrated in Figure 9. Upon releasing the oplock, BASupSrvcUpdater.exe initiated an attempt to delete bbb.txt, inadvertently resulting in the deletion of BASupSrvc.xml instead, as shown in Figure 10. And just like that, we’ve demonstrated that we can exploit CVE-2023-27470 by successfully deleting arbitrary files as NT AUTHORITY\SYSTEM.

From Arbitrary File Deletion to SYSTEM Command Prompt

But why do arbitrary file deletion vulnerabilities matter? Is there anything else an attacker could do with it other than deleting files on a system? Until recently, an arbitrary file deletion vulnerability on Windows was considered a limited threat, mainly leading to DoS attacks. However, security researcher Abdelhamid Naceri recently discovered a race condition attack targeting the Windows Installer's rollback functionality, which, when combined with an arbitrary file deletion vulnerability, such as CVE-2023-27470, could allow an attacker to obtain an elevated Command Prompt.

During an MSI installation, the Windows Installer service creates a folder at C:\Config.Msi containing a rollback script (.rbs) and a corresponding rollback file (.rbf). This setup is purposefully designed for instances where an incomplete installation requires reversion. In these cases, the service uses the information from the .rbs and .rbf files to safely restore the system to its pre-installation state.

To prevent low-privileged users from tampering with these files, the folder and its contents are protected with a strong discretionary access control list (DACL). However, with an arbitrary file deletion exploit as NT AUTHORITY\SYSTEM, an attacker could delete the protected C:\Config.Msi folder immediately after it's created by the Windows Installer; recreate the C:\Config.Msi folder with weak DACL permissions; and drop malicious .rbs and .rbf files into it to be executed by the MSI rollback functionality, potentially resulting in code execution. Proof-of-concept code demonstrating this exploit is available at FilesystemEoPs and is further explained further on in this post.

The Windows Installer race condition attack was carried out using FolderOrFileDeleteToSystem.exe in conjunction with CVE-2023-27470. When attempting to delete the C:\Config.Msi folder with the arbitrary file deletion exploit, shown in Figure 11, FolderOrFileDeleteToSystem.exe recreated the C:\Config.Msi folder and placed the malicious .rbs and .rbf files into it. These files then dropped a custom DLL at C:\Program Files\Common Files\microsoft shared\ink\HID.dll during the rollback procedure, as illustrated in Figure 12.

The HID.dll library file was deliberately placed in the aforementioned location due to the On-Screen Keyboard’s (osk.exe) susceptibility to DLL hijacking. When the On-Screen Keyboard is initiated and Ctrl-Alt-Delete is triggered, the osk.exe process first looks for it at C:\Program Files\Common Files\microsoft shared\ink\HID.dll, rather than its original location at C:\Windows\System32\HID.dll. Performing these actions leads the osk.exe process to run as NT AUTHORITY\SYSTEM, causing it to load the customized HID.dll file and consequently furnishing us with an elevated Command Prompt, as depicted in Figure 13.

Arbitrary file deletion exploits are no longer limited to DOS attacks and can indeed serve as a means to achieve elevated code execution. In this blog post, we've showcased that a seemingly innocuous process of logging and deleting events within an insecure folder can enable an attacker to create pseudo-symlinks, deceiving privileged processes into running actions on unintended files. Furthermore, we've demonstrated how to combine an arbitrary file deletion exploit with MSI's rollback functionality to introduce arbitrary files into the system. But enough of the hacking — let's now delve into defensive considerations that can effectively thwart such attacks from occurring in the first place.

Defensive Considerations

Ensuring protection against arbitrary file deletion vulnerabilities is paramount for upholding the integrity of systems and an organization’s security posture. This section of the blog post contains two recommendations software developers should consider when developing code to reduce risk of exploitation.

CVE-2023-27470 was exploitable due to insecure file operations conducted by an NT AUTHORITY\SYSTEM process. On Windows, standard users have write permissions to the following folders, and these permissions might cascade to subfolders due to inheritance:

• C:\Windows\Temp
• C:\ProgramData
• C:\Users\XXXX\*
• C:\ (ability to create folders)

N-able quickly addressed this vulnerability in version 7.0.43 by creating the previously absent PushUpdates folder and protecting it with strong DACL permissions. This change would thwart attackers from manipulating the folder into creating a junction to \RPC Control, which is an essential component to creating a pseudo-symlink.

Software developers should also consider enabling the ProcessRedirectionTrustPolicy mitigation policy in their Windows processes to have them verify a junction’s trust level. Microsoft introduced this mitigation policy to prevent high-integrity processes, such as those from NT AUTHORITY\SYSTEM, from processing junctions created by non-administrator users. Figure 14 contains C++ sample code illustrating how to enable this mitigation policy.

Attackers attempting to trick an NT AUTHORITY\SYSTEM process into performing an arbitrary file operation via pseudo-symlinks would be blocked and presented with an 0xC00004BE error.

CVE-2023-27470 Disclosure Timeline

• February 27, 2023: Vulnerability reported to N-able
• March 15, 2023: Vulnerability fixed in version 7.0.43