Microsoft patches critical wormable SigRed bug in Windows DNS Server

A critical vulnerability that’s been sitting in Microsoft’s Windows DNS Server for almost two decades could be exploited to gain Domain Administrator privileges and compromise the entire corporate infrastructure behind it.

The vulnerability received the tracking identifier CVE-2020-1350 and the name SIGRed. It is a remote code execution that affects Windows Server versions 2003 through 2019 and received the maximum severity rating, 10 out of 10.

It is wormable, meaning that an exploit can propagate automatically to vulnerable machines on the network with no user interaction. This characteristic puts it in the same risk category as EternalBlue in Server Message Block (SMB) and BlueKeep in the Remote Desktop Protocol (RDP).

Malformed DNS package

The Domain Name System (DNS) is the internet’s phone book, enabling clients to connect to servers to access resources. It is a model that maps domain names to IP addresses to enable a connection to the correct server.

The model is hierarchical and decentralized, so if a DNS server will forward up the ladder the queries to which it does not have an answer. At the top of the hierarchy are 13 root DNS servers that have all the information.

Researchers at Check Point discovered a flaw in Microsoft’s DNS implementation that can be exploited when the server parses an incoming query or a response for a forwarded request.

They found an integer overflow that leads to heap-based buffer overflow in “dns.exe!SigWireRead,” the function that parses response types for SIG queries.

In a technical blog today, the researchers detail how they were able to exploit the flaw in a target DNS server by replying to one of its queries with a SIG response large enough to trigger the bug.

To make the target Windows DNS Server parse responses from their machine, the researchers did the following:

1. Configure our domain’s (deadbeef.fun) NS Records to point at our malicious DNS Server (ns1.41414141.club)
2. Query the victim Windows DNS Server for NS Records of deadbeef.fun
3. The victim DNS, not yet knowing the answer for this query, forwards the query to the DNS server above it (8.8.8.8)
4. The authoritative server (8.8.8.8) knows the answer, and responds that the NameServer of deadbeef.fun is ns1.41414141.club
5. The victim Windows DNS Server processes and caches this response
6. The next time we query for a subdomain of deadbeef.fun, the target Windows DNS Server will also query ns1.41414141.club for its response, as it is the NameServer for this domain.

The researchers found that a threat actor exploiting SIGRed does not have to be on the same network as the target DNS server, since DNS data can be carried over a TCP connection, supported by Windows DNS.

As such, the target server will parse the data as a DNS query even it is packaged as an HTTP payload.

Check Point notes that because Windows DNS server supports “Connection Reuse” and “Pipelining,” an attacker can launch several queries over a TCP connection without having to wait for a reply.

These features allow sending to the server an HTTP POST request with binary data that has another DNS query in the POST data, to be processed separately.

This is possible even in browsers, such as as Internet Explorer and Microsoft Edge that allow requests to port 53 used by DNS. Google Chrome and Mozilla Firefox do not allow HTTP requests to this port.

Check Point illustrates using a browser as a vector to crash an internal Windows DNS server in the video below.

Vulnerability existed for 17 years

The vulnerability has existed in Microsoft’s code for more than 17 years. If researchers found it, Omri Herscovici, Check Point’s Vulnerability Research Team Leader, says that it is not far fetched to assume that other actors may have found it as well.

This is sufficient incentive for organizations big and small to prioritize applying the patches Microsoft released today for SIGRed.

For those that cannot apply the patch at this time, Microsoft recommends modifying the registry to mitigate the issue. The change takes effect after restarting the DNS service:

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

After applying the patch, admins should revert the changes to the original state by removing the value TcpReceivePacketSize and its data.