Andrew Wertkin & Farsight CEO Paul Vixie Unpack Mozart Malware & DNS over HTTPS News

It’s been a big week for tech news (and it’s not even Friday) so we brought our Chief Strategy Officer Andrew Wertkin together with Farsight CEO Paul Vixie to break down the headlines.

Check out the video or read our Cliff’s notes on their discussion below.

Mozart Malware: music to no one’s ears

In the News

First discovered by MalwareHunterTeam, Mozart is another strain of malware that leverages the inherently naïve DNS protocol. That isn’t the news though. The authors of Mozart have innovated on the way their malware abuses DNS, and created a direct line of communication between infected devices and its servers.

Instead of HTTP(S) as a transport, which is very common for malware and easily detectable by security software, Mozart uses DNS to communicate directly with its commanding server. The authors have also embedded commands in DNS TXT records, which are actions that are later carried out on the infected device. For further reading, Vitali Kremez, Head of SentinelLabs, breaks down the malware in detail on his blog.

Source: New Mozart Malware Gets Commands, Hides Traffic Using DNS by Lawrence Abrams

TL;DR

Paul Vixie: There have been plenty of botnets that have used DNS in their command and control architecture. But what Mozart is doing with TXT records today is a little bit different. […] And so it’s not quite the same as maybe making a web fetch to the command and control server. Thus disclosing to the security apparatus where that server is. This allows you to publish from anywhere and subscribe from anywhere and not really have a trail of breadcrumbs leading to the criminal’s infrastructure.

Mozart malware has circumvented established DNS resolution paths; especially harmful in an enterprise setting. Paul points out that by establishing a backdoor connection, the authors have basically made it impossible to trace anything back to them. They almost go undetected, but we’ll get into that after.

Andrew Wertkin: I think the authors were betting on the fact that people aren’t necessarily monitoring some of this stuff because it’s right there in plain sight.

Andrew shines a light on the fact that most organizations are not monitoring their DNS traffic closely. As he likes to put it, DNS is a chump and it does a great job of what it’s told to do. That is fine until an attacker uses that principle for their own purposes.

DNS Security Best Practices for Mozart and Beyond

In Bleeping Computer’s article on Mozart, our Software Security Director David Maxwell outlines a few steps enterprises can take to address the threat. “At your firewall, block outbound port 53 from everywhere except your official internal DNS server” – this virus goes directly to a fixed external IP, and while you could just block that, the next virus won’t use the same IP. Forcing all of your corporate name resolution to go through the resolvers you maintain gives you the ability to monitor traffic and control policy.”

From a best practice perspective, Andrew and Paul share what else enterprises can do to track threats on their network.

AW: A strategy that we often talk about with customers is knowing the percentage of TXT records that are queried by a Windows client, a Mac client, or something “normal” on the network during the day. And it becomes a strategy from our perspective to start looking for anything that might be an anomaly.

Solutions like BlueCat DNS Edge collect your DNS traffic data and allow for enterprises to do deeper investigations and understand their traffic.

PV: Anomaly detection is the only way that you can possibly prioritize resources. And anomalies cannot be detected if you don’t know the baseline. And so baseline counts on a certain amount of surveillance.”

Paul points out a very valuable point when deploying Andrew’s strategy. Anomaly detection is not possible if you haven’t defined what’s normal. In order to do that, enterprises need to monitor their network traffic.

Mozilla turns on DoH for US users

In the News

It finally happened. After many heated debates, Mozilla announced they are turning on DNS over HTTPS (DoH) as a default setting for US Firefox users. DoH encrypts some DNS traffic by using the HTTPS protocol. While its advocates argue that DoH will help privacy issues like ISPs monitoring your internet activity, critics argue it won’t resolve those privacy issues plus enterprises would have an even greater attack surface to tackle. (Here’s an explainer on both sides of the DoH argument.)

Source: Firefox turns on controversial new encryption on by default in the US by Jon Porter

TL;DR

AW: I see what these different players are doing and recognize that they’re implementing at least the possibility to block or to turn off or disable that service. In the case of Mozilla potentially, it seems like an afterthought and you still are relying on the informed user and the informed administrator. Or somebody needs to do something to turn off what you’ve imposed on me

Andrew’s referring to a key part of Mozilla’s news here: DoH is the default setting. Users ultimately have the choice. In an enterprise setting, the responsibility (and risk) falls on IT to manage. With the rapid pace businesses are expected to operate at, addressing DoH becomes an unwelcome challenge.

 PV: Any of us who might have had some infrastructure, some filtering, some monitoring, to maybe use the DNS to help discover these problems, and then block these results from being delivered, have been disenfranchised at precisely the moment that we needed.

Paul sheds some light on the challenge that DoH presents for enterprises. DNS data provides valuable insight for threat intelligence. Security teams risk losing part of their network visibility when DoH encrypts DNS traffic. They may not be able to detect or respond to threats with the same speed as before.

Their Recommendations

AW: For well known DNS over HTTPS providers, it’s fairly easy to block traffic to well known servers.

PV: There are a number of websites and people who have begun to collect this information. And others who want to join the project immediately go to those websites and say, “Hey, please list my service also.” And that’s because they all want to be used. And I realized that if I take that information and use it to program my firewall, that means I’m actually using their desire to be used as a way to implement my desire that they not be used.

For enterprises scrambling in the wake of DoH, Paul and Andrew agree on a very practical recommendation. Paul is referring to a public list of DoH servers. As the list grows, IT teams can use the same list to feed into their security strategy. That includes programming their firewall or blocking some servers entirely. As Paul mentions, it’s not the intended use of these lists but for corporations, mitigating this type of the risk to their business is a non-negotiable.