gwillcox-r7 (18)

Last Login: June 26, 2020
Assessments
4
Score
18

gwillcox-r7's Contributions (4)

Sort by:
Filter by:
4
Ratings
Technical Analysis

Summary/TLDR

This is a vulnerability within the MpCmdRun.exe component of Windows Defender which, in MpCmdRun.exe versions prior to 4.18.2005.1, did not appropriately validate that the file at C:\Windows\Temp\MpCmdRun.log.bak was not a directory prior to trying to delete it. As a result, attackers could exploit this vulnerability to delete arbitrary files as the SYSTEM user, which could allow for an elevation of privilege.

Rating as medium as it require authenticated access, but leaving exploitability as a medium as in theory this could work if the LPE vector does indeed work like the article states, but wasn’t able to confirm this. Also need to fill a log file with 16 MB of data which can take some time to do when your only writing about 2 KB per attempt.

Edit: Originally put this as easy to weaponize but tbh the file deletion trick stumped a lot of people as many people have stopped there before getting to LPE so even if we do get it working, its not exactly a “simple trick”.

Longer Explanation

Now that the summary of this vulnerability is out of the way, lets dive into the details a bit. The original discoverer of this bug is itm4n, who wrote a writeup at https://itm4n.github.io/cve-2020-1170-windows-defender-eop/ explaining his thought process and steps for discovering this vulnerability and the various different things that he found worked and didn’t work during his research. If you haven’t read it already I would highly recommend taking a look at it. Its not a challenging read compared to most technical blog posts, and it provides a great overview of how to actually query deeper to find interesting bugs.

With that being said I’m not going to repeat itm4n’s blog verbatum here, but rather explain some of the notes I made whilst reading his blog. The first interesting point, and perhaps the most important, is that Windows Defender has a log file that it creates when updating signatures, located at C:\Windows\Temp\MpCmdRun.log, which is then backed up to a file at C:\Windows\Temp\MpCmdRun.log.bak when its size exceeds 16 MB. The interesting thing to note though is that if one runs icacls on these files as an administrator, they will notice that these files can only be deleted or otherwise modified by SYSTEM or one of the computer’s administrators. This leads us to an interesting point: If the C:\Windows\Temp\MpCmdRun.log.bak file already exists, this vulnerability can only be exploited by a local administrator.

If alternatively, the file does not exist, an attacker can create a Directory Junction at C:\Windows\Temp\MpCmdRun.log.bak and link this to an arbitrary directory by using the command cmd.exe /C 'mklink /J C:\Windows\Temp\MpCmdRun.log.bak *target directory*. Following this they will then need to fill up the contents of the file at C:\Windows\Temp\MpCmdRun.log so that is 16 MB or larger, which can be done by repetitively running the command for ($i=0; $i -lt 2000; $i++) { Update-MpSignature -ErrorAction SilentlyContinue -UpdateSource InternalDefinitionUpdateServer }. Note that this command may need some pauses to prevent locking up MpCmdRun.exe as during tests there where times if we ran too many tests we either had to open another PowerShell command, or wait about 40 seconds or so before continuing. More testing may need to be performed to check how to solve this issue and make things more reliable.

Whilst executing this loop the attacker will most likely end up triggering the bug, which will cause all files and folders in the *target directory* specified earlier, no matter how deeply nested they are inside *target directory*, to be deleted. In the exploit itm4n briefly shows within his blog, he set *target directory* to C:\ProgramData\Microsoft\Windows\WER. The reason for this is that by deleting this directory and all files and folders located underneath it, we can then abuse a flaw in the WER service whereby if the C:\ProgramData\Microsoft\Windows\WER folder doesn’t exist, then when running the task \Microsoft\Windows\Windows Error Reporting\QueueReporting, the folder will be recreated albeit with read, write and delete permissions enabled for all authenticated users.

Supposively you can then create the C:\ProgramData\Microsoft\Windows\WER folder as a junction folder that links to \??\c:\windows\system32\wermgr.exe.local. This folder does not exist by default on Windows systems. By doing this C:\Windows\System32\wermgr.exe.local\ will be created as a directory with the same open permissions that grant all authenticated users to read, write and delete permissions. From there one can create the amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.18362.778_none_e6c6b761130d4fb8 directory inside of C:\Windows\System32\wermgr.exe.local\ , and then place a malicious copy of comctl32.dll, which will then get loaded and run as the SYSTEM user when wermgr.exe is run, granting the attacker arbitrary code execution as the SYSTEM user.

Unfortunately whilst I was able to confirm the original arbitrary file deletion bug and that it was possible to delete the C:\ProgramData\Microsoft\Windows\WER on a June 2019 patched Windows 10 x64 v2004 machine, create an empty WER job using the code from https://github.com/thesecretclub/ArbitraryDirectoryDeletion/blob/master/wer.h, and have the C:\ProgramData\Microsoft\Windows\WER directory created with Read, Write, and Delete permissions granted to all authenticated users, I was unable to figure out how to create the junction folder as needed to exploit the Windows Error Reporting (WER) behavior, as if the directory C:\ProgramData\Microsoft\Windows\WER exists, one cannot create a junction directory on top of it using tools like mklink. Perhaps there is some other way I am not aware of?

Overall the bug definitely exists, but I remain a bit skeptical on the practicality of getting it to a LPE for the time being until I can confirm how to transform the arbitrary file deletion into a LPE vector, cause articles can be wrong at times and I like to run code to confirm whether things legitimately work or not, not rely on heresay.

6
Ratings
Technical Analysis

Wrote the Metasploit module for this vulnerability which is currently sitting as a PR at https://github.com/rapid7/metasploit-framework/pull/13554. Let me start with an overview of this vulnerability and then explain why I believe this vulnerability is more valuable than it may initially appear to be.

First off, as mentioned in other reviews of this bug, you can find the original writeup at https://itm4n.github.io/cve-2020-0787-windows-bits-eop/ and the PoC at https://github.com/itm4n/BitsArbitraryFileMove. As described in the blog, the BITS service exposes the Legacy Control Class over COM. An attacker can use this to obtain a pointer to the IBackgroundCopyGroup interface, which contains two undocumented methods, QueryJobInterface() and SetNotificationPointer(). By calling the QueryJobInterface() method of the IBackgroundCopyGroup method, the attacker will get a handle to the new IBackgroundCopyJob interface.

The problem here is that the handle to the IBackgroundCopyJob group is done without proper impersonation. Normally this would not be an issue since the other methods implement impersonation properly. However there is a catch. When adding a new job using the IBackgroundCopyJob interface that was returned via the method described earlier, the temporary file that BITS creates when creating a new job will be renamed via a call to MoveFileEx() with the permissions of the IBackgroundCopyJob interface. Well since BITS runs as SYSTEM and the IBackgroundCopyJob interface didn’t implement impersonation, guess what? Its going to copy the file as the SYSTEM user.

Exploitation of this vulnerability is not the most difficult in the world but it basically relies on the following process (described in https://itm4n.github.io/cve-2020-0787-windows-bits-eop/ way better than I can explain it here, but heck I’ll give it a shot):

  1. Set up a temporary directory that will be our staging area and create two folders: Bait and MountPoint inside of it.
  2. Upload the payload DLL within this temporary directory.
  3. Create a symbolic link between MountPoint and Bait.
  4. Create a new job using the IBackgroundCopyJob interface, whose handle is obtained by calling the QueryJobInterface() method of the IBackgroundCopyGroup interface,
  5. Since the BITS job will be created in a suspended state, locate the temporary BITS job file, and set a file oplock on it so that our function will be called whenever someone tries to move the file.
  6. Resume the BITS job
  7. Our oplock gets hit. Delete the previous symbolic link, and create a symbolic link between the MountPoint directory and \RPC Control\. Create two more symbolic links to link the temporary BITS file within the MountPoint directory to the DLL we want to copy, and the sample test.txt file we were going to the file to so that it instead points to the protected location we would like the file to be copied to.
  8. Release the oplock, and profit!

Again its probably better you look at the How to Exploit this Vulnerability? section of https://itm4n.github.io/cve-2020-0787-windows-bits-eop/ for a better explanation of this, he words it much better than I do.

With this aside though the next important thing to note is that BITS was introduced with Windows 7, which is reflected in the affected systems listed at https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0787. Looking over this list we can see that every single version of Windows, be it Server or Workstation, is affected by this vulnerability, regardless of architecture.

In fact further examination of this bug revealed that with the PoC provided, one can very reliably obtain SYSTEM level file copies on nearly any affected machine with no interruption to its service at all. The only downside though is that SYSTEM level file copies alone are not enough to get LPE. To do this an attacker needs to combine this vulnerability with a DLL hijacking vulnerability or some other vulnerability where the placement of an arbitrary file into a protected location would grant the attacker additional privileges.

In the case of the PoC and the Metasploit module, this is achieved by taking advantage of a bug in the Windows Update Session Orchestrator service, which is well documented at https://itm4n.github.io/usodllloader-part1/ and https://itm4n.github.io/usodllloader-part2/. In a nutshell, an attacker can gain SYSTEM level code execution if they can create the file C:\Windows\System32\WindowsCoreDeviceInfo.dll and then run the undocumented command usoclient StartScan or usoclient StartInteractiveScan. Note that since the Update Session Orchestrator service only exists on Windows 10 and later, it is only possible to use this technique on those computers. With this being said though other techniques could be used to gain LPE on other Windows systems, it is just a matter of creativity.

This means that in essence, any Windows system that has not applied the March 2020 updates has a pretty universally accessible arbitrary file copy vulnerability provided that an attacker already has local access to the system. The only other limitation is the aforementioned DLL hijacking issue; however should an attacker account for this via vulnerabilities such as the NetMan DLL hijacking issue described at https://itm4n.github.io/windows-server-netman-dll-hijacking/, which affects all Windows Server editions from Windows Server 2008 R2 to Windows Server 2019, they could easily adjust this vulnerability to escalate privileges on a wide variety of systems.

In summary this is one to look out for and I can see this being weaponized in the future, however attackers will need a little bit of work to get a DLL hijacking bug working for each target they want to compromise (not that hard given that Microsoft doesn’t consider DLL hijacking issues a bug and tends not to patch them), and the fact that they need local access (the main limiting factor here).

2
Ratings
Technical Analysis

To add to @busterb’s assessment, another thing to consider is that SMBv1, which this vulnerability relies on, is disabled by default on Windows 10 (Build 1803) according to https://www.petenetlive.com/KB/Article/0001461. This is further confirmed on Microsoft’s official website at https://docs.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows where they state that SMBv1 is not installed by default on Windows 10 version 1709 and later and Windows Server version 1709 and later.

Considering the push from Microsoft to force Windows 10 users to automatically upgrade, and the fact that according to https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide, 72.96% of Windows users are running Windows 10, the chances are that unless your in an environment where you need to support older software, SMBv1 is most likely going to be disabled.

Exploitability will most likely be difficult given the past history of SMB vulnerabilities, but may be easier on older versions of Windows such as Windows 7 that have not introduced the modern mitigations that Windows 10 has, particularly in the area of heap randomization.