Windows: Malicious Software Removal Tool Unsafe Temp Directory Use Elevation of Privilege

[GoogleCodeExporter]

Windows: Malicious Software Removal Tool Unsafe Temp Directory Use Elevation of 
Privilege
Platform: Tested on Windows 8.1 Update 32 bit and 64 bit, should work on 10 as 
well
Version: MRT 5.25.11502.0 Built on 9 June 2015
Class: Elevation of Privilege

Summary:
The Malicious Software Removal Tool executable uses the global temp directory 
to write and load some DLLs. By exploiting a race condition in this it’s 
possible to get a DLL loaded into MRT.exe running at Local System causing 
elevation of privilege.

Description:

The Malicious Software Removal Tool is distributed as the monolithic executable 
MRT.exe. When this executes it writes three DLLs to c:\windows\temp directory 
then loads them using LoadLibraryEx. As a normal user can write to 
c:\windows\temp it’s possible to exploit a race condition in the process to 
replace one the DLLs after the MRT executable has verified the files signature 
but before LoadLibraryEx is called. While MRT.exe seems to sort of try and 
protect itself by holding a handle to these 3 DLLs it only specifies a 
READ/DELETE lock (which is necessary for things like LoadLibrary to work) which 
means we can rename a DLL during the operation, freeing up the directory entry 
so we can replace the file. 

We can exploit it by using a sequence of oplocks to trap the major steps of the 
file creation. Currently we can do something like this:

1. Create dummy files for the 3 DLL in the temp folder so that the user can 
write to them, we can now start MRT through its scheduled task or just wait for 
it to start at some defined interval. 
2. Oplock on DEVINV.DLL, once this triggers MPENGINE.DLL and MPGEAR.DLL has 
been dropped to the temp folder by MRT.exe
3. Oplock on MPGEAR.DLL, this is just to pass the writing of DEVINV.DLL. 
4. Oplock on DEVINV.DLL again. Once this triggers it means that MPGEAR.DLL and 
MPENGINE.DLL have been opened and read into memory (not sure why MRT does this, 
perhaps it’s verifying it wrote them correctly)
5. We can now move MPENGINE.DLL out of the way by renaming it, we then recopy 
the same DLL to a new copy in the temp folder.
6. We oplock on MPENGINE.DLL, once this triggers MRT is just about to verify 
the signature in WinVerifyTrust. 
7. The last step is the only one which requires brute force, we spin in a loop 
trying to open the file for write access (remember that the MPENGINE.DLL file 
opened by WinVerifyTrust isn’t the same one opened between steps 3 and 4, so 
when the handle is closed we can open with exclusive access). To ensure 
LoadLibrary doesn’t get a sharing violation while we’re overwriting the DLL 
we use the native create option FILE_OPEN_REQUIRING_OPLOCK to atomically open 
the file and set a preliminary oplock. We never finish the oplock but it 
doesn’t matter for our purposes. Choosing MPENGINE is the most reliable 
because it’s very large so takes a long time in WinVerifyTrust. 
8. Once we close the file handle we’ll release the oplock, LoadLibraryEx will 
now load our malicious DLL and we get system privileges.

There are a couple of problems with the exploit/vulnerability. Firstly I’ve 
seen some versions of MRT leave the DLLs in the directory, this causes a 
problem as a normal user cannot replace them. However the versions I’m 
looking at now seems to delete the files after use so you can plant the 
appropriate files. Second there seems to be some condition where MRT creates a 
randomly named directory and instead drops the files there, that seems to be 
the “correct” solution but it isn’t clear under what conditions it 
happens. Finally in order to get MRT to run you can execute a scheduled task 
but a normal user cannot do that, instead they’d have to wait around for the 
computer to become idle to trigger the task. 

Basically I don’t think MRT should be using Windows Temp at all, but if it 
does it should at least create random names. Another thing I’ve noticed is 
that, at least for a machine and a particular version of MRT it creates a known 
directory in temp and writes scan results to it. This might be exploitable in 
some way using junctions etc to overwrite files. I’ve not tested this.

Proof of Concept:

The PoC demonstrates the vulnerability getting cmd running at system privileges 
on the current active desktop. Note for simplicity the scheduled task needs to 
be started by an administrator, but in theory you could leave it running until 
the scheduled task runs on its own. The password for the 7z file is 
‘password’. 

1) Extract the PoC to a location on the system hard disk (where Windows is) and 
is writable by a normal user
2) As a normal user execute MrtTest.exe, it stop wait.
3) Execute the scheduled task using an administrator copy of powershell with 
the command Start-ScheduledTask \Microsoft\Windows\RemoveTools\MRT_HB
3) The PoC should print the current steps

Troubleshooting:

If the poc exits immediately it’s likely that it can write the DLLs to the 
temp folder. If you want to verify it works delete the DLLs from an 
administrator’s account. Not sure what conditions they’ll stay there, 
perhaps it’s an old version thing? 

If it starts but nothing happens perhaps MRT has decided to use the random 
directory name instead.

Expected Result:
It shouldn’t be possible to replace the DLLs files or even get access to the 
location

Observed Result:
CMD is running as system due to the malicious DLL being loaded by MRT.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

Original issue reported on code.google.com by fors...@google.com on 11 Jun 2015 at 3:07

Attachments:

• poc.7z

[GoogleCodeExporter]

Received MSRC Case Number 30421

Original comment by fors...@google.com on 11 Jun 2015 at 9:49

• Added labels: Id-30421

[GoogleCodeExporter]

Correspondence Date: 23 Jun 2015
> Microsoft says they've managed to reproduce and will determine whether it's 
something which needs to be fixed in a security bulletin. 

Original comment by fors...@google.com on 23 Jun 2015 at 10:02

[GoogleCodeExporter]

Microsoft have assigned a CVE and expect to fix the issue in the upcoming patch 
tuesday.

Original comment by fors...@google.com on 10 Jul 2015 at 12:35

• Added labels: CVE-2015-2418

[GoogleCodeExporter]

Fixed in https://technet.microsoft.com/en-us/library/3074162.aspx

Original comment by fors...@google.com on 14 Jul 2015 at 7:52

• Changed state: Fixed

[GoogleCodeExporter]

Opening issue

Original comment by fors...@google.com on 22 Jul 2015 at 5:00

• Removed labels: Restrict-View-Commit