This vulnerability was originally found by @klinix5, who later found another way to exploit the issue which they reported publicly at https://github.com/klinix5/Windows-Setup-EoP as a 0day. The original bug occurred due to the fact that on Windows 10 systems prior to the August 2020 updates, there was a flaw within the way Windows Setup operated which resulted in a LPE vulnerability.

More specifically, within windowsupdatebox.exe, there was a call to CreateDirectoryW() with a NULL security descriptor, which would create the folder C:\$WINDOWS.~BT with the same permissions as those from the C:\ directory, which by default allow everyone read, write, and delete access to the directory. After this, a CreateFileW() call would be made with the name C:\$WINDOWS.~BT to get a handle to the folder for later use, before Windows Setup would then execute a SetSecurityInfo() call on the C:\$WINDOWS.~BT directory to set its permissions appropriately.

The issue with this code is that attackers could create a directory junction on the C:\$WINDOWS.~BT directory once it had been created with open permissions, and cause the CreateFileW() call to create an file at an arbitrary location on the disk as the SYSTEM user. Then once this had been done, they could remove the directory junction to ensure that the SetSecurityInfo() call didn’t alter the permissions of the file that was created with CreateFileW().

Microsoft then fixed this vulnerability in their August 2020 update by patching the code so that they passed the security descriptor in as part of the CreateDirectoryW() call, and they removed the calls to CreateFileW() and SetSecurityInfo(). This means that even if an attacker can redirect the creation of the directory via a directory junction (an attack that is still possible with the new code), they won’t have access to the resulting directory that is created due to the security permissions that will be applied on the directory at the time of its creation. This also prevents the original timing issue by ensuring that there is no period in which the directory will be created with open permissions that could allow low privileged users to tamper with it.

Unfortunately, @klinix5, the original discoverer of this bug, found that Microsoft had another issue; specifically that once the Windows Setup was done, it would attempt to delete C:\$WINDOWS.~BT without properly checking that C:\$WINDOWS.~BT wasn’t a reparse point. Attackers can create the C:\$WINDOWS.~BT directory themselves and then create two subdirectories and place oplocks on them. These oplocks will only trigger once the C:\$WINDOWS.~BT directory is in the process of being deleted.

When these oplocks trigger, the attacker can then turn the respective directories into directory junctions, thereby allowing them to delete arbitrary directories as the SYSTEM user. The attacker can then use techniques such as the one described in https://secret.club/2020/04/23/directory-deletion-shell.html to transform the arbitrary file deletion into code execution as the SYSTEM user.

Note that this second technique does not have a patch, and is still a 0day as of September 1st 2020. Its likely however that Microsoft will patch this at a later date, however the exact date is as of yet unknown. For this reason the value of this vulnerability has been increased to 4 to reflect the unpatched nature of this bug. Do keep in mind however that an attacker will need to have authenticated GUI access for this bug to work, and that whilst Microsoft states that the bug works on Windows 10 v2004, it doesn’t seem like it would be possible to trigger it on this version at this point in time, as there is no “next version” to upgrade to. Once the next version of Windows does come out though, those Windows 10 v2004 systems which have not yet applied this patch will be exploitable.