TL;DR

This vulnerability allows low privileged users to hijack file that are owned by NT AUTHORITY\SYSTEM by overwriting permissions on the targeted file. Successful exploitation results in "Full Control" permissions for the low privileged user.

Intro

First of all I would like to thank fellow researchers for giving me inspiration to dive into this type research.

• James Forshaw (@tiraniddo) from Google Project Zero
• Ryan Hanson (@ryHanson) from Atredis Partners

Some of their research that inspired me can be found here:

• https://www.atredis.com/blog/cve-2018-0952-privilege-escalation-vulnerability-in-windows-standard-collector-service
• https://www.atredis.com/blog/cylance-privilege-escalation-vulnerability
• https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html
• https://googleprojectzero.blogspot.com/2015/08/windows-10hh-symbolic-link-mitigations.html

Now let's talk about this particular vulnerability. All Windows Apps have a settings.dat file which keeps track of the (registry) settings of the App. That file is a registry file which can be loaded into registry and modified there.
However once you launch a Windows App such as Microsoft Edge the settings.dat file it is used by NT AUTHORITY\SYSTEM and as a low privileged user you have full access to that file.
Now the question arises how can we abuse the privileged file access.

Vulnerability

Let's focus on the settings.dat file of Microsoft Edge.
All Windows Apps user configuration files are stored under the current users' AppData folder.

`C:\Users\\AppData\Local\Packages\`  Windows 10 already has a number of default Apps installed as shown above. Each package has a `settings.dat` file, as mentioned before this file is used by NT AUTHORITY\SYSTEM to writes any configuration changes. Once the Windows App is started the system uses an `OpLock` operation (Exclusive Lock) to prevent other processes to use/access that file while the App is running. In our case when we start Microsoft Edge the `settings.dat` file is opened as NT AUTHORITY\SYSTEM, which can be seen in the screenshot below.  Once opened, some basic integrity checks are performed in the following manner:

1. Check file permissions
1. If file permissions are incorrect, then correct the file permissions with the correct
2. Read the file content
1. If content is corrupted, then delete the file
2. Reset the configuration by copying the settings template file from "C:\Windows\System32\settings.dat"
3. Get "Exclusive Lock" on the newly copied file
4. Proceed to start the Windows App

This procedure can be seen in the following screenshot when performing our attack


As mentioned before it first sets the correct file permissions during the SetSecurityFile operation after which it continues on reading the contents of the file, in our case the contents do not correspond to a correct settings.dat file. After which it deletes the file, copies the settings template file and proceeds with starting up the Windows App.
Now most of these operations are performed by impersonating the current user access which prevent abuse of these operations as they won't be any different as performing these operations as the current user.

We can use this behaviour to set the file permissions on "any" file (there are some pre-requisites, I'll come back to that later) by using hardlinks.
Huge thanks to James Forshaw and Google P0 again for providing us with the SymbolicLink Testing Toolkit. Using his toolkit we can create hardlinks to files where we want to have "Full Control" over as a regular user.

Exploit

We know that file permissions set on a hardlink will result changes on the original file.
Below we will hijack the HOSTS file located at C:\Windows\System32\drivers\etc\hosts. As a regular user you don't have modify access to that file as seen below.

I've written an exploit that automates the entire process of creating a hardlink and triggering the vulnerability. The result of a successful exploitation can be seen below.

1. The exploit first checks if the targeted file exists, if it does it will check its permissions. Since we are using Microsoft Edge for this exploit it will kill Microsoft Edge in order to get access to the settings.dat file.
2. After Microsoft Edge is killed it will check for the "setting.dat" file and delete it in order to create a hardlink to the requested targeted file (in our case that was the HOSTS file)
3. Once a hardlink is created Microsoft Edge is fired up again to trigger the vulnerability. Concluding with a final check if indeed "Full Control" permissions have been set for the current user.

As I mentioned previously above there are some pre-requisites you have to take into account before abusing this vulnerability. These are the following:

• NT AUTHORITY\SYSTEM should have "Full Control" over the targeted file
• The low privileged user or the Users group should have "Read/Execute" rights
• The "Read/Execute" rights should be inherited, explicit "Read/Execute" are not sufficient

PoC

PoC code can be found here.

Video PoC

This PoC video demonstrates the complete use of this vulnerability by using a DLL and injecting our own malicious code into it to gain Privilege Escalation using the Chrome Update Service.