My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

PATCH NOW - SIGRed - CVE-2020-1350 - Microsoft DNS Server Vulnerability

Published: 2020-07-15. Last Updated: 2020-07-16 15:00:59 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

* THIS POST WILL BE UPDATED AS NEW INFORMATION BECOMES AVAILABLE *

Yesterday, Microsoft released a patch for CVE-2020-1350, fixing a critical vulnerability in it's DNS server. The vulnerability is 17 years old. All current versions of Microsoft's server back to 2003 are affected. The vulnerability earned a CVSS score of 10, indicating that it allows a full remote system compromise without any authentication. An exploit could likely spread without user interaction ("wormable").

A server is vulnerable if the DNS role is enabled. Note that Active Directory and Kerberos require DNS, and domain controllers usually have the DNS role enabled. This will put the domain controller at risk!

The vulnerability is triggered by an oversized DNS response containing a "SIG" record. 

The basic exploit flow would look like:

  • The attacker triggers a DNS query (for example, the victim visits a web page, or the attacker is sending an email to the victim). For a badly configured ("open recursive") name server, the attacker may just send a query to the name server directly.
  • The victim DNS server will query the attacker's name server via UDP. By default, name servers will send queries via UDP first.
  • The attacker responds with a truncated response, indicating that the response is too large for UDP.
  • The victim will now re-send the request via TCP
  • The attacker will respond with the exploit.

To trigger the exploit, the size of the response has to exceed 64kBytes. However, this does not mean that the attacker has to send more then 64kBytes (the attacker can't! DNS replies over TCP max out at 64kBytes). Instead, the attacker's response will take advantage of "pointers", to compress the response. It will be expanded (and trigger the exploit) on the victim's DNS server.

Note that some fake (prank) exploits are being advertised.

So far, one "real" PoC was released. It does not execute code but may cause the DNS server to crash. The exploit implements a simple DNS server that will respond with a truncated response to UDP queries, and an oversized SIG record if a query is sent via TCP.

Exploit: hxxps://github[.]com/maxpl0it/CVE-2020-1350-DoS [ Download at your own risk ]
PCAP collected using the exploit: https://isc.sans.edu/diaryimages/sigxploit.pcap 

zeek script to detect the exploit:

event dns_unknown_reply(c: connection, msg: dns_msg, ans: dns_answer) {
      if ( ans$qtype==24 && c$resp$size > 65000 ) {
           print "CVE-2020-1350 Exploit";
      }
}

Cisco published a rule for it's Talos/Snort subscribers (for pay only). In my experiments and as I read the rule, the rule does not work and does not look for the correct artifacts. There is an Emerging Threats rule that I have not had a chance to review.

We are monitoring for actual exploits, and expect to adjust the Infocon level to "yellow" if a working RCE exploit is released (see our Infocon page at https://isc.sans.edu/infocon.html ).

For more details, see Checkpoint's blog:

https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/

For mitigation techniques, see Microsoft's article.

https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

4 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

Possible DOS POC script.

https://github.com/maxpl0it/CVE-2020-1350-DoS/blob/master/sigred_dos.py

Can't see a Rick Roll in there.
Thanks for the analysis and webcast yesterday. There are still two aspects I cannot find definitive answers:
1) The Checkpoint exploit video shows the javascript in the browser performing multiple DNS requests, the last one being an explicit SIG request. Does it effectively needs to be a SIG request, or is it enough for the malicous DNS server to piggyback a SIG record to any response? (it's basically a signature, so I thought it should be applicable to any request...). In that case, you wouldn't need the whole browser/javascript stuff, and just include an img tag pointing to a malicious DNS domain...Why hasn't Checkpoint mentioned this much simpler attack vector?
2) What happens if the windows DNS server is using a non-windows resolver (forwarder)? Does the malformed SIG reply go through the resolver untouched, or is it validated and discarded, never reaching the vulnerable Windows DNS server?
1 - I think as long as the DNS server adds a SIG request in the answer, it will work, even if not requested. I think Checkpoint just figured that the JavaScript/Browser based exploit is cute.

2 - The forwarded will likely just pass on the response. It is a valid / well-formed response without expanding the pointers, and a forwarded won't touch/expand the pointers I think.
[quote=comment#43442]Possible DOS POC script.

https://github.com/maxpl0it/CVE-2020-1350-DoS/blob/master/sigred_dos.py

Can't see a Rick Roll in there.[/quote]

correct. At least this sends an oversized SIG response. I added a PCAP of this exploit here: https://isc.sans.edu/diaryimages/sigxploit.pcap

Diary Archives