SIGRed Windows DNS Vulnerability Hands Domain Privileges to Attackers

CVE-2020-1350 is a wormable bug in Windows DNS servers that threatens Active Directory domain controllers and network resources.

You don’t need to look any further than WannaCry or NotPetya to understand the potential harm from a wormable Windows vulnerability. SIGRed, a critical bug (CVE-2020-1350) in Windows DNS servers disclosed Tuesday by Check Point and patched by Microsoft, could be the next bug to be so-abused.

Present in Windows Server since 2003, the vulnerability can be remotely exploited to grant an attacker Local SYSTEM privileges on the DNS server. And while hacking DNS is bad enough, the common practice of running DNS from domain controllers could amplify the impact of this flaw, putting entire Active Directory environments at risk and consequently every network resource accessible via AD.

Exploit Likelihood is High

As Check Point explained, an attacker could use a phishing email to link to an exploit that would send a large TCP DNS request to an unpatched server over port 53. The request would be crafted in such a way that it would trigger a heap-based integer buffer overflow within the DNS server executable; the DNS client is not affected by this vulnerability. The malicious DNS query would ultimately allow the attacker to remotely execute code of their choice with SYSTEM level privileges without the need to authenticate to the server.

“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,” Check Point said in its advisory. The company said it did not develop an exploit, which would require chaining a number of “exploitation primitives” in order to successfully attack the bug.

“We do believe that a determined attacker will be able to exploit it,” Check Point said. “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.”

An assessment of SigRed by QOMPLX suggests that the primary targets of attacks on SigRed will be outwardly facing DNS servers that parse incoming DNS queries from known and unknown sources, and which may also respond to forwarded DNS queries. The most vulnerable of these will be the external, forwarding servers in an environment. Internal servers also must be patched, but are not as critical if time and manpower are at a premium.

DNS must be configured properly within the Active Directory environment in order to ensure proper name resolution and minimize security risks. While public-facing DNS servers are a rarity because most use respected public providers for DNS forwarding, some less-mature organizations may use this risky configuration. One expert quoted in a Wired article about SIGRed said that since the start of the COVID-19 pandemic, some organizations have opted for architectural changes to their networks to support rising numbers of remote workers, simultaneously expanding their exposure to remote attackers.

Successful Exploits Enable Highest Privilege Levels

CVE-2020-1350 is rated a “critical” vulnerability because of its potential impact on domain controllers hosting DNS server implementations. DNS servers run on domain controllers very frequently, and special priority should be given to evaluation and patching of this vulnerability. A successful exploit will drop an attacker onto a DNS server at the highest privilege level: local SYSTEM.

With those privileges, an attacker would have access to anything running on the server, and would have the ability to extract information from memory, dump password hashes, access data over the wire, and file systems; there is no higher privilege level.

An attacker with admin privileges on a domain controller may then use a number of freely available tools such as Mimikatz and Rubeus to launch secondary attacks that would allow lateral movement on the network and privilege escalation.

Some, such as Golden Ticket and Silver Ticket attacks, expose every service on a domain, or a single service, respectively. Other attacks such as Kerberoasting, DCSync, or Pass-the-Ticket, allow threat actors to steal legitimate service account credentials or service tickets that are passed between services for privileged access.

DNS Security Often Overlooked

Domain Name System (DNS) security has long been identified as a sore spot for enterprises and consumers.

For consumers, cyber criminal gangs have been spotted compromising home routers and modifying embedded DNS software on them to redirect users from legitimate websites to malicious, clone websites that they control.

For enterprises, DNS is a critical component of network operations. But DNS servers are often low priorities for IT teams. Hackers have taken notice. A 2017 survey by the firm EfficientIP found that 76% of organizations have been subjected to a DNS attack in the previous year and that 32% of those suffered data theft. DNS infrastructure is vulnerable to a variety of threats including malware, denial of service attacks, as well as DNS cache poisoning and DNS tunnelling attacks, in which DNS is used to exfiltrate data from sensitive organizations.

QOMPLX can Help

QOMPLX’s technology, such as its Identity Assurance platform, can help harden Active Directory against attack by maintaining a stateful ledger of valid Kerberos tickets and interactions across domain controllers, Kerberos-enabled services, and clients.

It can verify, in near real-time, that a given Kerberos authentication event was correctly generated, that it is linked to legitimate user interactions and the issuing domain controller. This type of deterministic verification makes it difficult for attackers to abuse authentication protocols and processes.

Further, as Active Directory attacks expand in severity via Golden Ticket and Silver Ticket attacks, there must be external validation of the Kerberos protocol to assure that every ticket presented by a Kerberos service client was in fact issued by a legitimate key distribution center.