gwillcox-r7 (41)

Last Login: September 09, 2020
Assessments
8
Score
41

gwillcox-r7's Contributions (8)

Sort by:
Filter by:
4
Ratings
Technical Analysis

This vulnerability was originally found by @klinix5, who later found another way to exploit the issue which they reported publicly at https://github.com/klinix5/Windows-Setup-EoP as a 0day. The original bug occurred due to the fact that on Windows 10 systems prior to the August 2020 updates, there was a flaw within the way Windows Setup operated which resulted in a LPE vulnerability.

More specifically, within windowsupdatebox.exe, there was a call to CreateDirectoryW() with a NULL security descriptor, which would create the folder C:\$WINDOWS.~BT with the same permissions as those from the C:\ directory, which by default allow everyone read, write, and delete access to the directory. After this, a CreateFileW() call would be made with the name C:\$WINDOWS.~BT to get a handle to the folder for later use, before Windows Setup would then execute a SetSecurityInfo() call on the C:\$WINDOWS.~BT directory to set its permissions appropriately.

The issue with this code is that attackers could create a directory junction on the C:\$WINDOWS.~BT directory once it had been created with open permissions, and cause the CreateFileW() call to create an file at an arbitrary location on the disk as the SYSTEM user. Then once this had been done, they could remove the directory junction to ensure that the SetSecurityInfo() call didn’t alter the permissions of the file that was created with CreateFileW().

Microsoft then fixed this vulnerability in their August 2020 update by patching the code so that they passed the security descriptor in as part of the CreateDirectoryW() call, and they removed the calls to CreateFileW() and SetSecurityInfo(). This means that even if an attacker can redirect the creation of the directory via a directory junction (an attack that is still possible with the new code), they won’t have access to the resulting directory that is created due to the security permissions that will be applied on the directory at the time of its creation. This also prevents the original timing issue by ensuring that there is no period in which the directory will be created with open permissions that could allow low privileged users to tamper with it.

Unfortunately, @klinix5, the original discoverer of this bug, found that Microsoft had another issue; specifically that once the Windows Setup was done, it would attempt to delete C:\$WINDOWS.~BT without properly checking that C:\$WINDOWS.~BT wasn’t a reparse point. Attackers can create the C:\$WINDOWS.~BT directory themselves and then create two subdirectories and place oplocks on them. These oplocks will only trigger once the C:\$WINDOWS.~BT directory is in the process of being deleted.

When these oplocks trigger, the attacker can then turn the respective directories into directory junctions, thereby allowing them to delete arbitrary directories as the SYSTEM user. The attacker can then use techniques such as the one described in https://secret.club/2020/04/23/directory-deletion-shell.html to transform the arbitrary file deletion into code execution as the SYSTEM user.

Note that this second technique does not have a patch, and is still a 0day as of September 1st 2020. Its likely however that Microsoft will patch this at a later date, however the exact date is as of yet unknown. For this reason the value of this vulnerability has been increased to 4 to reflect the unpatched nature of this bug. Do keep in mind however that an attacker will need to have authenticated GUI access for this bug to work, and that whilst Microsoft states that the bug works on Windows 10 v2004, it doesn’t seem like it would be possible to trigger it on this version at this point in time, as there is no “next version” to upgrade to. Once the next version of Windows does come out though, those Windows 10 v2004 systems which have not yet applied this patch will be exploitable.

3
Ratings
Technical Analysis

Looking at the patch for this vulnerability, one can see that a new function was added, UShortAdd. Looking at this, I immediately thought that this might be a integer overflow vulnerability. Turns out I was right, but the actual bug is a little bit tricky to determine at first glance. This is cause when calculating the size for a heap allocation which is performed via a call to Dns_AllocZero, several functions first correctly convert the user’s input to an unsigned value, by using movzx to convert the attacker’s input, stored in the RCX register, into an unsigned integer after first adding 0x32 to its value. The result is then stored in RAX.

The problem comes in when it then goes ahead and tries to adjust this value further. In the case of the SigRecordCopy function, this is done by attempting to add 0x28 to AX. This is an issue as if AX is a large number, then adding 0x28 could cause it to overflow into a large negative number. In SigRecordCopy, this value is then incremented by 0x20 before then being used as the number of bytes to allocate on the process heap with Dns_AllocZero, meaning that the attacker can cause dnsrslvr.dll to allocate an undersized heap buffer, which is subsequently filled with data via a call to memcpy later on within the SigRecordCopy function.

This same logic was applied to a total of 6 different functions, which are listed below:

  1. SigRecordCopy
  2. NsecRecordCopy
  3. KeyRecordCopy
  4. OptRecordCopy
  5. DhcidRecordCopy
  6. Nsec3RecordCopy

As far as attacking these vulnerabilities go, there are a number of good and bad things to consider here. The first is that the overflow takes place on the process heap, which generally speaking is harder to exploit than a normal stack overflow, however articles like https://blog.rapid7.com/2019/06/12/heap-overflow-exploitation-on-windows-10-explained/ have shown that it is possible to gain reliable control over the process heap assuming certain requirements are met. The main issue in exploiting this likely would be the need to find a separate information leak to exploit more recent machines and bypass the DEP + ASLR protections that will be enabled on them.

On the other hand the good news is that some of these affected functions are very short so it is unlikely that an attacker would have issues with stray instructions messing up their exploit should they manage to find a good information leak. Also since this is a local privilege escalation, then since the attacker would have local access to the victim’s machine, they would likely be able to have more opportunities to find DEP/ASLR bypasses that might not otherwise be exploitable remotely.

Finally given the nature of this bug, it seems likely that an attacker would have to set up some sort of malicious DNS server, and then they would have to query it. The result would then be placed in the DNS resolver cache, and when the same query is made again, the corresponding record copying function would be called within dnsrslvr.dll, which would then cause the heap overflow. This is just my initial guess though based on the expected behavior of dnsrslvr.dll though.

4
Ratings
Technical Analysis

TLDR: Originally this was written as a low priority issue, however after further discussions internally we are upping the risk due to the fact that IE 11 is installed on every Windows computer and cannot be removed (as it is an OS component), and the fact that there still remains the risk of attack via social engineering, which could get around many of the originally proposed mitigations.

Originally I wrote this as a low priority issue, however after looking into it more I’m upping the risk on this as IE 11 is installed by default on every Windows system and it cannot be removed, which means that with some social engineering, its possible to compromise any Windows user’s computer. Above all else this factor should be kept in mind as it means that even if an organization doesn’t have IE set as its default, all it takes is a user who is convinced that to download some info they require they need to use IE instead of Firefox, and a malicious website, and attackers will start to have a foothold within the network.

Now what are some of the limiting factors here? Well you can’t uninstall IE, as it is integrated into every Windows operating system and is considered an OS component. This explains the point above as to why this vulnerability really does affect pretty much every single Windows user. However if organizations implement policies or protections that block IE from being run, then users will not be able to open IE and therefore trigger the vulnerability.

The other point to note is that according to https://gs.statcounter.com/browser-market-share, only 1.28% of people use IE these days, compared to 65.89% of people that use Chrome. The closest competitor there is Safari at a little over 16%. This means that this vulnerability is likely to be more of a risk to enterprises where IE use is more likely due to the prevalence of legacy systems and software, and is unlikely to affect the average home user.

However, keep in mind that particularly in the government space, there are many organizations that still use IE by default or which require users to interact with their legacy applications using IE (due to compatibility issues or similar). These organizations need to patch this issue as soon as possible as all it takes to exploit this issue is one user browsing to a site with a malicious advertisement or one user clicking a link in a malicious email for that user to be compromised.

For those that are not using IE by default this issue will be slightly less of a risk due to the need for attackers to conduct social engineering attacks against end users to convince them to load a malicious site in IE, however remember that all it takes is one user clicking on a link for attackers to start gaining a deeper foothold into your network. Even if the social engineering attack only nets a 10% success rate, if your targeting an organization of 1000 users, that’s 100 users that are now compromised, all of which could provide an attacker with unique possibilities to escalate their privileges within your network.

7
Ratings
Technical Analysis

Update: Checkpoint has since released their blog post at https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/ with much more details on this vulnerability than when I originally wrote this. I’ll update a few statements here but readers are encouraged to read the paper for more details.

On July 14th, 2020, Microsoft released CVE-2020-1350, a critical DNS server remote code execution vulnerability that can result in Domain compromise and which is listed as a 10.0 CVE rating. Microsoft also described this vulnerability as wormable and recommended the following mitigation:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters 
  DWORD = TcpReceivePacketSize 
  Value = 0xFF00

This is rather odd to me. 0xFF00 looks like a potential mitigation against a integer overflow, as its possible the vulnerability stems from any packets being over 0xFFFF causing an integer overflow in memory, resulting in the allocation of a very small amount of memory to hold a very large buffer. At the very least, the fact that the recommended mitigation forcibly controls the max size of the packet that can be received suggests that this is a buffer overflow of some sort. Given the dynamic nature of DNS and the fact that it has to handle multiple requests at once, my guess is that its a heap buffer overflow.

Now that CheckPoint’s blog post is public one can confirm that this is in fact a integer overflow leading to a heap buffer overflow within the SigWireRead function of dns.exe, the server component of Microsoft’s DNS implementation. When the DNS server receives a SIG query response, that, when decompressed, incremented by 0x14, and added to the result of an earlier Name_PacketNameToCountNameEx call, is greater than 0xFFFF, will result in integer overflow, resulting in the following RR_AllocateEx call allocating too small of a heap buffer for the resource record, and a heap buffer overflow occurring when memcpy is called to copy the SIG query response into the overly small heap buffer that RR_AllocateEx allocated.

A very important point to note here is that whilst there is a RCE potential here by smuggling DNS requests over HTTP, it seems that CheckPoint has noted that only some browsers, notably Microsoft Edge and Internet Explorer, actually support sending HTTP requests to port 53, so whilst their video at https://youtu.be/PUlMmhD5it8 is certainly pretty cool, its important to note that with Google Chrome taking up over 65% of the browser market share according to https://gs.statcounter.com/browser-market-share as of July 2020, and IE and Edge accounting for a combined total of roughly 4% of all browsers, its pretty unlikely that most organizations will be affected by the HTTP smuggling attack vector unless users are forced to use IE/Edge in their networks for some reason (such as support for legacy apps).

Edit: @cblack-r7 Also pointed out to me that looking at https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability they mention this line “After the workaround is implemented, a Windows DNS server will be unable to resolve DNS names for its clients when the DNS response from the upstream server is larger than 65280 bytes.” He noticed that the terminology “upstream server” could mean that the malicious overly large DNS response has to come from an upstream resolver, which could complicate this vulnerability a little bit. This is also something that @busterb’s assessment seems to reflect concern about and is something that the CheckPoint blog doesn’t really address from what I’ve seen (though feel free to correct me if I am wrong here)

It should be noted that this vulnerability only affects Microsoft’s DNS implementation, however it goes way back all the way to Windows Server 2008. I wouldn’t be surprised if this also potentially affected Windows Server 2003 as well though, given how these types of vulns tend to be rather systemic, but I could be wrong there.

Another important point to note is that on Windows the DNS service runs as SYSTEM, so this will essentially be a remote SYSTEM level exploit for any attackers, which is pretty powerful. Unfortunately there is a limitation that if this is a remote RCE on the heap, the attacker will most likely have to deal with a lot of the new heap related mitigations introduced starting with Windows 8 and which were greatly improved with Windows 10. So this likely means that Windows Server 2008 and Windows Server 2008 R2 will be easy to develop an exploit for, but more recent servers like Windows Server 2019 may see a noticeable lag in exploit development time whilst exploit developers work their way around these mitigations. This can be seen in past heap overflow exploits where the Windows 7/Windows Server 2008 exploit came out very quickly but in some cases it took several months or even a year for the Windows 10/Server 2019 exploit to come out.

It should be noted that whilst this vulnerability has not been used in active attacks according to Microsoft, I’d safely place money on seeing this vulnerability get weaponized very quickly.

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.

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

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