Attacker Value
High
(1 user assessed)
Exploitability
Moderate
(1 user assessed)
User Interaction
None
Privileges Required
Low
Attack Vector
Local
1

CVE-2020-1170

Disclosure Date: June 09, 2020
Add any MITRE ATT&CK Tactics to the list below that apply to this CVE.

Description

An elevation of privilege vulnerability exists in Windows Defender that leads arbitrary file deletion on the system.To exploit the vulnerability, an attacker would first have to log on to the system, aka ‘Microsoft Windows Defender Elevation of Privilege Vulnerability’. This CVE ID is unique from CVE-2020-1163.

Add Assessment

4
Ratings
Technical Analysis

Update

As of July 24th 2020, there is a bypass for this patch, with a public writeup available at https://0x00sec.org/t/windows-defender-av-zero-day-vulnerability/22258 along with a working exploit at https://github.com/klinix5/WinDefend_ZeroDay. The bypass takes advantage of the fact that the patch only checks whether C:\Windows\Temp\MpCmdRun.log.bak is a junction directory, rather than accounting for the fact that any one of the subfolders could be a directory junction. Its possible also that one could also further nest folders within one another, which basically means the new patch will need to account for potentially near infinite nesting possibilities should it choose to still honor junction directories. I am still not 100% sure if one could exploit this via files, but my initial feeling says no as I think you would need to create symbolic links which requires administrator privileges, at which point there are much better and easier ways of getting SYSTEM access.

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 junction 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.

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.

Update #2: I have managed to confirm this is a legitimate LPE technique and after some further help from @jonasLyk on Twitter, I have managed to clear up a few misunderstandings on his technique of going from an arbitrary file deletion bug to SYSTEM level code execution using the technique mentioned above. This has resulted in a LPE module being created for Metasploit which is presently being worked on at https://github.com/rapid7/metasploit-framework/pull/13800, where we have managed to achieve a full LPE chain. Its just awaiting some refinement and reorganization before it can be landed into the framework.

General Information

Vendors

  • Microsoft

Products

  • Microsoft Forefront Endpoint Protection
  • Microsoft System Center
  • Microsoft Security Essentials
  • Windows Defender on Windows 10 Version 1803 for 32-bit Systems
  • Windows Defender on Windows 10 Version 1803 for x64-based Systems
  • Windows Defender on Windows Server, version 1803 (Server Core Installation)
  • Windows Defender on Windows 10 Version 1803 for ARM64-based Systems
  • Windows Defender on Windows 10 Version 1809 for 32-bit Systems
  • Windows Defender on Windows 10 Version 1809 for x64-based Systems
  • Windows Defender on Windows 10 Version 1809 for ARM64-based Systems
  • Windows Defender on Windows Server 2019
  • Windows Defender on Windows Server 2019 (Server Core installation)
  • Windows Defender on Windows 10 Version 1909 for 32-bit Systems
  • Windows Defender on Windows 10 Version 1909 for x64-based Systems
  • Windows Defender on Windows 10 Version 1909 for ARM64-based Systems
  • Windows Defender on Windows Server, version 1909 (Server Core installation)
  • Windows Defender on Windows 10 Version 1709 for 32-bit Systems
  • Windows Defender on Windows 10 Version 1709 for x64-based Systems
  • Windows Defender on Windows 10 Version 1709 for ARM64-based Systems
  • Windows Defender on Windows 10 Version 1903 for 32-bit Systems
  • Windows Defender on Windows 10 Version 1903 for x64-based Systems
  • Windows Defender on Windows 10 Version 1903 for ARM64-based Systems
  • Windows Defender on Windows Server, version 1903 (Server Core installation)
  • Windows Defender on Windows 10 for 32-bit Systems
  • Windows Defender on Windows 10 for x64-based Systems
  • Windows Defender on Windows 10 Version 1607 for 32-bit Systems
  • Windows Defender on Windows 10 Version 1607 for x64-based Systems
  • Windows Defender on Windows Server 2016
  • Windows Defender on Windows Server 2016 (Server Core installation)
  • Windows Defender on Windows 7 for 32-bit Systems
  • Windows Defender on Windows 7 for x64-based Systems
  • Windows Defender on Windows 8.1 for 32-bit systems
  • Windows Defender on Windows 8.1 for x64-based systems
  • Windows Defender on Windows RT 8.1
  • Windows Defender on Windows Server 2008 for 32-bit Systems
  • Windows Defender on Windows Server 2008 for 32-bit Systems (Server Core installation)
  • Windows Defender on Windows Server 2008 for Itanium-Based Systems
  • Windows Defender on Windows Server 2008 R2 for Itanium-Based Systems
  • Windows Defender on Windows Server 2008 R2 for x64-based Systems
  • Windows Defender on Windows Server 2008 R2 for x64-based Systems (Server Core installation)
  • Windows Defender on Windows Server 2012
  • Windows Defender on Windows Server 2012 (Server Core installation)
  • Windows Defender on Windows Server 2012 R2
  • Windows Defender on Windows Server 2012 R2 (Server Core installation)

Additional Info

Technical Analysis