CVE 2020-1350 Analysis of Windows DNS Server RCE Vulnerability

A customer recently came to Telesoft to request further visibility of their DNS traffic to help them detect attackers trying to exploit CVE-2020-1350, a Windows DNS Server remote code execution vulnerability which has earned a CVSS of 10.0 due to being “wormable” and affecting versions as far back as 2003, all the way to 2019.

The vulnerability allows threat actors to take advantage of how Windows DNS Servers passes incoming and forwarded DNS queries by using malicious custom DNS requests. If done correctly this will trigger a Heap-Based Buffer Overflow, where data surpasses the capacity of the memory buffer leading to programs resorting to overwriting other adjacent memory locations. This can potentially damage and expose private data which threat actors can exploit by overwriting data in the buffer or divert pointers to execute malicious code.

The root of the exposed vulnerability is due to programming languages C and C++ being sensitive to buffer overflows as they don’t contain safeguards to prevent overwriting or access to data in memory, and since Windows uses C and C++ such attacks have occurred.

Due to most enterprises using Domain Controllers (DC) that not only house the DNS but also the Active Directory (AD), should the DNS become compromised, the threat actor will have complete access to the entire network infrastructure. Additionally, Domain Administrator rights enables the threat actor to manipulate and hijack traffic such as emails, VPNs, DNS records and high-level domain accounts.

While Microsoft has provided a workaround, the solution carries a negative impact as it has the potential of dropping genuine DNS requests and the CSP had limited capability to understand what the threat landscape looks like and to see where this type of attack might be coming from.

By monitoring and understanding the DNS traffic, it became clear they needed additional visibility to see the DNS length, DNS truncated and DNS record length fields to allow our customers to triage events.

In order for this exploit to be effective, the malicious DNS server would need to force the victim Microsoft DNS server to switch from UDP to TCP. Whilst this will happen routinely for legitimate reasons, we soon discovered peaks of such activity could be identified during scanning/exploitation, which should help our customer to find the malicious domains.

Telesoft engineering teams worked with our customer to understand what was needed and quickly implement the changes into the platform within days of the request coming in.

Within 48 hours, three new records had been introduced into the FlowProbe:

dnsRecordDataLength
dnsTruncated
dnsResponseName

With this new information being extracted, the customer was able to start creating new searches, which in turn enabled them to start detecting misuse of their DNS platform, such as tunnelling via resolvers.

Additionally, we created and released a SNORT rule for Intrusion Detection Systems which provides an alert on any flow meeting the suspicious traffic criteria and provides the SOC analysts with a PCAP of the data surrounding that alert.

CERNE Rule:

alert tcp-stream any 53 -> any any (msg:”CVE-2020-1350-DoS”;flow:established,to_client;content:”|ff|”;offset:0;depth:1;classtype:denial-of-service;sid:123456;rev:1;)

The additional fields can be seen populated within the record below.

The customer now has greater DNS visibility to help them detect the vulnerability, and provide further analysis into this threat vector.

If you would like to find out more about the FlowProbe or TDAC, please request a demo or contact us on sales@telesoft-technologies.com.

 PCAP INVESTIGATION OVERVIEW

Scenario 

In order for a threat actor to exploit CVE-2020-1350 it requires a victim DNS Server such as those ones found within an organisation to query it’s malicious DNS server. This is done via adding a NS (Name Server) record which indicates which DNS Server manages a domain, for which in this exploit the malicious DNS server will be authoritarian for this domain, and through means for example like phishing tactics, deceive users into clicking links that will trigger it’s victim DNS Server to resolve the domain via the malicious DNS Server. And once the victim DNS Server queries the malicious DNS Server, threat actors can commence responding with the malicious payload:

Suspicious Packet 1 (Responding to victim DNS request)

Suspicious Packet 2 (Malicious DNS reply)

Example script of the pointer within the ‘Signers Name’ field and arbitrarily generated code in the ‘Signature’ field to reach payload capacity

PCAP’s and Python Script curtesy of @maxpl0it