Researcher Sago Tzadik said in a detailed blog post the vulnerability had been christened SIGRed, evoking memories of the massive hole in Microsoft's Internet Information Server in 2001 which was attacked by a worm known as Code Red.
According to Wikipedia, the Code Red worm was first discovered and researched by eEye Digital Security employees Marc Maiffret and Ryan Permeh when it exploited a vulnerability discovered by Riley Hassell. They named it Code Red because Code Red Mountain Dew was what they were drinking at the time. On 19 July that year, 359.000 hosts were hit.
The Check Point report said that the SIGRed flaw had been categorised as CVE-2020-1350 and was a wormable, critical vulnerability with a CVSS base score of 10. It affects Windows Server versions 2003 to 2019.
The vulnerability was found after Check Point decided to look for a means of compromising a Windows Domain environment, preferable without authentication.
Tzadik said some points to note were that DNS operated over UDP/TCP port 53, a single DNS message (response / query) was limited to 512 bytes in UDP and 65,535 bytes in TCP and the system was s hierarchical and decentralised in nature.
"This means when a DNS server doesn’t know the answer to a query it receives, the query is forwarded to a DNS server above it in the hierarchy. At the top of the hierarchy there are 13 root DNS servers worldwide," he explained. [A detailed explanation of how DNS works, written by the author, is here.]
Tzadik said in Windows, the DNS client and DNS server were implemented in two different modules: DNS Client – dnsapi.dll is responsible for DNS resolving and DNS Server – dns.exe was responsible for answering DNS queries on Windows Server, in which the DNS role is installed. The research focused on the dns.exe module.
Two main scenarios were considered for the attack surface: A bug in the way the DNS server parses an incoming query and a bug in the way the DNS server parses a response (answer) for a forwarded query.
Since DNS queries are simple in nature, the odds of finding parsing issues in the first scenarios were low; hence the second scenario was looked at.In order to get the Windows DNS Server to parse responses from the malicious DNS NameServer set up by the researchers, the following actions were taken:
- Configure our domain’s (deadbeef.fun) NS Records to point at our malicious DNS Server (ns1.41414141.club).
- Query the victim Windows DNS Server for NS Records of deadbeef.fun.
- The victim DNS, not yet knowing the answer for this query, forwards the query to the DNS server above it (220.127.116.11).
- The authoritative server (18.104.22.168) knows the answer, and responds that the NameServer of deadbeef.fun is ns1.41414141.club.
- The victim Windows DNS Server processes and caches this response.
- 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.
"Now that we’re able to get the victim DNS server to query our DNS server for various questions, we have effectively turned it into a client," Tzadik said. "We can make the victim DNS server ask our malicious DNS server specific types of queries, and respectively answer with matching malicious responses.
"We thought that all we needed to trigger this vulnerability was to make the victim DNS server query us for a SIG record, and answer it a SIG response with a lengthy signature (length >= 64KB). We were disappointed to find that DNS over UDP has a size limit of 512 bytes (or 4096 bytes if the server supports EDNS0). In any case, that is not enough to trigger the vulnerability."
Tzadik then set the TC (truncation) flag in his response, which caused the target Windows DNS Server to initiate a new TCP connection to the malicious NameServer, and a message larger than 4096 bytes could be passed.
He said Microsoft had requested the company to withhold information about the exploitation primitives in order to give users enough time to patch their DNS servers. "Instead, we discuss our exploitation plan as it applies to Windows Server 2012R2. However, we do believe that this plan should apply to other versions of Windows Server as well," he added.