DNS is probably the second most misunderstood protocol (the first being the control protocol du network), and that needs to change. I can’t claim to be anything close to a DNS expert, but am known to do neat tricks with it now and then.
A few years back I was lucky enough to catch Dan Kaminsky present at ToorCon on IP-over-DNS tunneling, which planted a seed with me about general protocol tunneling. He had just tinkered with doing DNS queries over SSH, itself tunneled over DNS (and proceeded to chug a cup filled with Cinnamon Toast Crunch and Mickey’s to celebrate, IIRC).
The technique is actually much older, and dates back to the late 90s/early 2000s, when hacker-types would dial-in to Microsoft PPP servers (normally used for software registration), and would tunnel to the Internet using the technique.
DNS can be a bit complicated, but there are some basic principles that should be understood about DNS where security is concerned.
Let’s take digitalbond.com. If you are reading this, you entered www.digitalbond.com into your web browser. Your web browser, in turn, had to figure out what IP address www.digitalbond.com belonged to.
To do that, your web browser first contacted your local DNS server. This DNS server probably had our www.digitalbond.com cached (we’re Digital Bond, after all). In the unlikely event that it did not have us cached, it would first try to figure out what DNS server was responsible for resolving digitalbond.com domains. You can do this yourself via a Unix command line with the command ‘host -t ns digitalbond.com’. On Windows, you would do this with the command ‘nslookup -querytype=ns digitalbond.com’.
This will give you a list of namservers responsible for resolving hosts within the digitalbond.com domain. Your local DNS server will then contact these nameservers in their listed order to figure out the IP address that belongs to ‘www’ in our domain to get you to www.digitalbond.com.
In our case, our nameservers are ns3151.dns.dyn.com, ns2137.dns.dyn.com, ns1128.dns.dyn.com, and ns4132.dns.dyn.com. Your local DNS server will then ask each of these servers what IP www.digitalbond.com is associated with. If the first query gets an answer, voilla, your local DNS server is done. If none of the four respond, your browser will show a cryptic error about host resolution.
The trick is that you generated some data: a request for ‘www’, and this exact request was sent, eventually, to dyn.com. Some arbitrary response, an IP address, came back.
DNS over IP tunneling works exactly like this, except that the hostname is something completely nonsensical-looking. So is the response. If digitalbond.com ran an IP-over-DNS tunnel, you’d see requests for hosts like qezxcvl239817lzkjcvzlq23.digitalbond.com, with a response of “Oh yeah, that’s at <some address> and by the way here’s some padding SLksdflzxjzlsalfwelakjczvnvvawe”. The domain being resolved and response provided are both just encoded IP traffic (which could be anything, TCP, UDP, other).
Blocking IP over DNS tunneling is easy on a control network — the control network shouldn’t need DNS at all, except for host resolution of local systems (and if it does need to resolve Internet-served names, sit down and have a tough conversation with your vendor about what, exactly, they mean when they say, “don’t plug our stuff in to the Internet”). Anything contacting the Internet and truly requiring DNS could be moved to a DMZ — it doesn’t belong on a control systems network.
Blocking it on commercial and corporate networks is trickier — I have yet to find a commercial product that can stop the technique while guaranteeing that it won’t interfere with normal users. Detecting it would be fairly easy: a flood of requests for various records on a single domain would be issued, and the flood could be stopped if not at least detected and alarmed upon. GoGo InFlight wireless, for example, appears to block IP-over-DNS tunneling, but only for users that haven’t paid yet. Connections work, sort of, but GoGo throttles the requests fairly quickly causing the tunnel to break down.
If you are able to resolve www.digitalbond.com or ay other internet address from inside your control systems network, chances are good that you are vulnerable to this method of communication. My weapon of choice is iodine, a free IP-over-DNS tunnel that allows for a password-protected server. If you want to try IP-over-DNS tunneling from your own control network but don’t have an internet-accessible server to try it on, drop me a note and I’ll give you access to a test domain. From it, you should be able to load up an internally-hosted web page.
Of course, the crafty have their wheels begin to turn: this technique is universal across bidirectional protocols. For example, I can (and maybe will) make an IP-over-Modbus/TCP tunnel. The tunnel could use Modbus read coil commands to send and receive arbitrary data to a malicious slave, say on the far side of a Layer 7 Modbus firewall…
Image by amagill