DNS Tunnelling,
its all in the name!
Arron “finux” Finnon
finux@finux.co.uk
http://www.finux.co.uk

Okay, DNS Tunnelling sounds a little
complicated. You won't need a hard hat, a
shovel or a drill, but you will need a shell
account on a system which allows you control
over port 53

However, it is very likely that it is illegal unless
it is in your own test environment

So who am I, and why am I here?
I ask the question every morning, I still haven't answered it,
but I maybe able to answer it for you
My Name is Arron, I have been involved in ethical hacking
for a number of years. I'm currently at The University of
Abertay Dundee as a student. I have spent sometime as a
security consultant, and independent researcher. I have a
reputation as being a little bit of a media/attention whore.
I agree with that statement, so much so that I have a weekly
podcast talking about geeky things: Finux Tech Weekly
I have over the years gave a number of talks on a range of
things related to hacking and security.

So where can you find me?
Email – finux@finux.co.uk
Twitter – www.twitter.com/f1nux &
www.twitter.com/finuxtechweekly
Facebook – www.facebook.com/finux
Podcast Site – www.finux.co.uk
Skype – finux1

Talk Out Line
The History Involved
Technical Overview
Tools Available
Those that “Bob” told me are effected
A short how to on one set-up/configuration option
Other potential uses for DNS Tunnelling
Countermeasures
Links
Q&A

Disclaimer
Without doubt the legal implications of using the discussed techniques
are immense. If you use this to obtain “Free Internet”, I would point out
that if you go to JAIL its not very free, and of course it could quite
possibly cost you a career too.
If you have any doubt about the legalities of what you are doing then
STOP it.
If you do use this to break the law, and you do get caught. Your totally
on your own, this is for educational purposes only. Feel free to let me
know though, it will make a great anicdote and I'm happy to write to you
during your stay.
However as usual to defend we must know how to attack.
“The art of war teaches us to rely not on the likelihood of the enemy's not
coming, but on our own readiness to receive him; not on the chance of
his not attacking, but rather on the fact that we have made our position
unassailable.” - Sun Tzu
Not if the hacker comes, but when they come......

Intended Audience
Here's the shock! Hackers! However I mean the playful advocates of
technology when I use that term. I tend not to buy into the media
definition of it.
What I mean by hacker is;
playful advocates of technology. If technical things excite you, then this
is for you.
I love security, i love hacking, i love taking things apart and i believe its a
prerequisite for our trade.
As a good friend of mine, who is now the chief of operations for first base.
A long haired geek that goes by the name of Pete Wood; if you wern't
electoricuted by the age of 10 this might not be the trade for you. I'm
proud to say i was shocked by 6, and I'll hazard a guess I'm not the only
one in this room.

A Small Intro
In September 2000 a post came across the Slashdot website informing
its readers of an interesting use of DNS tunnelling for breaking out of
locked down networks. It utilises that most networks regardless of their
firewall, or their Access Controls Lists, would allow DNS look ups.
Researchers found with crafted packets that they could in fact establish
bi-direction IP traffic, they delivered a protocol named NSTX.
However this concept became more widely established when the
respected DNS security researcher Dan Kaminsky, released his Ozyman
tool at Black hat in 2005, Kaminsky who in 2010 became one of ICANN's
Trusted Community Representatives for the DNSSEC root certificate, has
an unparalleled reputation when it comes to DNS security and it
insecurities. Needless to say this release caught the attention of many
security researchers, however worrying nearly 11 years after the
discovery and 6 years since Kaminsky's Ozyman tool release, this
vulnerability still lives on in a number of networks.
All though DNS tunnelling could be seen as way to obtain free Internet on
captive portals, it is also an effective tool in data theft. However it is hard
to imagine the limitations when this is mixed with shellcode's. DNS
tunnelling could be used to reverse connect a shellcode from target to
attacker, the tunnel's effectiveness of traversing NAT makes it a worthy
deployment.

Some History
So 1987 the the domain name protocol basically came into life, it was
defined in the the RFC 1035. It superseded RFCs 882, 883, and 973.
Around 13 years later a group of hackers started playing around with the
concept of DNS tunnelling. Mainly due to gain free internet from a
Microsoft update PPP dailin's. Most of these Microsoft PPP dialins allow
you to use a Name server.
These hackers later developed "NSTX Protocol", meaning "Name server
Transfer Protocol" in doing so they finally managed to use one of
Microsoft toll free numbers in Germany and tunnel their net connection
over it.
Iodine later became popular due to its password authentication however
it was still very similar to NSTX.
However as i have said i think it fair to say that the concept grabbed more
attention when respected breaker of DNS Dan Kaminsky released a set
of scripts at Black Hat 2005 which were written in perl and in reality very
easy to deploy. For the purpose of today's talk i will focus on
OzymanDNS

Technical Overview
Now we could take this from the stand point of a captive portal, which
normally intercepts all web traffic until some sort of authentication is
achieved.
However we see regularly that a they still enable DNS enquiries. I way to
check this on a captive portal would be to use either dig or nslookup if
your running windows. If you are issued a private address then your out
of luck, however if you receive the IP address of the domain name in
question then DNS requests are allowed out.
So if we revisit the Domain Name Systems set-up, we'll see that it has 13
root domain name servers responsible for the .com's, .org's, so on and so
forth known as the Top Level Domain names or TLD for short. They are
responsible down to the root domain such as example.com, then from
there sub domains are delegated to their own server. Such as
test.example.com. Each domain is configured in a zone file, and each
zone file has a number of records configured within it. So an example
would be an A record which stands for an address record, or a CNAME
alias for an A record, we could see a MX record for handling mail, a NS
record which points to a new DNS Server for that sub-domain, or a TXT
record which handles text descriptions. It is the last two records that
interest us.

Technical Overview
A hostname can only be 255 octets long, or 255 bytes. In addition a TXT
record can also only be 255 bytes.
So it lies within these 255 byte TXT records the potential for us to deliver
a payload of data back within one of these records.
If we could encode a formatted domain name request up to a maximum
of 255 bytes, and then have that decoded back at our fake domain name
server.
Our fake domain name server could encode our response back and
deliver that via a TXT record we now see the very plausible avenue of
transmitting data.

Technical Overview
So what we would need in this situation is a fake domain name server
listening on port 53, which will respond to requests, and a hostname
which is in fact a delegated NS record pointing to a fake DNS Server. An
example would be;
inbound.example.com would point to server.inbound.example.com
The zone file could look like this;
inbound.example.com NS server.inbound.example.com
server.inbound.example.com A 92.35.18.118
The A record would point to our fake domain name server, and our client
would make its requests to the inbound sub-domain.
Of course if you where using DynDNS.org it could be a simple as
inbound.example.com NS finux.dyndns.org

Technical Overview
Now a free account at DynDNS.org does not allow you to delegate Name
Servers. However freedns.afraid.org does. I happen to prefer the update
client(s) on DynDNS, so I personally go for a freedns.afraid.org and point
it to a DynDNS account. Personally I think this makes the set-up slightly
more easier, and gives it an edge of portability.
Now all DNS Tunnelling set-ups in some way use the delegated Name
Servers. Now I admit I'm a Linux jock and so this configuration is based
on my experience with Linux, there is some links on how to do this with a
Windows set-up at the end. My advice to you would be to build a Virtual
Machine either running Ubuntu/Debian which of course will make its
deployment in your test environment pretty easy.

Technical Overview
As I have said for today's purpose we'll be looking at Kaminsky's
OzymanDNS tool, in fact its a revised revision of it. OzymanDNS is
broken down into 4 perl scripts. The server script is named nomde.pl
which listens on a privileged port and in doing so requires sufficient
permissions to do it;
sudo ./nomde.pl -i 0.0.0.0 inbound.example.com
The above command would set OzymanDNS server section to listen to
all requests on the sub-domain inbound.example.com

Technical Overview
Now the OzymanDNS client is written to encode/decode and send the
responses back via STDOUT which isn't overly useful however combined
with the SSH config option "ProxyCommand" enables the ease of use
this set of scripts has become renowned for.
ssh -o ProxyCommand="./droute.pl sshdns.inbound.example.com"
user@localhost
The upstream data sent out will be encoded using Base32. After the data
has been transmitted, there is a unique ID due to some DNS requests
taking longer than others, the UDP protocol has no methods to check
this. and either one of the keywords up or down, indicating whether the
traffic's up- or downstream. Here is what an example request could look
like;
ntez375sy2qk7jsg2og3eswo2jujscb3r43as6m6hl2wsxobm7h2olu4tmaq.ly
azbf2e2rdynrd3fldvdy2w3tifigy2csrx3cqczxyhnxygor72a7fx47uo.nwqy4o
a3v5rx66b4aek5krzkdm5btgz6jbiwd57ubnohnknpcuybg7py.63026-0.id-
32227.up.sshdns.inbound.example.com

Technical Overview
The response comes as a DNS TXT record. A TXT record can hold
arbitrary ASCII data and can hold upper-case letters as well as lower-
case letters and numbers. So the responses come encoded with Base64
encoded. Such a response might look like the this.
695-8859.id-39201.down.sshdns.inbound.example.com. 0 IN
TXT
"AAAAlAgfAAAAgQDKrd3sFmf8aLX6FdU8ThUy3SRWGhotR6EsAavqH
gBzH2khqsQHQjEf355jS7cT
G+4a8kAmFVQ4mpEEJeBE6IyDWbAQ9a0rgOKcsaWwJ7GdngGm9jpv
ReXX7S/2oqAIUFCn0M8="
"MHw9tR0kkDVZB7RCfCOpjfHrir7yuiCbt7FpyX8AAAABBQAAAAAAAAA
A"

Technical Overview
So a quick recap of what is needed on our Debian like system.
We we need to install some perl packages;
sudo apt-get install screen libnet-dns-perl libmime-base32-perl
In addition you may want to install ddclient as well and configure your
dynamic sub-domain to point to the server.
You'll also need to set-up SSH as well
You will want to download the OzymanDNS scripts, I have made the
latest version available on my site.
wget
http://finux.co.uk/demos/software/OzymanDNS-Splitbrain-Version.tar.gz
Now as I have said the version of OzymanDNS is revised and the code
cleaned up by Andreas Gohr of the Splitbrain.org website
http://www.splitbrain.org/blog/2008-11/02-dns_tunneling_made_simple

Technical Overview
Our client configuration is as follows;
sudo apt-get install libnet-dns-perl libmime-base32-perl
And then a simple command command
ssh -o ProxyCommand="./droute.pl sshdns.inbound.example.com"
user@localhost

Tools Available
Iodine is based on NSTX as i have mentioned is a Linux only tool,
however it works via producing a virtual network interface on the server
and client, and those two virtual interfaces communicate with each other.
Netcross is a little modular tool that might be useful in restricted network
connections
DNSCat is the basically NetCat for DNS

Those that “Bob” told me are effected
The Cloud Network – Such as the one's that cover Weatherspoons pubs
and McDonald's
BT Open Zone
A certain University in North East Scotland – Which will soon be fixed
Interestingly over 3g it has been reported that T-Mobile allow unfettered
DNS queries. This could in fact be false, however if its true then really
quite scary.
Eastern Trains
Remember its easily tested, a nslookup or a dig should tell you within
seconds. Even if ping is blocked there is a good chance you could use
that to determine if the next work is vulnerable to attack, as it will still
obtain an IP address

Other potential uses of DNS Tunnelling
As discussed covert communications over an otherwise restricted
channel.
Data theft, as in you do not allow any SSH, FTP, SFTP so on and so
forth. scp works with the OzymanDNS set-up
By far the craziest I have seen is to deliver shell code via DNS Tunnel's.
The interesting concept with tunnelling a shellcode over DNS is for
starters this happens to null in void any potential NAT issues
There is already a fair few PoC that highlight this concept. I have been
reading of recent how we could use some of the Metasploit payloads,
combined with DNSCat
I have not had time to play anywhere near as much with this as I would
have liked too. But needless to say I'm sure I'll get my chance

Countermeasures
The best way of detecting DNS tunnelling is by performing statistical
anomaly detection on the network.
Some characteristics of a DNS tunnel include:
High volume of DNS requests from internal clients where little usually
take place
Significant difference in the format of these lookups as compared to
regular ones i.e. Base32 and Base64
The total amount of data transferred over port 53 is much higher than
usual
DNS Tunnelling could actually be one of the best covert channels ever
designed. In general, it proves quite challenging to stop this traffic, as
there is no specific indication that it concerns IP over DNS tunnelling.
There are however a number of ways to mitigate the threat to a certain
degree.

Countermeasures
If you are running a for-a-fee access point, consider having your DNS
server answer all queries with a local IP address until payment has been
completed. Only afterwards should a client be able to perform DNS
lookups that your server resolves to the internet.
Many organizations do this currently by having HTTP requests rewritten
to a local web server on which payment is due. This however still allows
the client to resolve external domains, and as such, does not alleviate the
covert channel.
A potential solution is to set up a BIND server which has a local entry for
all TLD's: get lists here and here.
Set up a wildcard entry for each of these domains that points to your local
web server that processes payments.
Requests to any other domains or zones should not be handled
recursively.

Countermeasures
One solution which is sometimes considered is to deny all queries for
TXT records.
The impact of this will in most cases would be limited, although certain
functionality (such as SPF) may break.
In general, only your incoming mail server will need to perform these
lookups: taken a general split-DNS service on multiple servers, it should
be feasible to work around this issue.
There are precious little reasons why the average internal client should
be able to perform lookups for TXT records.
This approach is however fairly naive as tunnelling will still be possible
through other record types.
You will not be able to disable these others, such as CNAME, due to the
heavy production impact.
Remember blocking a domain name with X amount of calls within a
period seems a good idea, until you think about the lookups your
organisation makes to google in an hour

Conclusions
In conclusion I haven't really scratched the surface of what can be done
here.
The reality of it is, if your not looking at DNS traffic then someone may
well be doing so.
Its has the potential to be still one of the best covert channel's going and
can be very technically difficult to detect.
The uses for this are really limited by your imagination.
If you can use this with 3g technology then this could make somewhat of
a lethal weapon.
However some pre-thought of what you could and should expect on your
network
You may think this connection would be slow, but within my links is a
paper showing that speeds of up to 110 kilobytes a second

Links
Slashdot article on NSTX.
http://slashdot.org/articles/00/09/10/2230242.shtml
Kaminsky's Wikipedia page
http://en.wikipedia.org/wiki/Dan_Kaminsky
Kaminsky Release of the Tools he developed
http://dankaminsky.com/2004/07/29/51/
Kaminsky's Black Hat paper
http://www.doxpara.com/slides/BH_EU_05-Kaminsky.pdf
Dan Kaminsky's 2005 Black hat talk
http://www.splitbrain.org/blog/2008-11/02-dns_tunneling_made_simple
Very good guide on setting up DNS Tunnels
http://dnstunnel.de/
IVC Wikipedia article on DNS tunnelling
http://beta.ivc.no/wiki/index.php/DNS_Tunneling

Links
Another further guide to tunnelling DNS
http://www.h-i-r.net/2010/03/dns-tunneling-part-1-intro-and.html
PDF paper from Black hat
http://www.blackhat.com/presentations/bh-usa-08/Miller/BH_US_08_Ty_Miller_Reverse_DNS_Tunneling_Shellcode.pdf
Heyoka paper
http://shakacon.org/talks/Revelli-Leidecker_Heyoka.pdf
Further guide to making to configuring OzymanDNS, however for
Windows type systems
http://cyberphob1a.wordpress.com/2008/02/10/dns-tunneling-part-i/
http://cyberphob1a.wordpress.com/2008/02/11/speeding-up-dns-tunneling/
http://cyberphob1a.wordpress.com/2008/03/08/dns-tunneling-updated-source/
DNS RFC
ftp://ftp.rfc-editor.org/in-notes/rfc1035.txt

Links
Another set of software for TCP over DNS this one using Java instead of
perl
http://analogbit.com/tcp-over-dns_howto
For Presentation Side Notes – Speeding Firefox for Low Bandwidth
carriers
http://www.ghacks.net/2008/07/13/optimize-firefox-for-low-traffic-volumes/
DNScat as a Payload with Metasploit
http://www.skullsecurity.org/blog/2010/weaponizing-dnscat-with-shellcode-and-metasploit
Reverse DNS Tunneling Shellcode (v0.3) Technical Details
http://projectshellcode.com/?q=node/2
In the following tutorial, we will use the tool dns2tcp written by two guys
working for HSC, a French security company.
http://blog.rootshell.be/2007/03/22/dns2tcp-how-to-bypass-firewalls-or-captive-portals/
http://www.hsc.fr/ressources/outils/dns2tcp/download/
Traffic analysis approach to detecting DNS tunnels
http://blog.vorant.com/2006/05/traffic-analysis-approach-to-detecting.html
Tunneling shit over DNS
http://www.modacity.net/forums/showthread.php?19755-Tunneling-shit-over-DNS

Questions & Answers
?

Thank You For Your Time
I hope it has been of interest
Please feel free to come grab me later for a
chat
Don't forget to listen to the show
www.finux.co.uk
On a side note, I have never been on a night
out in London.
So I'll apologise for tonight tomorrow
morning