Tunneling through captive portals with DNS

Networking
1

Imagine you are sitting in an airport, and you feel a sudden urge to browse the Internet. You take out your phone, and there seems to be an open network for travelers. Having safety in mind, you fire up your VPN client. But wait - It can’t connect? You open your browser and witness a horrible sight when you try to look something up in DuckDuckGo…

“Damn!”, you say to yourself. “I don’t want to pay for that! There has to be a way…”

Enter DNS tunneling!

DNS is, in short, a service to translate domain names, such as 0x00sec.org, to IP adresses, such as 104.18.49.48. A typical exchange looks like this:

  1. Client sends a UDP packet containing the domain name to translate.
  2. Server replies with the IP address corresponding to the domain.

There are more DNS record types, for example TXT, which allow the server to respond with arbitrary data instead of an IP. Now, someone smart thought to themselves, would it be possible to communicate using DNS requests and replies? As it turns out, it is! Imagine something like the following:

  1. Client sends a DNS packet of type TXT containing “hello-server.domain.tld”
  2. Server receives the packet, reads data from the request and sends back “hello-client”

See where this is going? Now, let’s go a step further and create (almost) a full blown VPN! With some base64 or other encoding sprinkled in, you can send whole IP packets encapsulated in DNS requests. Here’s an example:

  1. Client reads a packet from a TUN device, encodes it and sends a request containing the packet to the server. Let’s say it’s a SYN packet to 0x00sec.org.
  2. Server receives the request, and decodes the packet.
  3. The packet’s source address is changed to indicate the server’s address, so replies go back to the server instead of the client.
  4. The packet is then sent on its way, and a reply shortly arrives: a SYN/ACK packet!
  5. Packet source is changed back to client so his networking software doesn’t bitch about malformed packets and other such frivolities. It’s then encoded into a DNS reply and sent back.
  6. Client receives the SYN/ACK and writes it into the tun device.

Now the client’s browser/netcat/metasploit will respond with an ACK packet and a connection will be estabilished. There’s a caveat, though. What if the server needs to send data? It can’t just send another DNS reply, as the client’s router won’t route it to the client anymore. The solution is a bit hacky but simple: the client just needs to send an empty DNS request every so often, so the server can reply with the data.

It might look simple on paper, but the implementation is somewhat difficult. Trust me, I tried. Thankfully, there already are programs for DNS tunneling. The one I’m using is called Iodine. You can install it by using apt-get install iodine. Here’s what you will need:

  1. A server and client. They’re both included in the iodine package.
  2. A domain name, with the ability to set nameservers. You can get one from dot.tk.
  3. Another couple domains to set up nameservers.
  4. A computer you can forward port 53 to.

You’ll have to set up nameservers to domains which point to your iodine server.

Setting up is quite simple. On the server, run:
iodined -P <strong password> <IP of tun device> <domain>
for example, iodined -P 1234 10.0.0.1 tunnel.tk

On the client, run:
iodine -P <password> <domain>
for example, iodine -P 1234 tunnel.tk

And voila! Free internet access everywhere! (Unless the router doesn’t fall for it and blocks all DNS queries, but shh…)

14 Likes
2

This is pretty 1337, but it sounds expensive.

1 Like
3

This can’t be real. The legend himself @Joe_Schmoe made a write-up? Dayum!

3 Likes
4

.tk domains are free.

1 Like
5

Computers aren’t, though. And I would not wanna use one of those dot.tk spam domains.

1 Like
6

You can run iodined on your main computer while away on holidays or a raspberry pi. It takes up barely any resources.

If you don’t want to use dot.tk domains you can use any other free domain services, but you need to be able to change nameservers.

7

@Joe_Schmoe What does changing nameservers entail?

8

Iodine is pretty dope, but the thing that killed me with it is that you need to be prepared ahead of time to use it. I found myself stuck in an airport and wanted to tunnel out, but didn’t have iodine or a gateway. RIP.

2 Likes
9

However, if we’re strictly talking about evading captive portals, most have a free tier that lasts 30 mins or so. Use macchanger to generate a new mac and refresh your session

3 Likes
10

That’s what I do the majority of the time. In the past I have spoofed Mac addresses of of the people who have paid, but @py doesn’t believe I pulled it off.

2 Likes
11

DNS records man! Cmon.

12

That sort of attack is in theory not that hard to pull off. Just sniff for someone who is clearly browsing past the paywall, send a ton of DEAUTH frames, wait until they get pissed and give up, then take over their mac.

3 Likes
13

@pry0cc:

It is possible. The way you described it seemed like you and the victim were sharing the same MAC address while BOTH connected, which will fail.

@fraq’s description sounds feasible because the user will be kicked off the network.

1 Like
14

Perhaps I was lucky? Where that person had left just as I connected? Or perhaps the access point would disconnect the user in favour for the new user?

Hm who knows. Does anybody know the rules around what happens when a device connects to an access point with the mac address of an exisiting device?

15

I read this a few months ago in my online newspaper. Maybe a time saver, a lot less l33t way to get on the airport wifi: http://mashable.com/2016/10/06/airport-wifi-map/#2eMsSLDm7qqw

1 Like
16

Nice post. This might come useful. Muahhaha! :smile:

17

I do this also. It works in most hotels.

18

I know this is one hell of a necrobump and im probably going to get beaten up by @vict0ni ,
but anyways here it is …

  1. Most captive portal have some whitelisted hosts which are allowed though it.
    Ex: the website of a hotel so that customers can access it without paying for the wifi, or the
    website of a university which guests can access without logging in.

  2. Good News!, this can be abused

  • Incase of Http connections : if a arbitrary website does not have virtual hosts configured
    while visiting it you could just rewrite the host header to that of a allowed site, and the
    captive portal should allow you to visit that site.

  • Incase of Https connections : you can change the SNI header(in the TLS client hello) to that of a allowed site, this should result in the webserver giving you some default TLS certificate and will generate a warning in the browser, but since the host header is unchanged the website should be accessible as usual. (This might not be possible in all captive portal scenarios)

1 Like
19

hahaha I would never!

1 Like
20

“Allegedly” borrowed mac-addresses of people who already paid lol