Very High
CVE-2020-1350 Windows DNS Server Remote Code Execution (SigRed)
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
Add References:
CVE-2020-1350 Windows DNS Server Remote Code Execution (SigRed)
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Topic Tags
Description
A remote code execution vulnerability codenamed “SigRed” exists in Windows Domain Name System servers when they fail to properly handle requests. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the Local System Account. Windows servers that are configured as DNS servers are at risk from this vulnerability.
To exploit the vulnerability, an unauthenticated attacker could send malicious requests to a Windows DNS server.
The update addresses the vulnerability by modifying how Windows DNS servers handle requests.
Add Assessment
Ratings
-
Attacker ValueVery High
-
ExploitabilityMedium
Technical Analysis
Important Update: This is now supposedly being exploited in the wild by Chinese state actors according to this NSA announcement: https://media.defense.gov/2020/Oct/20/2002519884/-1/-1/0/CSA_CHINESE_EXPLOIT_VULNERABILITIES_UOO179811.PDF
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.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportRatings
-
Attacker ValueVery High
-
ExploitabilityHigh
Technical Analysis
Given the need to include a corrupted response from a recursive DNS server in the chain, this may be difficult to exploit in practice, at least with a properly configured DNS server that doesn’t allow recursive queries from untrusted sources.
This vuln seems like it needs a hat trick to execute, when there might be easier ways to get DA in a network, but after looking at some analysis by others on this, it seems there could be some creative solutions. I’m changing my mind in that there may be some form of attack on this soon, even if it’s just leveraging the DoS attack, such as this is a crash PoC from maxpl0it:
https://twitter.com/maxpl0it/status/1283537179365564417
https://twitter.com/maxpl0it/status/1283471692006920193
Here are some ruminations on alternate vectors outside of just directly making queries:
https://twitter.com/bmenrigh/status/1283189603873075201
Basically all the info is here for someone to try to attempt a mass DoS attempt at least in conjunction with some sort of side-channel attack on domain-joined clients. So this may become easier to weaponize for crashing domain controllers, but I still posit a reliable RCE will be difficult.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportRatings
Technical Analysis
I’m going to quote @hrbrmstr here: Since the registry config workaround doesn’t require a system restart, it seems like this is going to be a niche exploitation issue for organizations that haven’t config’d or patched their way to safety.
Still haven’t seen PoC past the DoS from maxpl0it (which is a very good Twitter username, unrelatedly) that surfaced quickly after the vuln details were published. Anecdotally, a few other researchers have mused that this probably isn’t the ripest or most valuable target for exploitation (famous last words, eh?).
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportCVSS V3 Severity and Metrics
General Information
Vendors
- Microsoft
Products
- Windows Server,
- Windows Server, version 1909 (Server Core installation),
- Windows Server, version 1903 (Server Core installation),
- Windows Server, version 2004 (Server Core installation)
Exploited in the Wild
Would you like to delete this Exploited in the Wild Report?
Yes, delete this reportWould you like to delete this Exploited in the Wild Report?
Yes, delete this reportWould you like to delete this Exploited in the Wild Report?
Yes, delete this reportReferences
Miscellaneous
Additional Info
Technical Analysis
Description: On Tuesday, July 14 Microsoft released a patch for CVE-2020-1350, a 17-year-old critical Remote Code Execution (RCE) vulnerability in Windows DNS Server that Microsoft’s Security Response Center classified as a wormable vulnerability. CVE-2020-1350, code-named “SigRed,” carries a CVSSv3 base score of 10.0 and results from a flaw in Microsoft’s DNS server role implementation that can be triggered by a malicious DNS response. According to Check Point Research, the security firm who discovered the vulnerability, successful exploitation can result in domain administrator privileges, compromising critical business data, assets, and infrastructure.
The U.S. Department of Homeland Security issued an emergency directive on July 16, 2020 requiring federal agencies to patch or mitigate the vulnerability within 24 hours—notably only the third time CISA’s current director has taken such an action. A public denial of service (DoS) exploit was released on July 15.
Rapid7’s Labs team found roughly 50,000 Microsoft DNS servers in UDP and TCP DNS scans in early July. A Sigma rule to detect exploitation is available from Florian Roth here. Roth has asked for reports of false positives.
Affected products include: CVE-2020-1350 affects all Windows Server versions (2003 to 2019) running a Windows DNS server. Non-Microsoft DNS Servers are not affected.
Rapid7 analysis: During a month of competing CVSS 10 vulnerabilities, CVE-2020-1350 stands out both because of the prevalence of Windows DNS servers and because of Microsoft’s warnings on wormability—warnings that the research community has speculated likely stem from private proof of exploitability. As of July 20, 2020, there have been no reports of exploitation in the wild, but with a patch widely available and a DoS proof-of-concept publicly accessible, we expect active exploitation shortly. As with any vulnerability known to be wormable, CVE-2020-1350 will make an attractive target for ransomware campaigns in addition to stealthier threat actors. Rapid7’s blog on CVE-2020-1350 discusses exploitation scenarios along with internet exposure of Windows DNS servers, but because the exploitation path can even be invoked from a trusted client passively making a query to a malicious domain, even limiting access of the Windows DNS service is not a mitigation for this vulnerability.
Guidance: We reinforce CISA’s urgent guidance to those who have Windows servers running DNS: Patch on an emergency basis. Microsoft released guidance on mitigations for those who cannot patch, but as with other recent high-severity, high-urgency vulnerabilities, it is highly recommended that defenders prioritize patching over mitigation wherever possible.
Report as Emergent Threat Response
Report as Exploited in the Wild
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below: