SigRed is the name given to a new highly critical "wormable" vulnerability with severity score of 10 out of 10 on the CVSS scale, that affects Windows Server versions 2003 to 2019.
While the 17-year-old remote code execution flaw (CVE-2020-1350) was dubbed 'SigRed' by the cybersecurity outfit, Check Point, who discovered the flaw in Windows DNS Server, allowing attackers to spread malicious code from one vulnerable computer to another remotely.
It could also allow an unauthenticated, and remote attacker to gain admin privileges over targeted Windows DNS servers and take complete control of an organization's IT system.
How SigRed Spreads Malicious DNS Responses
As Windows DNS server parses an incoming query or a response for forwarded query, which query happens when a DNS server cannot resolve the IP address for a given domain, it results the query to be forwarded to an authoritative DNS name server (NS).
SigRed exploit this architecture, by configuring an NS resource records to point to a malicious name server (ns1.41414141.club), and querying the target DNS server for the domain to have the latter parse responses from the name server for subsequent queries from the domain or its subdomains.
The vulnerability stems from the function for allocating memory in the resource record ("RR_AllocateEx"), which generates a bigger result than 65,535 bytes to cause integer overflow that would lead to a smaller allocation than what's expected.
And SigRed can be triggered remotely via a browser, such as IE and Edge (non-Chromium version), allowing an attacker to exploit Windows DNS servers' support for query pipelining features to "smuggle" DNS query within an HTTP request payload to a target DNS server on visiting a maliciously crafted website.
How to Mitigate against SigRed Vulnerability
All organizations using Microsoft infrastructure is at major risk, therefore it's recommended that they patch their affected Windows DNS Servers to mitigate the risk, otherwise left unpatched, the risk would result to a complete breach of the corporate network.
There is a temporary workaround, with the maximum length of a DNS message (over TCP) set to "0xFF00" to eliminate the chances of a buffer overflow, as follows:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters" /v "TcpReceivePacketSize" /t REG_DWORD /d 0xFF00 /f
net stop DNS && net start DNS
Fortunately, DNS clients ("dnsapi.dll") aren't susceptible to the flaw, as Microsoft manages different code bases for the DNS server and DNS client, and it doesn't synchronize bug patches between them.