The 17-year-old DNS vulnerability that leads to RCE in Windows

Previously on our blog, we unpacked vulnerabilities in web applications, firewalls, SMB protocols… and now we have a DNS one.

This is proof that each service, network protocol, and application is susceptible to attack.

As long as a device is connected to the Internet, it becomes a potential target. (Even those that aren’t online can be abused using data exfiltration techniques focused on hardware vibrations, but that’s a topic for another day.)

So, let’s switch gears back to our main topic of today: CVE-2020-1350 (also called SIGRed), a high-risk vulnerability found in Windows DNS Server that can lead to Remote Code Execution, or – even worse – to full infrastructure compromise.

Are you ready to get down to the nitty-gritty?

Vulnerability Overview

This big (or even huge!) security problem was found in the Windows DNS Server protocol. Its concept is very similar to SMBGhost (which you can chain to SMBleed using our technical walkthrough).

It received the highest CVSS possible – 10/10 – because of two factors:

• this vulnerability can lead to Remote Code Execution, which raises its impact to critical levels

• and also its exploitation complexity is somewhere at easy to medium.

The fact that it stayed under the radar for over 17 years makes the situation much worse.

Since its disclosure, cybercriminals started abusing it in the wild as expected.

What’s the story behind the “SIGRed” name?

The “SIG” in the name comes from “Signature record”, a type of DNS used to carry different details, including the crypto-algorithm of the signature, the signer name, expiration time, and much more about a specific DNS query sent by the client. The “Red” in the name is a reference to the fact that this issue is a critical one.

Remember the resemblance to SMBGhost? This vuln also has something in common with the famous EternalBlue. And it’s a very simple aspect: buffer overflows in Windows-related network protocols.

Originally, SIGRed is a buffer overflow through a DNS query with an over-exceeding SIG flag value when interpreted by the Windows DNS Server.

Affected versions

You can find this flaw in every unpatched version of Windows Server from 2003 to 2019. Ouch.

Technical Aspects

Most fingers are pointing towards the guilty “SigWireRead” function within the Windows DNS Server implementation, respectively the “dns.exe” process. This function is responsible for interpreting the SIG and RRSIG values from a DNS query.

The SigWireRead function has a sub-function called “RR_AllocateEx” which allocates memory for the SIG and RRSIG values, and passes this allocated memory’s address through memcpy, a function related commonly with heap-based buffer overflows.

By sending a DNS response from the client with a SIG/RRSIG value greater than 64KB, you can trigger a controlled buffer overflow, which ultimately can result in service crashing (Denial-of-Service), or – even worse – Remote Code Execution.

Impact

If (when?) exploited, this vulnerability can get you a VIP ticket to the Remote Code Execution train with the destination of Windows Server. Be careful, that the ones that get there are called “Domain Admins”!

Windows DNS Server is a core component of each Windows-based environment and it’s also commonly used within Active Directory. Besides, the vulnerability was tagged as “wormable”, meaning that, after exploitation, the attacker can perform lateral and vertical movements through your network, leading to a potential full compromise.

At the time of writing, there were about 23,244 possible vulnerable targets registered through Shodan.

You can try yourself to search and find potential targets for educational purposes, starting from this basic Shodan query: port:53 “Microsoft DNS”.

Exploit Overview

At the time of writing the article, the only exploit you could find available so far was a DoS one on GitHub, which abuses the SIGRed vulnerability to crash the DNS service.

The exploitation principle is that it takes advantage of the way the DNS Server parses the response for a forwarded SIG-tagged (or RRSIG) query.

Using the Python script from Github, you can host your own malicious domain, and after that, it will work as following:

1. From the attacker’s machine, send a SIG-records DNS query for the malicious domain through the vulnerable DNS server using this command: nslookup -type=sig {subdomain.attacker_domain} {vulnerable server IP}

2. The vulnerable DNS server will ask a public DNS server about the nameservers for your malicious domain

3. The nameservers for the attacker’s DNS server are returned to the vulnerable Windows DNS Server

4. The vulnerable DNS will act as a client and forward the initial SIG request query to the Attacker’s DNS Server

5. Through our script, the malicious DNS Server will respond with a malicious SIG value, crafted to produce a buffer overflow and crash the DNS service on the victim server.

How to fix CVE-2020-1350

The best practice would be to patch immediately, and you can do this in two ways:

1. Bring the machine online and check for Windows updates (if not installed automatically)

2. Download the update manually using this link.

If you can’t patch the server, there’s a registry-based workaround (not recommended, but still better than nothing):

After you add that into your Windows Registry, open CMD as an administrator and enter the following commands to restart DNS Service:

Given SIGRed’s nature and prevalence, we expect we’ll be updating this article with new exploits or essential details, so make sure to bookmark it if you plan on keeping an eye on the situation.