Micropatching Arbitrary File Delete Vulnerability in Windows Backup Service (CVE-2023-21752)

 

January 2023 Windows Updates brought a fix for a local privilege escalation vulnerability in Windows Backup Service, discovered and reported by Filip Dragovic. The vulnerability allows a non-admin user on the machine to execute arbitrary code as Local System and thereby take over the computer.

 

The Backup Service

The intended use of the Backup Service is through local user interface of the legacy "Backup and Restore (Windows 7)" component, still existing on all Windows 10 and Windows 11 computers. A privileged user launches Backup and Restore, selects the backup destination and what they want to backup, and starts or schedules a backup. The destination can either be a local drive or a network path, and in the latter case, network credentials have to be supplied as well. The Backup Service uses these credentials for accessing the network share.

The Vulnerability

The vulnerability lies in the way Windows Backup Service tries to determine whether the user whose credentials were supplied has write access on the chosen destination or not. Specifically, the service attempts to create a temporary, randomly-named file on the destination path using these credentials; if this fails, the path is considered non-writable and the backup procedure can't continue, but if temporary file creation succeeds, the file is immediately deleted and the backup procedure can continue as the path is confirmed to be writable.

Now, the process of creating and deleting this temporary file is vulnerable to a TOCTOU symbolic link attack. As Filip has demonstrated, a local low-privileged attacker can trigger the backup process with some path under their control, catch the temporary file which the Backup Service creates (and hold it locked), replace it with a symbolic link to some system file they could not otherwise delete, and let the Backup Service continue with deleting said system file. This results in the service deleting a chosen file, which can be exploited for arbitrary code execution as Local System as was first shown by Jonas Lykkegård in 2020 using Windows Error Reporting Service, and subsequently also by Abdelhamid Naceri using Windows Installer. Filip's POC makes use of the latter.

But, one could reasonably ask, why does the Backup Service use its own Local System identity instead of user-supplied credentials for creating and deleting the temporary file? Well, it turns out that user-supplied credentials are indeed used for network paths pointing to other computers - but when a share on the same computer is used (such as \\127.0.0.1\C$, the computer's administrative share), the service keeps using its own identity, i.e. Local System.

Microsoft's Patch

Microsoft's patch for this vulnerability introduced a completely redesigned test for path writability, whereby a temporary file is created using the FILE_FLAG_DELETE_ON_CLOSE flag. This flag makes sure that the file, if created, would get automatically deleted when closed - making this entire test an atomic operation from the perspective of TOCTOU shenanigans.

Our Micropatch

Our micropatch is logically identical to Microsoft's, but to minimize its complexity and code size we opted for a simpler naming of the temporary file: we start with creating a file 0patchTMP_A.tmp, then failing that continue with 0patchTMP_B.tmp, and so on until 0patchTMP_Z.tmp. If any of these files can be created, the path is considered writable, otherwise it is considered unwritable.

This is to accommodate multiple backup processes using the same path at the same time, which is unlikely but not impossible. One might think that an attacker could create files 0patchTMP_A.tmp through 0patchTMP_Z.tmp on the backup path to trick our patch into thinking the path was unwritable, but then again, if the attacker has write access to your backup location, no patch is going to save you.

Let's see our micropatch in action. With 0patch disabled, Filip's POC can delete a file on the root of C: drive by exploiting the described vulnerability. With 0patch enabled and our micropatch in place, the vulnerability is no longer there and the same file does not get deleted.

Micropatch Availability

The micropatch was written for the following Versions of Windows with all available Windows Updates installed: 

1. Windows 10 v21H1
2. Windows 10 v2004
3. Windows 10 v1909
4. Windows 10 v1809
5. Windows 10 v1803
6. Windows 7 (no ESU, ESU years 1 and 2)
7. Windows Server 2008 R2 (no ESU, ESU years 1 and 2)

 

Note that Windows 7 and Server 2008 R2 with ESU year 3 have received Microsoft's patch with January Updates.

This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

To learn more about 0patch, please visit our Help Center. 

We'd like to thank  Filip Dragovic for sharing details about this vulnerability, which allowed us to create a micropatch and protect our users. We also encourage security researchers to privately share their analyses with us for micropatching.