TL;DR

Find out how a vulnerability in Windows Installer allows local users to gain elevated SYSTEM privileges in Windows.

Vulnerability Summary

Windows Installer is a software component and application programming interface of Microsoft Windows used for the installation, maintenance, and removal of software.

A patch recently released by Microsoft for Windows Installer is addressing a local privilege escalation allowing a local user to gain SYSTEM on victim’s machine.

Credit

An independent, Abdelhamid Naceri (halov), Security Researcher has reported this vulnerability to SSD Secure Disclosure program.

CVE

CVE-2020-16902

Affected Versions

Windows 7

Windows 8

Windows 10

Windows 2008

Windows 2012

Windows 2016

Windows 2019

Vendor Response

Microsoft has released patches to address this issue, for more details see: CVE-2020-16902 | Windows Installer Elevation of Privilege Vulnerability

Vulnerability Analysis

The vulnerability was first found by sandbox escaper, she posted the write up here.

As you can read the vulnerability got addressed in CVE-2019-1415, however a bypass to the security patch was possible, and it was reported to Microsoft and they released security patches for CVE-2020-0814 and CVE-2020-1302.

Those patches are also broken and can be easily bypassed.

Here’s the unpatched output of the windows installer output using Process Monitor:

And then here’s the updated version:

As you can see there’s no call of SetSecurityFile why ? shouldn’t it secure the folder, the answer is setting up the security description in c:\ allows for a race condition – since by default an authenticated user has delete access to subdirectories – so what can you do is calling CreateDirectory(path,&sz) and set sz to your security descriptor, that was the patch for CVE-2020-0814.

But wait, why should the directory be protected from a user?

Windows Installer Rollback Files and Scripts

When you try to install, repair, uninstall something you might notice that there’s a cancel button

According to Microsoft Documentation when the Windows Installer processes the installation script for the installation of a product or application, it simultaneously generates a rollback script and saves a copy of every file deleted during the installation.

These files are kept in a hidden system directory and are automatically deleted once the installation is successfully completed.

If however the installation is unsuccessful, the installer automatically performs a rollback installation that returns the system to its original state.

So if we can modify the rollback files we can do changes on the machine in the context of the windows installer service which run as SYSTEM.

As you can see here:

There’s probably no race condition since we can’t access to the directory because of the ACL.

The security descriptor doesn’t allow even a user to have read access to the directory.

But there’s still something we can do about that as you can see in the first the windows installer doesn’t proceed to create the rollback script directly but he create the directory put some temporary files on it and then he delete the directory the create again to proceed to create the rollback files.

But there’s a weird part when the windows installer check if the directory still exists after he successfully deleted it (see the NAME NOT FOUND).

But what if the directory still exist after he deleted it, the answer is easy it will bring back CVE-2020-1302.

As you can see Windows tries to set the security of the folder which can be easily abused.

How? pretty easy since we created the directory which means we have the ownership of directory we will have the WRITE_DAC access to the directory so as soon the Windows Installer tries to change the ACL to make write restricted we change it to allow everyone to access to the directory.

However, accessing to the rollback is a little bit hard, the rollback script is created with a security descriptor that allow only SYSTEM and Administrators to access to it, which mean even if we control the c:\config.msi directory we can’t access to the rollback script.

However as can be seen in CVE-2020-0814 we can move the entire directory and then replace it as, at this point we would have control over the entire directory and this will allow us to delete or move it.

This means we can move the entire directory into a temporary place and then create it by ourselves and place in it our specially created rollback file which would then be executed.

Sounds easy but not you can’t just do it in a straightforward way, the Windows Installer usually makes it harder than it sound, since the Windows Installer creates the rollback file in the directory using a special sharing method:

As you can see we are allowed only read only access so any attempt to access to it with delete or write access will result in SHARING_VIOALATION.

We can still do some damage sooner or later as the Windows Installer will close the handle, but then again reopen it when Windows Installer wants to read it after clicking on Cancel. In between these two steps we can to move the directory and replace it.

The vulnerability up to this point without modification would require a timing attack, pressing on the Cancel button at the right moment, so we need to address it in order to make the LPE work seamlessly.

There’s an application to create such MSI packages which will help to create something special called Advanced Installer, this product has a nice feature called Custom Actions:

Clicking on it will show you these options:

Clicking on “Launch File”:

Will present these options, the interesting for us option is Fail the installation if the custom action return an error, this what we are looking for an automated rollback, you can also see an option at bottom called Condition let’s what we can do with it.

As you can see, it asks us for the expression and it expects something like if(condition==true){//then execute}

If you pick the Wizard option (just right of the text box), you can then select Feature and clicked Next:

We can pick the Feature is being reinstalled:

This will allow us to execute the file only if the package is being repaired, making our exploit no longer require any user interaction.

At this point we have everything ready, we have an MSI package that will fail, will automatically rollback and will execute our code – we just need the Rollback file placed in the right folder and we are set.

Our rollback file will modify the Fax service executable to something we control – since users are allowed to start this service without any special privileges, after the registry was modified we just need to star the service and we get SYSTEM privileges.

Exploit

Because the exploitation of this vulnerability requires building an MSI file and using Bluebear rollback generated file, we will not be providing an exploit for this vulnerability – a working exploit in binary form was provided to Microsoft and used by them to verify the findings.