I first wrote about DNS Tunnelling back in 2010. Even back then, commodity tools to facilitate it were at least five years old. I covered OzymanDNS, DNS2TCP,Heyoka, and DNSCAT in 2010.
A few years ago, I was introduced to Iodine, and it's been my go-to tool for DNS tunnelling ever since, frequently with great success. Iodine has several different modes, and will try various query types, packet sizes and timing parameters, usually making the connection as reliable as it can be. Without any adjustments, it doesn't try to be stealthy, but if you dig into the manual client options and you know what your adversary is looking for (e.g. Snort/Suricata rules, Bro, FQDN length, volume of queries, etc.) you might be able to get Iodine to fly below the radar.
Just like the very first articles I wrote, the technique requires you to set up a sub-domain with a name server. Here, I set up a subdomain for *.t.h-i-r.net, and I've assigned it a name server of tn.h-i-r.net. I had to specify an A record for it: the IP address of a VPS I'm leasing (which also hosts much of HiR's presence aside from this blog). You could easily point it to your home IP address -- so long as you can NAT port 53 UDP to it.
Once you have established these DNS configuration entries, and made sure that UDP traffic can get to port 53 on the tunnel server, you should be ready to get Iodine installed. Most GNU/Linux and BSD flavors I've used lately have Iodine in the package repository. That includes OpenBSD, Arch Linux, Kali, and Ubuntu. If you're using Mac OS X, there's a Homebrew recipe that seemed to work last time I tried. The Iodine page has Windows and Android binaries available for download. I have not yet tried them.
You probably want to leave the iodine server (iodined) running on your tunnel server at all times, so that it's ready when you need to use it. Since iodine uses a privileged port and creates TUN/TAP interfaces, you need to run it as root. At a minimum, to start the Iodine server, you need to specify a password, a network (in CIDR notation) to allocate for the tunnel, and the subdomain you configured above. I'm using a pretty small network mask (/29) which allocates only five client IP addresses. As I'm the only one using this tunnel server, this is fine. It might even be overkill.
# iodined -P r3d4c73d 172.16.0.1/29 t.h-i-r.net
Opened /dev/tun0
Setting IP of tun0 to 172.16.0.1
Adding route 172.16.0.0/29 to 172.16.0.1
add net 172.16.0.0/29: gateway 172.16.0.1
Setting MTU of tun0 to 1130
Opened IPv4 UDP socket
Limiting to 5 simultaneous users because of netmask /29
Listening to dns for domain t.h-i-r.net
Detaching from terminal...
#
On the client machine, it's assumed that you can connect to a network, but unrestricted Internet access isn't working. In my example, I'm on a somewhat restricted hospital Wi-Fi network that isn't allowing SSH, and has restrictions on what one can browse on the web. Most of my favorites are being blocked because they're "hacking" related.
Ideally, a recursing DNS server is available. As long as you can see the NS record you set up, there's a pretty good chance Iodine will work. The client also needs to run as root (or via sudo) and the bare minimum configuration requires a password and the subdomain.
$ host -t ns t.h-i-r.net
t.h-i-r.net name server ns.t.h-i-r.net.
$ sudo iodine -P r3d4c73d t.h-i-r.net
Opened /dev/tun0
Opened IPv4 UDP socket
Sending DNS queries for t.h-i-r.net to 208.67.222.222
Autodetecting DNS query type (use -T to override).
Using DNS type NULL queries
Version ok, both using protocol v 0x00000502. You are user #0
Setting IP of tun0 to 172.16.0.2
Adding route 172.16.0.0/29 to 172.16.0.2
add net 172.16.0.0/29: gateway 172.16.0.2
Setting MTU of tun0 to 1130
Server tunnel IP is 172.16.0.1
Testing raw UDP data to the server (skip with -r)
Server is at 168.235.84.117, trying raw login: OK
Sending raw traffic directly to 168.235.84.117
Connection setup complete, transmitting data.
Detaching from terminal...
Once you have the connection established, the remote end should be reachable via the "Server tunnel IP" shown in the output. In this case, that's 172.16.0.1. Typically, this is where I set up a Dynamic proxy with ssh.
$ ssh 172.16.0.1 -D 1080
Last login: Thu Oct 20 17:44:19 2016 from 172.16.0.2
OpenBSD 6.0 (GENERIC.MP) #0: Fri Sep 2 16:10:46 CEST 2016
$
Back in the real world, I set Firefox proxy settings up to use localhost at port 1080, and enabled remote DNS. Configuring the proxy in other browsers may vary. You may even have a system-wide SOCKS proxy setting.
Firefox now can browse through this SSH session, which is tunnelling over DNS.
Back on the tunnelled SSH session, I used the ~# SSH escape command to list open tunnel connections. This will verify that you are browsing through the tunnel.
The following connections are open:
#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cc -1)
#3 direct-tcpip: listening port 1080 for www.h-i-r.net port 80, connect from 127.0.0.1 port 16128 to 127.0.0.1 port 1080 (t4 r1 i0/0 o0/0 fd 9/9 cc -1)
#4 direct-tcpip: listening port 1080 for www.blogger.com port 443, connect from 127.0.0.1 port 25392 to 127.0.0.1 port 1080 (t4 r2 i0/0 o0/0 fd 10/10 cc -1)
#5 direct-tcpip: listening port 1080 for apis.google.com port 443, connect from 127.0.0.1 port 46746 to 127.0.0.1 port 1080 (t4 r3 i0/0 o0/0 fd 11/11 cc -1)
...
It's hard to see here, but I grabbed a Wireshark screen shot of Iodine in action a few weeks ago. The heartbeat packets are all pretty short. They can get quite large when the time comes to send a lot of data. Here, Iodine has chosen to use NULL records.
Posts
