A vulnerability called “SIGRed” (CVE-2020-1350), exploits a buffer overflow within the way that Windows DNS Servers process SIG resource record types.

Recently, Check Point researcher Sagi Tzadik published a blog post announcing a new attack against Windows DNS Servers which can allow an attacker to create Denial-of-Service conditions and possibly gain Domain Administrator access. What makes this specific vulnerability unique is that it isn’t really new it has been around for 17 years it is just that no one has discovered it until now. The vulnerability, called “SIGRed” (CVE-2020-1350), exploits a buffer overflow within the way that Windows DNS Servers process SIG resource record types.

Jump to TL;DR:

“Domain Name System (DNS) is one of the industry-standard suites of protocols that comprise TCP/IP, and together the DNS Client and DNS Server provide computer name-to-IP address mapping name resolution services to computers and users (Microsoft, 2020)”

Essentially, DNS serves as an automated phonebook. You type in the name and it gives you the phone number by mapping the domain name to the corresponding IP address. By translating names to IP addresses, DNS makes it easier for users so that we don’t have to remember all of the IP addresses of our favorite sites, just the names.

As Tzadik points out in the Check Point write up the primary information we need to know about DNS to understand this exploit are:

The SIGRed vulnerability takes advantage of the way that dns.exe handles SIG queries. A SIG resource record, now referred to as RRSIG, is utilized within DNSSEC and plays an integral role within the Public Key Infrastructure of DNSSEC. Within dns.exe’s handler function for SIG responses (dns.exe!SigWireRead) the RR_AllocateEx function expects 16-bit integers to be passed to it. If it doesn’t receive the correctly sized parameters, it will overflow the remaining integers which will cause a heap-based buffer to overwrite. Thus, if an attacker can create a DNS response that contains a SIG record that exceeds the expected 64KB we can cause a buffer overflow.

Now, as mentioned in the list above UDP responses are limited to 512 bytes so we can’t trigger this vulnerability via UDP. However, because of the way DNS is designed if a feature called “Extension Mechanisms for DNS 0” is missing then the DNS server will truncate any response that exceeds the UDP limit of 512 bytes so that the response fits within the 512-byte limit then set a TC flag in the response header. When the client receives such as response, it will take that TC flag as a cue to retry the query over TCP instead – thus we can force our target DNS server to use TCP which gives us 65,353 bytes which is unfortunately still not enough to trigger the buffer overflow.

Alright, so what do we need to do the make this work?

Taking a look at https://powerdns.org/hello-dns/basic.md.html. Tzadik references how this compression works. When the DNS server provides its response it provides the header, the original query, and the answer portion. Within the answer portion of the packet, the first two bytes are 0xc0 and 0x0c. The “c0” portion of those bytes corresponds to the domain name that was provided earlier in the packer i.e., if we are looking up assurainc.com this would reference the string’s (assurainc.com) position earlier in the packet.

That “magic” offset identified in 0xc0 is key in this attack. It identifies the 12^th position from the beginning of the packet as the beginning of the domain name. This isn’t enough to trigger the attack because the name queried is already present in the packet and won’t change the size allocation when we pass the information off to the previously mentioned RR_AllocateEx function. However, there isn’t anything that says we can’t change that pointer and use 0xc0 and 0x0d instead. What will 0x0d point to? The first character in the domain name we query. What if we provide an integer as the subdomain or our domain starts with an integer value? That integer value will be passed as the ordinal value for the size of the uncompressed string. In the video example below I used 9 as that value. In an ASCII table 9 = 0x39 in Hex and 57 in Decimal format. When we aggregate the size of the uncompressed string value with the maximum amount of data that can fit in the Signature field (<=65,535 depending on the query) this results in a value greater than 65,535 bytes, a la buffer overflow.

As seen in the video, I am running a DNS Server on a Windows Server 2019, “TEST-DC”. Off-screen I am hosting a malicious DNS Server with the domain name “sewerpeople.club” which will respond with the TC flag, forcing the target DNS Server (TEST-DC) to connect back via TCP, providing the pointer mentioned above, 0x0d. That pointer will provide the integer 9 as the ordinal value and then chaos ensues. Despite the video being short and rather unimpressive, it does demonstrate how quickly and simply the DNS server crashes when trying to process this response.

Currently, this buffer overflow has proof of concepts out that will work to cause a denial of service condition for all vulnerable Windows DNS Servers. It is well believed in the research community that given enough time this vulnerability will result in a Domain Admin level privilege escalation exploit because of the privilege level the DNS service is running at.

This exploit IS exploitable outside of the local network although it is slightly harder to do. An attacker can accomplish this by hosting a site with some simple Javascript or an Ad that will utilize DNS smuggling inside of HTTP to trigger a DNS query on the target server. An example can be seen here.

This has the potential to be a high impact attack on your infrastructure if you rely on your local Windows DNS. Luckily, Microsoft has already released a patch for the vulnerability and there is also a simple-to-implement workaround if you aren’t ready to patch.

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters” /v “TcPReceivePacketSize” /t REG_DWORD /d 0xff00 /f

THEN

net stop DNS && net start DNS

Detecting an attack like this is also paramount to your organization’s protection. Utilizing IDS/IPS and/or SIEM technologies will limit an attacker’s ability to successfully exploit this (and others) vulnerability without your knowledge. As this exploit develops into one that can provide the attacker remote Domain Administrator access this detection will become even more important.

If you’re an Assura Managed SIEM client then we are actively monitoring for your environment for this attack already. If you’re an existing Assura Customer, contract your Virtual ISO or Assura POC to provide further guidance on mitigating this attack.

Stay safe, stay healthy, and as always feel free to submit any questions you may have about this or any other cybersecurity matter through our website or to [email protected].

Sincerely,

The Assura Team