IPoverDNS

Introduction

Firewalls for public wifi such as universitys, airports, train stations, coffee shops or hotels often have restricting rules that prevent IP traffic before the user has logged in to the network, requiring a password, some payment or both before allowing access to the internet. But in many cases, DNS traffic to the local nameserver is not blocked. By setting up an authoritative nameserver for one's own subdomain, one can send DNS queries that will be transmitted to this outside DNS server, and therefore transmit data. It is possible to tunnel IP traffic encoded in DNS messages and therefore circumvent the restrictions of the network.

How it works

A large part of the Wlan solutions in use is initially an open, unencrypted WLAN, which in most cases is named after the provider or the location or the hotel name. If the attacker, which at this point still acts as a normal customer, now works its network card to this WLAN and sends a DHCP request, it receives from the access point a local LAN-IP address. However, it can not receive and send packets, since a firewall on the access point drops all outward packets. (In detail, this means that the access point does not reject the connection by sending RST packets, but completely ignores the connection. For Iptables, this is equivalent to the "DROP" statement.) There is an exception to this categorical rejection these are connections on port 80 (HTTP). All HTTP requests are intercepted by the access point via a transparent HTTP proxy and the requests are transferred to a web page of the Wlan provider. The normal customer notices this by entering the browser, entering an arbitrary domain, and instead of the expected website, the web page of the provider appears, usually with a login option and instructions for payment.

But the client can still communicate with the local DNS server. DNS, the service that resolves domain names into IP addresses, is integrated into the access point for most of the wisans. And for all tested wlans, it also resolves names for non-authentic clients, so you can already send DNS queries before paying or logging in. And since the DNS server needs to communicate with other DNS servers out there, a communication channel is created that can be used for tunneling.

The attacker just needs to set up their own domain (say, "mydomain.com") with their own authoritative nameserver that resolves queries for "anysubdomain.mydomain.com". Now, when the DNS resolver of the restricted network gets a request for those subdomains, it sends the request to the authoritative nameserver. Encoded in this request, more specifically, in the subdomain, is the IP packet that goes out. The autoritative nameserver can access the internet himself, acting as a proxy, get the answer and encode it in a DNS NULL or TXT or any other large DNS record type, and send it back to the DNS resolver which will hand the answer to the client. Now the client has sucessfully communicated with the outside world.

Anleitung

DNS Server Setup

(todo: much more explanation)

Setting up Iodine requires control over a domain, for which you have to register the following dns records.

You have to run your own server with a public IP that will function as nameserver for your domain “mydomain.com” managed by iodine.

Assume you have a domain called “mydomain.com” and it’s IP is “1.2.3.4”. You have to register a subdomain, e.g. “tunnel.mydomain.com”. Also, you need another subdomain “ns.mydomain.com” for your nameserver. For the tunnel subdomain, Iodine on your own server (1.2.3.4) will pretend to be the authoritative nameserver.

So you need to create an A record for the sub-domain (tunnel.mydomain.com) that point to IP of the private server.

dns IN A 1.2.3.4

And you need a NS recod that makes the dns sub-domain the authoritative name server for the tunnel sub domain.

tunnel IN NS dns.domain.tld.

The result could look like this:

Iodine Server Setup

install and start iodine

$ sudo apt install iodine

$ sudo iodined -c -f 10.0.0.1 -P 123456 tunnel.l0m.de

Test server

http://code.kryo.se/iodine/check-it/

Iodine Client Setup

install and start iodine

$ sudo apt install iodine

$ sudo iodine -f -P 123456 tunnel.l0m.de

Test tunnel

$ ping 10.0.0.1

Set up routes to go through the tunnel

Find out dns server: $ nmcli dev show | grep DNS

Find out gateway: $ netstat -rn|egrep "^0.0.0.0"

Find out your tunnel interface: ifconfig -> look for something like dns0 that wasn’t there before

$ route del default $ route add default dns0

and if dns server and gateway don’t have the the same IP adress anyway:

route add -host [DNS server IP] gw [gateway IP]

Put a ssh tunnel through the dns tunnel for encryption

Put a ssh tunnel through the dns tunnel to encrypt

$ ssh -D 5000 -N root@10.0.0.1

$ curl --socks5-hostname 127.0.0.1:5000 http://httpbin.org/ip

$ google-chrome --proxy-server="socks5://127.0.0.1:5000" http://httpbin.org/ip

Deactivating Iodine

stop iodine client on client and server (just by pressing ctrl+c)

Set routes back to ‘normal’

$ route del default

$ route add default [gateway ip]

or just restart your networking manually by using the network manager or restart the device entirely.

Metrics

Of course, tunneling IP over DNS does not allow for a very impressive data rate.

Methods to prevent dns tunneling

Network architecture

The first method to prevent dns tunneling would be to block dns requests for arbitrary servers, so that the client that is not logged in yet can not resolve any dns request.

Tunneling Detection

Furthermore, tunneling of IP traffic over DNS results in unusual DNS traffic that can be spotted.

Implementations tend to use DNS types that can have a lot of bytes per packet, e.g. the experimental "NULL" type. We see those only when we use iodine, in regular DNS traffic this type does not appear at all.

Naturally, tunneld IP traffic causes a lot more DNS packets to be sent than normal use of the protocol. Also, because as much data as possible is crammed into every single packet, the packets get longer. See the following graphs for a comparison between normal DNS load (blue) and DNS metrics while using iodine for tunneling (green). We captured 9 times 30s of traffic and counted the number of DNS packets and the average length. As is clearly visible, the packets tend to get longer and there are decidedly more of them when tunneling is used.

Another method for detecting DNS tunneling is to analyze the fully qualified domain names (FQNs) that are resolved. Usually, domain names have somewhat meaningfull names like yourshop24.com or mywebsite.net. The fully qualified domain names that are resolved for the tunneling are very long and very arbitrary, containing a combination of many letters and numbers. We recorded the resolved FQNs, the following examples should illustrate the point.

Example for FQNs with tunneling:

0abbt82M-J2hbM->M-nYM-VAdM-?BM-KM->M-nWwM-bM-RcxbM->M-X5M-RM-mfM-dZkM-DaUM-UM-^TVXM->qGaM-VmgwM-faM->gdki5.a.tunnel.l0m.de.

0ebbu82M-J2hbM->M-nYM-VAdM-?BM-UM->M-nWwM-fM-RM-LxbM->M-X5M-RM-mfM-d9ZJx6M-}M-dM-QM-byaiqaSgM-AMnM-^WydtM-we.M-ZG.tunnel.l0m.de.

0ibbv82M-J2hbM->M-nYM-VAdM-CBM-?M->M-nWwM-fM-R2xbM->M-X5M-RM-mfM-d9ZJx6M-}M-dM-QM-byaiqaSgM-AMnM-^Wydule.M-ZG.tunnel.l0m.de.

0mbbw82M-J2hbM->M-nYM-VAdM-CBM-WM->M-nWwM-fM-RM-dxbM->M-X5M-RM-mfM-d9ZJx6M-}M-dM-QM-bzaiqaSgM-AMfM-^WyduNe.M-ZG.tunnel.l0m.de.

0qbbx82M-J2hbM->M-nYM-VAdM-EBM-YM->M-nWwM-mrM-VUdbM-rM-qPM-\lM-LM-dM-SmaM-BIM-]8M-lWM->qGaM-VmgM-FM-fM-_M->M-^dM-Jnf.Ca.tunnel.l0m.de.

0ubby82M->tM->dpM-}aabacuaaAXM-uKabagM-@MHGaaeM-jM-VM-[M-uM-Yjyd7zCjM-\HM-ILM-_M-YGcahM-}FM-Ea.aaqiGvM-}M-}M-`BM-EM-BM-_M-ZM-PM-oAM-`M-DM-v.tunnel.l0m.de.

Examples for normal FQNs:

img.washingtonpost.com.

d1pz6dax0t5mop.cloudfront.net.

ads.twitter.com.

s0.2mdn.net.

safebrowsing.google.com.

www.google.com.

We counted the number of resolved FQNs per 30s, the average number of unique characters in the FQNs and also the length of the FQNs. The differences between tunneling and "innocent" DNS traffic are obvious. It is therefore definitely possible to use some kind of analyzing software to detect DNS tunneling as we did with a simple python script.

Problems with Captive Portals

Technical problems

It doesn't work with https, because it's basically a man in the middle attack. When people try to access https websites, it doesn't work at all.

It causes some strange problems (https://forum.piratebox.cc/read.php?9,8879)

forged DNS answers don't work with DNSSEC

fundamental problems

man in the middle