More than four years ago, I wrote an in-depth article for Security Week describing Domain Name System (DNS) tunneling and signaling, and their uses for malware and other malicious activities, along with some sound advice on how to deal with them. That was of course prior to having an excellent solution for the problem like the Infoblox Threat Insight service to ferret out such abuses automatically.
There was an important issue, though, that I left out of that article, and the research done by the Infoblox cyberintelligence team and the engineering group working on Threat Insight have brought this problem to the fore of late. In examining apparent DNS tunneling/signaling traffic on customer networks, we repeatedly run into anomalous traffic that looks like a harmful activity but is, in fact, intentionally being sent by services and users on those customer networks and is by and large not malicious.
Let me pause here to give some background. The Domain Name System was introduced in 1983 to translate names—easily understood by humans—such as www.infoblox.com, into IP addresses—easily understood by computers—such as 161.47.10.70. DNS queries are typically very small data packets and are NOT intended to transport any data beyond that required to perform name-resolution services. Note that this has changed a bit over the years with the introduction of authentication mechanisms such as DNSSEC and DKIM; however, these purposes are still serving up information about the domain name itself, not transporting other data.
However, the DNS protocol is flexible enough that unrelated data can be inserted in a DNS query and sent into or out from a targeted network. In its simplest form, this is called DNS signaling—where information is encoded into query strings or in response records, typically using a cryptographic hash function. Since DNS packets are so small, this may mean a lot of packets are needed for just a little real data, so performance is quite slow. DNS tunneling takes this even further by using DNS queries to encode other protocols (like http, ftp, smtp, or even custom ones) over a DNS session. This is done via the same basic techniques you use to encode other transmissions: for instance, as you do to set up a VPN network. Infoblox Threat Insight detects both of these methodologies, and for simplicity, we lump these techniques together under the moniker of DNS tunneling that is most familiar to the marketplace.
Malicious DNS tunneling is a big problem in cybersecurity, as documented in the Infoblox Security Assessment Report for the second quarter of 2016, which we published today.
Security and networking teams fighting malicious DNS tunneling usually are unaware of the “creative” use of the DNS for non-malicious communications, potentially triggering a lot of false alarms.
Why is this? Well, because these “legitimate” users of DNS tunneling aren’t really abusing the networks they are running on and are merely taking creative shortcuts to power their solutions. Most companies utilizing these techniques don’t advertise their unsanctioned and unwise use of the DNS. This creates a real challenge for network defenders looking for bad guys using DNS for malware command and control or data exfiltration, since those activities look nearly identical to non-malicious services that misuse the DNS.
What kind of activities are we talking about? Well, things got started back in the 1990s when some enterprising yet penny-pinching folks decided to help themselves to free Internet access at hotels, airports, etc. These folks noticed that while they were blocked by pay walls from accessing the Internet directly via standard protocols such as HTTP, DNS wasn’t blocked, ostensibly to allow names to resolve so you could pay! After hacking some code together, tools like NSTX, DNScat, and iodine were released over subsequent years to allow you to tunnel your web sessions and eventually other protocols like e-mail through your DNS connection. A bit slow, but it worked, and was “free.” These have evolved to provide full VPN services over DNS, and dozens of such tools exist and are freely available today on Github and elsewhere.
So beyond the obvious theft-of-service concerns, why is DNS tunneling such a bad idea—in particular for corporate networks? Besides the false alarm already described, use of DNS for data transport is, by definition, knowingly misusing the protocol to intentionally circumvent a measure put in place by the network operator.
This could be something as relatively benign as proxying past workplace productivity filters that may be blocking Facebook or personal e-mail services, to something more sinister that could put the company at risk. Employees accessing illegal content, malware communicating with command-and-control services, and a host of other activities are just the tip of the iceberg.
It’s not just tunnels that are problems though—plenty of bad guys use DNS for “signaling,” where a formal “tunnel” for another protocol isn’t set up. This is often the case for advanced persistent threat (APT) scenarios where data is exfiltrated low and slow, as well as botnet command and control. The fact that DNS is a horrible transport mechanism due to its speed and capacity limitations isn’t a problem for the bad guys in these scenarios.
However, it turns out a lot of commercial products also use DNS signaling to provide quasi-legitimate data transfer services. Around the time DNS tunnels were taking off, some manufacturers of customer presence equipment (CPE) devices were having problems getting updates out to their various consumer-grade cable and DSL modems or Wi-Fi routers and other gear on consumer and SMB networks.
Turns out the ISPs were inconsistent on allowing various types of traffic through, and getting people to set up proper connections through their NAT-based routers was really hard. Ah, but DNS provides a slick mechanism for that, and before long, you had companies performing software updates and other maintenance tasks with their installed base through DNS.
While most enterprise-grade network gear uses proper communications and authentication channels for handling these tasks, internal departments and branch offices often have cheaper CPE gear, so even in a full-blown enterprise network, these signals are being passed around in the DNS.
Some anti-virus (A/V) vendors got on the DNS bandwagon for similar reasons, and with a need to do nearly continuous communications, this problem is very noticeable. Some A/V vendors have set up file hash identification routines via the DNS—if you look up a hash value for a suspect file via a hostname under a domain run by that A/V company, you’ll get an answer back telling you whether it’s infected or not. Pretty slick, but again, you’re creating a communications channel using the wrong protocol and potentially opening up your network to malicious communications. Don’t forget, more than one A/V product has been infected by malware.
There are many other product and service categories that have had one or more companies turn to DNS tunneling for similar reasons. Heck, our teams even identified systems doing network time updates over DNS via signaling rather than via NTP, even though NTP is actually designed for this and runs over UDP just like DNS!
Ideally, companies needing to do updates and other approved data transfers to their millions of devices would use a well-established channel like HTTPS. If the needs are too specific or unsuitable for HTTPS, they should work with the Internet Engineering Task Force (IETF) to designate a proper protocol and/or method for these types of services, even though that takes time and expense while, of course, the DNS is free.
At the end of the day, the big problem with these techniques is that they are circumventing controls put in place by the team operating that network. There are many reasons for such controls, and circumventing them opens up security, compliance, and operational concerns, while overloading the DNS protocol and anomaly detection systems examining DNS traffic. Worse still, these companies are typically doing so without disclosure or configuration options to disable their misuse of the DNS.
While it’s doubtful everyone will stop, we would like to see IT vendors refrain from continuing this practice, as it makes the job of securing DNS that much harder. These days, more and more organizations are trying to protect DNS and are starting to realize how much of this “garbage” DNS traffic is actually running on their networks.
Perhaps concerted action to block such traffic may dissuade manufacturers from relying on it, but that may be a heavier lift if you have an installed base relying on that misbehaving gear.