Windows DNS Server Remote Code Execution Vulnerability (CVE-2020-1350): What You Need to Know

Last updated at Tue, 27 Feb 2024 17:18:39 GMT

On Tuesday, July 14, 2020, Microsoft released a patch for a 17-year-old remote code execution (RCE) vulnerability in Windows Domain Name System (DNS) servers discovered by Check Point researchers—and disclosed in CVE-2020-1350. While there is a patch, organizations that are able to can quickly deploy the following registry entry to all Microsoft DNS servers to help block any in-development/in-use exploits:

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

Rapid7 strongly encourages all organizations running Microsoft DNS (i.e., every organization using Active Directory, so, literally, pretty much every organization) to deploy the mitigation and patch as quickly as possible as systems all the way back to Server 2003 are impacted.

Organizations that have the ability to analyze DNS requests should also configure detection technologies to flag anomalous use of SIG record queries (more on “why?” in the Extended Analysis).

This vulnerability only impacts Microsoft DNS servers.

Extended analysis of CVE-2020-1350

This Windows DNS server RCE vulnerability is currently rated 10.0, and Microsoft noted that this weakness was wormable, but that may not tell the full story. As Rapid7’s own Grant Willcox noted in the AttackerKB assessment:

"This is rather odd to me. 0xFF00 looks like a potential mitigation against an integer overflow, as it's 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 it's a heap buffer overflow.”

Check Point confirms that it is, indeed a heap-based buffer overflow.

Further in the assessment, Rapid7’s Cale Black noted that the official description of the vulnerability includes, “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,” and that the use of “upstream server” could mean that the malicious overly large DNS response has to come from an upstream resolver, which could complicate this vulnerability a bit.

The path to exploit first requires an attacker to host a DNS server capable of producing the malicious content. DNS clients—phones, tablets, laptops, desktops, servers, cameras, cars, etc.—can be “tricked” into making a query through their Microsoft DNS servers to a malicious server. The response from the malicious server (which uses compression in one of the DNS fields) is temporarily cached in the local Microsoft DNS server as it is passed back to the client, and the next time the query is requested, the local Microsoft DNS server will attempt to uncompress the fields before responding, resulting in a (heap) memory overflow, which can lead to remote code execution.

The Check Point research team discovered that the DNS SIG response parser in the Microsoft DNS server code appears to be a great place to target exploits, and once a Microsoft DNS server is compromised, it can be turned into a DNS client, thus making this a very wormable bug. You will really want to pay attention to SIG requests for the foreseeable future.

Check Point further notes that the exploit is viable via both TCP and UDP delivery paths for DNS requests and that it is possible to smuggle DNS requests into HTTP requests, meaning phishing attacks could be further weaponized beyond traditional credential stealing to Microsoft DNS server compromise attempts.

The Rapid7 Labs team encourages everyone to read the extremely informative and well-crafted Check Point deep-dive into this weakness for more information.

Exposure analysis: Windows DNS Server RCE Vulnerability

Project Sonar found just under 50,000 Microsoft DNS servers in UDP and TCP DNS scans in early July with the following common platform enumeration breakdowns:

fingerprint                                         count
cpe:/o:microsoft:windows_server_2008:Service Pack 1 38005
Known Microsoft but OS type/version unknown          7785
cpe:/o:microsoft:windows_server_2008:Service Pack 2  2113
cpe:/o:microsoft:windows_server_2008:-               1561
cpe:/o:microsoft:windows_server_2016:-                 20
cpe:/o:microsoft:windows_server_2012:-                  4

At the timestamp of the scans, all fingerprinted versions were vulnerable.

Most countries have Windows DNS servers in their allocated internet segments with exposure to this wormable RCE:

And, 20 members of the Fortune 500 are exposing over 250 (combined) vulnerable Windows DNS servers at the time of this post.

Rapid7 Labs will be monitoring our Project Lorelei honeypot network for anomalous activity that may be associated with this exploit and will update this post as findings come in.

Update: July 15, 2020

• Rapid7 InsightVM and Nexpose customers have full coverage for detecting vulnerable configurations with additional checks for whether the DNS service is enabled and if Microsoft's recommended workaround has already been applied.
• Rapid7 Labs has detected a significant increase in internet-wide DNS version scans from both benign and non-benign sources (using GreyNoise "actor" feeds).
• Researcher Kevin Beaumont has noted that organizations running Microsoft Windows DNS can disable remote DNS version query support with the following command: dnscmd /config /EnableVersionQuery 0. While there are other methods and tools available to successfully fingerprint Windows DNS servers without relying on the version query working, disabling version query responses will help stave off most unwanted opportunistic attackers.