Major Vulnerability in Windows DNS Servers: Responding to CVE-2020-1350 (SIGRed)
As part of Microsoft’s traditional Patch Tuesday in July, CVE-2020-1350 (codenamed “SIGRed”) was fixed and disclosed publicly. This vulnerability is very serious, with a CVSS score of 10, and allows remote unauthenticated attackers to run arbitrary code with elevated privileges.
The Vulnerability
The vulnerable component is the Windows DNS Server. Windows DNS clients and DNS servers from other manufacturers are not affected by CVE-2020-1350.
The vulnerability itself is an integer overflow in the handling of a so-called “SIG” (Signature) record. This record is an early attempt at DNS security, containing a cryptographic signature as defined in RFC2930 and RFC2931. SIG records were later abandoned and are now seen as obsolete, with some DNS servers rejecting SIG records.
The vulnerability can be exploited by tricking a DNS server into querying a malicious server (due to the recursive nature of DNS) that replies with a long SIG record. Due to specifics of DNS, the vulnerability is exploited over TCP instead of UDP, the usual transport protocol for DNS. When the vulnerability is exploited, an attacker gets Domain Admin rights, which may allow him/her to compromise a network’s infrastructure, since often DNS servers are also domain controllers.
More details about the vulnerability and its exploitation can be found here.
This vulnerability is acknowledged by Microsoft to be wormable, which means that attacks leveraging it can spread with no human interaction, although at the moment of publication no malware using it is known.
CVE-2020-1350 brings to memory two recent issues that Forescout Research Labs has analyzed: CVE-2020-0796 (SMBGhost), which is also a wormable vulnerability affecting Windows, and CVE-2020-11901 (part of Ripple20), which affects DNS clients using the Treck TCP/IP stack. It reiterates that:
- Critical vulnerabilities in Windows still happen very often, so IT equipment will continue to be a big concern in critical infrastructure and the Enterprise of Things.
- The DNS protocol is a great target for malicious actors because of the possibilities of remote exploitation.
Affected Devices
Known vulnerable versions of Windows are Server 2008, Server 2012, Server 2016, Server 2019, version 1903, version 1909, and version 2004.
To have an idea of the number of impacted servers, we looked at our Device Cloud and identified more than 7000 impacted Windows Servers with TCP port 53 open, out of almost 250000 impacted Windows Servers, or close to 3%. The table below shows the breakdown of impacted OS per vertical, where we can see that between 1% and 7.5% – depending on the vertical – of Windows Servers have TCP port 53 open, with the highest percentages in Education, Manufacturing, and Technology.
| Impacted OS and TCP port 53 open | Impacted OS but TCP port 53 not open | % Impacted OS with TCP port 53 open | |
| Education | 284 | 3483 | 7.5% |
| Manufacturing | 1133 | 26681 | 4.1% |
| Technology | 639 | 15086 | 4.1% |
| Retail | 586 | 13983 | 4.0% |
| Services | 790 | 19074 | 4.0% |
| Entertainment | 77 | 2142 | 3.5% |
| Government | 1162 | 43265 | 2.6% |
| Financial | 867 | 36630 | 2.3% |
| Utilities | 66 | 3038 | 2.1% |
| Oil and gas | 62 | 4222 | 1.4% |
| Healthcare | 606 | 56333 | 1.1% |
| Other | 747 | 18110 | 4.0% |
| TOTAL | 7019 | 242047 | 2.8% |
Mitigation – how our customers are protected
Everybody is advised to install the patch without delay. The U.S. Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive on July 16th giving federal government agencies 24 hours to patch the vulnerability.
There is an official registry-based workaround issued by Microsoft for servers that cannot be patched, as is often the case in critical infrastructure. This workaround restricts the largest allowed inbound TCP-based DNS response packet. To apply, it is necessary to change the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
DWORD = TcpReceivePacketSize
Value = 0xFF00
and reboot the system.
Below, we describe how Forescout can help to protect your network:
- Visibility: Use Forescout to identify and classify potentially impacted Windows instances in your environment. Known vulnerable versions are Server 2008, Server 2012, Server 2016, Server 2019, version 1903, version 1909, and version 2004 (for most up-to-date details see Microsoft’s security advisory).
- Control: Leverage Forescout’s ability to install the missing patch or modify the registry property detailed above to mitigate the vulnerability.
- Segmentation: As an ongoing best practice, use Forescout to monitor DNS flows over TCP port 53 – these flows should be monitored for anomalies and should be controlled via segmentation in environments with internal DNS servers. Upon detection of violation, enact device restriction policies to mitigate risk to the network and prevent lateral movement.
Besides the points above, we have developed a SilentDefense script to detect exploit attempts against CVE-2020-1350. To access this script, ask your OT account representative.
Detecting the malicious DNS message requires a lot of parsing and some publicly released detection scripts can raise false alerts because they flag every long message as malicious. Forescout’s SilentDefense script works by checking DNS traffic based on TCP port 53. The DNS Responses are inspected in detail: there should be a “SIG” (type 24) or “RRSIG” (type 46) present. If so, the “signer’s name” subfield is checked for the presence of a string pointer. If present, the first character pointed to normally gives the size of the (first part of) the string. A malicious DNS message purposely sets the pointer wrong, so that a wrong byte is used as the string size. When this value is added to the record size, and the value is > 0xFFFF, then a 16-bit addition wraparound occurs in Window, and the wrong (much too small!) amount of memory is then allocated by Windows. This may cause memory in Windows be overwritten. The script alerts when it sees the addition result >0xFFFF. No check is done on the presence of any malware in the DNS Response message.