Threat Hunting for CVE-2020-1350: Microsoft DNS Server Vulnerability
By now most security professionals have heard about the vulnerability in Microsoft’s DNS server implementation that exists in versions going back to Microsoft Windows Server 2003 up to and including Windows Microsoft Server 2019 (CVE: 2020-1350). Microsoft has given this vulnerability a CVSS score of 10, indicating a very severe bug: successful exploitation leads to complete compromise of the Active Directory (AD) environment. Specifically, the remote code execution (RCE) on the domain controller (DC) can lead to a full-scale compromise of the entire network, since all machines which are members of the compromised domain are now vulnerable. We often see attempts to exploit this now 5 month+ old vulnerability so in this blog we describe how the exploit works and how to hunt for this threat in the environment.
The setup shown in Figure 1 ensures that our malicious DNS server is able to communicate directly to the victim DNS server. For the vulnerability to be exploited:
- The DNS server must parse an incoming query, or
- The DNS server must parse a response (answer) for a forwarded query.
Since the former is harder to control, we focused on creating a scenario for the latter.
In this diagram:
- The Windows Server shown in red is controlled by the attacker.
- The name server labeled “ns1.example.com” (also in red) is a malicious DNS server.
- The victim DNS server is shown in pink.
- The green DNS server represents any global DNS server – we used 220.127.116.11.
Figure 1 is a pictorial representation of the lab environment we used to reproduce the attack. The steps needed to exploit this vulnerability are:
- Create a domain (example.com) and configure the NS record for this domain to point to our malicious DNS server: ns1.example.com. This DNS record must be published to a global DNS server–18.104.22.168 in our lab set up–so that it is then accessible to the victim DNS server.
- Query the victim DNS server for example.com. Since the victim DNS server does not hold any records for this domain, it forwards the query to a public DNS server (22.214.171.124 in this case)
- 126.96.36.199 resolves and returns a valid NS record for ns1.example.com.
- The victim DNS receives the response – ns1.example.com. This also causes the response to be cached.
- Now, if we query again for perhaps a sub-domain of example.com, the victim DNS server finds an NS record in the cache and forwards the request, and receives a response from our malicious DNS server (DNS Cache Poisoning). This allows the vulnerability to be exploited.
The vulnerability in question exists within dns.exe – the binary responsible for processing DNS queries on Windows Servers with the DNS role installed. Exploitation involves overflowing the heap by sending a large volume of data as a SIG response from the attacker’s DNS Server to the victim’s DNS Server. This data is read by dns.exe which in turn leads to the attacker achieving RCE.
Since DNS primarily communicates over UDP, packet sizes are limited to 4 KB at the maximum, This packet size is insufficient to overflow the heap. However, the workaround for this is simply sending a TC (Truncate) flag, over UDP as the response header from the attacking name server to the victim. This causes the victim to listen for additional data over a TCP connection. The victim DNS Server then receives a large packet with more than 64KB of data and this leads to a heap overflow.
Exploitation occurs in the following manner –
- The DNS service cannot parse the length of a SIG packet above the constrained size of the buffer. Hence, sending it a size above 0xFF00(64 K bytes) leads to an integer overflow.
- This in turn leads to a heap overflow since the SIG data is greater than 64KB.
- The heap overflow allows the attacker to corrupt memory and control system registers and thus achieve RCE.
OS Level security protocols provided by Microsoft such as Control Flow Guard (CFG), an extension to Data Execution Prevention (DEP), are intended to prevent such execution of shellcode. But these can be easily circumvented using techniques such as ROP gadget chaining and the infamous Write-What-Where technique.
Moreover, since the vulnerable executable, dns.exe, is a Microsoft signed binary, the control flow across functions in the code can be reverse-engineered using publicly available debug symbols. This simplifies the exploit development process.
Figure 2: PCAP Analysis of CVE-2020-1350 exploit
IDS engines like SNORT struggle to detect threats like this since they are forced to work at the raw packet level. On the other hand, since the Awake Security Platform processes the full packet and then runs analytics to surface artifacts and activities at the protocol level (DNS in this case), any analyst can build a model to identify the threat very easily.
Using the Awake Security Platform, we are able to fingerprint the specific type of DNS Resource Record (RR), in this case matching the value 24 which refers to DNS SIG records. The model also validates the payload length exceeds 64K bytes, which as discussed above is the size necessary to trigger the vulnerability. Finally, since we know that during t./he attack communication shifts from UDP to TCP, we also add that check.
Moreover, the detection model is just the beginning. The platform automatically creates a Situation that reconstructs the entire attack sequence as shown in Figure 4. This Situation not only displays the devices in question but also the flow of the traffic.
Figure 3: Awake Security detection of CVE-2020-1350
The platform’s underlying full packet capture engine makes it easy to find the custom shellcode included within the packet and illustrated in Figure 5. The Awake platform detects this in a proactive manner and presents the payload to the analysts for further investigation.
Figure ˙4: Awake Security detection of injected shellcode
Microsoft released a patch to mitigate this vulnerability (SIGRed) over the summer of 2020 and organizations with Windows DNS servers are strongly advised to apply this update. In addition, Microsoft recommends the following registry change to restrict the size of the largest inbound TCP-based DNS response packet allowed. This workaround provides mitigation for those not able to apply the patch.
Value = 0xFF00
Dig Deeper with These Resources
Awake Security 2 Minute Explainer Video
What if security could think? What if it could sense danger, calculate risk, and react quickly based…
The Internet’s New Arms Dealers: Malicious Domain Registrars
This report dives into the results of a multi-month investigation that uncovered a massive global surveillance campaign…