So about this SIGRed Microsoft DNS Server vulnerability (CVE-2020-1350). Microsoft calls it "wormable".
https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/

So what would/could a worm for a vuln like this even look like? It probably wouldn't be a 'normal' worm.

A (long) thread. 1/20

Worms are self-propagating malware. Historically worms have gathered up the malware + propagation parts into one package. Propagation usually involves scanning and some exploit payload(s).

This vuln is different though. You can't send the exploit payload directly.

2/20

CVE-2020-1350 is a vuln in parsing a DNS response. A worm can't just spew DNS responses out at DNS servers. Instead malicious authoritative DNS servers must be stood up that respond to queries with maliciously crafted exploit payload responses.

3/20

A worm for this would involve several parts:

1) Registration of worm domain(s)

2) Setup of special authoritative DNS servers for those domains with the exploit payload

3) Get vulnerable MS DNS servers to query for the malicious domains

4) Malware to automate #3

4/20

The thing that makes this so interesting is that there are so many clever ways to get hosts to do DNS lookups for you. This is where worms could get really innovative and where as defenders we're going to have to think a lot about the possibilities.

5/20

The obvious first choice will simply be to scan the entire internet on UDP port 53, sending a query for one of the worm domains.

Any publicly accessible recursive MS DNS server will be exploited in under an hour.

This will happen but it has big limitations.

6/20

Many (most?) MS DNS servers aren't on public IPs or don't enable recursion (or both). The trick will be to get other hosts to send the the queries for the worm domains to the vulnerable MS DNS server for you. The options for this are nearly endless.

7/20

One very easy choice is to post http://worm.domain/ links all over the place.

Anyone that clicks (or any browser that per-fetches) will send a DNS query for worm.domain up through their (possibly vulnerable) recursive DNS resolver.

8/20

As such, one possibly way of spreading of worm propagation links would be blog/forum/article comment spam. Getting those links all over the web would be a viable propagation strategy to reach many more internal Windows DNS servers.

9/20

But there are so many other services you can co-opt into doing a DNS lookup for you. For example, SMTP servers will often do a forward lookup of your claimed name and compare it to a backward (PTR) lookup of your IP.

10/20

We could see a worm propagating by scanning the internet on TCP/25 and saying "HELO worm.domain".

Any other service that similarly accept and look up a name from an untrusted source is a potential middle-man target (exploit stooge) for a worm.

11/20

There are even crazier options too. By compromising a DNS server you can manipulate what clients using the DNS server cache. Change out the IP for a name for an attacker-controlled server and browsers could be told to cache HTML/JavaScript for long periods of time.

12/20

Now with clients caching malicious content they can be made to do lookups for the worm domains pretty regularly. Mobile clients that move between networks have the chance to bring malicious queries from a compromised network into a not-yet compromised network.

13/20

This does not require the client itself to be compromised. The caching behavior of client software alone is sufficient to make client behave in a way useful for the worm's propagation.

14/20

Of course, another option is to deliver DNS-scanning malware to the compromised DNS server itself. Since that server likely lives on an internal private network it can scan the internal addresses and laterally compromise other internal Windows DNS servers.

15/20

The web and SMTP protocol are not the only options that would work. Spam email with malicious links often flows through plenty of spam scanning infrastructure that does name lookups. Not to mention end-user mail clients or users that simply click on links.

16/20

And by "links" I don't mean <a href="... tags. <img src="... and CSS and other such options are often loaded *automatically* even by mail clients. If I can customize my "avatar" on a site to refer to an image on another site then I can get your browser to do a lookup.

17/20

Don't think that any of this would require malicious users either. Thanks to hijacking DNS clients can be made to load malicious javascript from what they think are legitimate sources which can then try XSRF tricks to store malicious worm domain names all over the place.

18/20

The one silver lining to all of this is that for the worm to work, it needs domains to be registered and hosted by malicious authoritative nameservers. That's a bottleneck that will make it much easier for defenders to block. Somewhat like the WannaCry "killswitch" domain.

19/20

Our clients will become stooges for a worm. As defenders we're going to have to be extra vigilante about finding and neutralizing these domains and authoritative nameservers as they pop up and sharing that information as rapidly as possible.

20/20