Credit: Dreamstime
Remote code execution vulnerabilities that affect the core networking components of operating systems are rare these days, but when they happen, the IT industry is put on alert because they are among the most dangerous flaws that can lead to the mass exploitation of computer systems around the world.
On Tuesday, Microsoft released a patch for such a vulnerability that affects its implementation of the Domain Name System (DNS) server on Windows and urged organisations to deploy the fix as soon as possible.
A wormable remote code execution
The vulnerability, tracked as CVE-2020-1350, was discovered by researchers from Check Point Software Technologies, who dubbed it SIGRed, a play on the vulnerable function name that handles DNS SIG queries. The flaw received the maximum CVSS severity score of 10, making it critical, and according to Microsoft, it's wormable.
"Wormable vulnerabilities have the potential to spread via malware between vulnerable computers without user interaction," the Microsoft security team said in a blog post. "Windows DNS Server is a core networking component. While this vulnerability is not currently known to be used in active attacks, it is essential that customers apply Windows updates to address this vulnerability as soon as possible."
It's worth noting that this vulnerability does not affect the Windows DNS client component that is used to query DNS servers, but the server component which answers DNS queries. Because of this the flaw affects all versions of Windows Server starting with 2008 that have the DNS role installed but does not affect the desktop versions of Windows.
Not all Windows servers are configured to act as DNS servers, but Windows domain controllers usually do, and they sit at the core of Windows networks.
An attacker who successfully exploits the SIGRed vulnerability can run arbitrary code in the context of the LocalSystem Account, giving them full control over the affected system. If those systems are domain controllers, the impact extends to the whole network.
How does the SIGRed vulnerability work?
SIGred stems from an error in the function that parses DNS responses for SIG-type queries, resulting in a heap-based buffer overflow. The DNS protocol is generally used to translate domain names into IP addresses, which is known as an A record.
However, the protocol also supports other record types, such as MX which defines the server designated to handle email or NS which defines the authoritative DNS servers a domain. SIG is a record type that's used to provide a signature associated with the domain for certain functionality.
In addition to responding to queries from clients, DNS servers also act as clients themselves, because if they don't have a locally cached answer to a query, they ask servers higher up in the chain of authority. The DNS is a hierarchical system with 13 root DNS servers at the top that serve the entire internet.
To exploit the vulnerability, the Check Point researchers needed a way to force the targeted DNS server to forward a query received from a client to a DNS server they controlled so they could respond with a malformed packet back to the local server that would exploit the vulnerability.
They achieved this by first forcing the target server to cache an NS record for a domain they controlled and then by sending another query for a subdomain of that domain. This caused the local server to forward the subdomain query to the DNS server specified in the domain's NS record which is considered authoritative. Since they controlled that authoritative DNS server, they were able to respond with the exploit.
Getting the exploit to work took additional effort, because they also needed to find a way to send responses that were larger than what the DNS standard normally allows to trigger the overflow.
For attacks from outside LANs, they also needed a way to force a local computer on the same network as the targeted DNS server to send queries to it. It turned out this can be achieved by tricking a user to visit a specifically crafted website in Internet Explorer or Microsoft Edge (non-Chromium version) because DNS queries can be "smuggled" in HTTP POST data.
A complete attack chain would look like this:
- The attacker gains access to a system on the local network or tricks a local network user to visit a specially crafted Web page with IE or Edge
- The attacker sends an NS query to the local DNS server for a domain they control, either directly from inside the network or through the victim's browser. The local DNS server caches the NS record
- The attacker sends another query, this time for a SIG record for a subdomain on the attacker's domain. The local DNS server queries the authoritative DNS server specified in the cached NS record
- The attacker controls the authoritative DNS server for the domain, allowing them to return a malicious DNS response that exploits the vulnerability
The Check Point researchers published a detailed technical write-up of the entire process, but withheld details about bypassing certain memory protections on Windows, which is a required step to actually turn the overflow into code execution.
"We believe that the likelihood of this vulnerability being exploited is high, as we internally found all of the primitives required to exploit this bug," the researchers said in their blog post. "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."
Mitigations for SIGRed
Organisations are advised to install the security patch released by Microsoft as soon as possible. If they can't update their systems immediately, they can apply a registry workaround manually.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
DWORD = TcpReceivePacketSize
Value = 0xFF00
The DNS service needs to be restarted after this registry modification for it to take effect.
