Risk Narrative: CVE-2020-1350 - "SIGRed"
Preface
We are providing this information as a means to simplify the technical narrative provided within Check Point's original research, in an effort to make the information easily consumable and understandable by a broader audience. It is our intent that what follows exemplifies the risk, attack vectors and steps to mitigate.
Issue
On July 14, Microsoft released a patch for a vulnerability in Window’s implementation of its DNS server. Domain Name Service (“DNS”) is the service that resolves hostnames to IP addresses. For example, when you type “www.google.com” in your web browser and hit enter, the DNS server is responsible for finding the IP address that Google wants you to use when accessing “www.google.com”. It effectively converts human readable hostnames into more computer-friendly IP addresses. The vulnerability, nicknamed “SIGRed”, has been present for 17 years in various Windows operating systems. Note, that this doesn’t mean that the vulnerability was known this entire time. Rather, retrospective examination reveals the presence of this issue dating as far back to Windows version 2003. The vulnerability was discovered by Check Point’s Research team.
The issue exists in how the Windows DNS server handles Signature Records (SIG), which is an optional DNS record type that allows for DNS query authentication and protection. In the Windows DNS server, this record can be manipulated by placing a large SIG record value that causes the Windows DNS server to improperly parse and handle the SIG record. With a specially crafted SIG record, it is possible to make the Windows DNS server overflow its heap buffer. The significance of this is that it means that it is possible to modify the memory in the Windows DNS server.
Risk
Windows DNS servers often run on Windows Domain Controllers in the context of a Domain Administrator account. This means that a successful exploitation of a vulnerable DNS service would likely result in a compromise of Domain Administrator credentials in the majority of Windows-based IT organizations.
Simplified, the compromise of the DNS server would likely lead to a complete enterprise domain compromise along with any inherent domain connected resources. As most organizations, small to enterprise, are wide adopters of Microsoft technologies, this poses a significant risk.
Microsoft considers this a “wormable” vulnerability. This indicates that there is high likelihood that this vulnerability can be weaponized to spread through chained, automated exploitation that does not require user interaction. “Wormable” vulnerabilities are the highest impact vulnerabilities because of their ease of exploitation and eventual proliferated use by botnets performing widespread exploitation on all internet-accessible systems. At the moment, there is no public exploit for this vulnerability.
According to Check Point’s Research team:
We internally found all of the primitives required to exploit this bug. Due to time constraints, we did not continue to pursue the exploitation of the bug (which includes chaining together all of the exploitation primitives), but we do believe that a determined attacker will be able to exploit it. Successful exploitation of this vulnerability would have a severe impact, as you can often find unpatched Windows Domain environments, especially Domain Controllers. In addition, some Internet Service Providers (ISPs) may even have set up their public DNS servers as WinDNS.
We strongly recommend users to patch their affected Windows DNS Servers in order to prevent the exploitation of this vulnerability.
The Threat Vectors
There are two threat vectors that organizations should be worried about:
- An external request via TCP to the Windows DNS server
- A solicitation attack which tricks a valid internal LAN user to query a malicious DNS server by clicking a link
External Request
In the event that the internal Windows DNS server is exposed to the internet on port 53/UDP (i.e. not firewalled off), an attacker can query the victim Windows DNS server directly from the internet in such a way that the victim internal DNS server will respond by querying the attacker’s external DNS server. When the victim DNS server does this, it will retrieve a response with the aforementioned SIG record modified to contain malicious content, resulting in a victim server crash or code execution.
Note that according to internet census data, there are only approximately 2000 internet exposed Windows DNS servers.
Solicitation Attack
In the event that the Windows DNS server does not have port 53/UDP exposed to the internet, an attacker can use a web browser to trigger the exploit by tricking a user inside of the target organization into clicking a link. The Windows DNS server responds to HTTP requests as if they were DNS queries, meaning that an attacker could craft a malicious web page that generated a DNS request in the victim’s browser, resulting in a similar chain of events as in the external request vector. This could be done through spear phishing, phone pre-texting, or even drive-by/watering hole exploitation. This is a much more pernicious vector and one that many organizations may not be aware of.
Remediation
Microsoft has released a patch to address this vulnerability in supported versions of Windows Server. Microsoft has recommended that every organization that runs Windows DNS servers to install the security update as soon as possible. There is also a workaround in the event that it is not possible to quickly install the security patch. The list of security patches for their respective products can be found on Microsoft’s Security Portal.
The workaround, provided by Microsoft, limits the size of TCP DNS requests, preventing the DNS query from holding enough data to create the conditions required for an effective buffer overflow exploit. The workaround requires the creation of a registry key, the details of which are included below:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
DWORD = TcpReceivePacketSize
Value = 0xFF00
Final Thoughts
This vulnerability is poised to become weaponized and start circulating within public domain. Take the necessary steps to harden your deployments and ensure adequate visibility through whatever monitoring capabilities your organization has at its ready.
Also, ensure that the fidelity of your logs is adequate. There is no worse situation than not knowing that you have a threat in your environment. So, take necessary measures. Finally, reach out to the folks at STACKTITAN if you have questions or need assistance. We are happy to help out.
References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=ALAS-2020-1350
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350