Data Exfiltration: DNS tunnelling using iodine

DNS, as we all know, is the way that computers look up human readable names and turn them into IP addresses – and vice versa. Along with that basic function, there are referrals to other name servers, because the whole database is essentially decentralised, with each administrator looking after their particular domains (or zones).

DNS servers can be run in one of two modes – a recursive resolver, which is your computer asks when it needs to look up www.google.com. The resolver starts with .com, finds the relevant nameserver for google, then asks that for the www. prefix, and finally comes back to you with the answer.

The other type, is the name server that is asked in the above case – we say this is an authoritative nameserver – in this case, for google.com.

This configuration, and the flow of data enables us to set up a covert channel using DNS queries and responses to pass data between two machines, one inside and one outside the organisational perimeter. In this case, we’re using “iodine” for the DNS tunnel: http://code.kryo.se/iodine/

For the server, we first need to point our nameserver records to the Internet host that is going to support the remote end of the tunnel. This will need to be a public IP address, say “a.b.c.d” in this case.

Because I am using a .co.uk domain, I need to query the nominet nameservers. You can find these by running “dig co.uk ns”, which I omit for brevity.

And this is a referral to the endpoint server a.b.c.d. Which doesn’t actually answer queries sensible because it is being the tunnel endpoint, hence why you cannot just do a dig digitalanathema.co.uk.

So now, to run the server on a.b.c.d, use the following, where 10.0.0.1 is a network which is not currently in use by either end.

On the client:

“foo” is the password by the way, which you should not re-use! In another window, you can now SSH directly to 10.0.0.1 from the internal client machine (where 10.0.0.1 is the private tunnel address of “a.b.c.d”) and forward ports however you like using SSH port forwarding, including passing traffic through to some sort of SOCKS-type proxy on the remote end.

Some things to think about: would you notice this if it were going on? Would you be able to reconstruct the incident from your DNS logs if you were alerted to it?

If you don’t use a default deny policy on your firewall outbound, all this is moot anyway. Any insider, or an attacker who compromises an internal machine can simply export their data directly.