Everybody knows that you can’t connect to a WiFi-hotspot if it is secured and you don’t have a the password. But at airports, train-stations or homes with a routers from a big provider you will have a unsecured wifi hotspot, but when you connect to it and you open your browser, you will get prompted to log in or supply a credit card, etc… . Great if you have a login but otherwise you are stuck behind this ‘captive’ portal (that is what this page is called).

1. Router Port 53
2. Open Udp Port 53

How to bypass a captive portal

Hi Fordem, thanks for the reply! I didn't know port 53 was automatically blocked so that's interesting, thanks. Re the wireless, are there devices that allow people to connect over considerable distances? The closest someone could get to the router without being within the boundaries is about 40 meters away. If I export the settings and reset.

Often you can bypass a captive portal page by using DNS tunneling. You can test if this attack is possible by trying to ping google.com. Try this command;

You don’t need to get a PING back, but you can see that www.google.com resolved to 172.217.17.36, this means that DNS is still working… strange if you don’t have an internet connection right?
So this means that DNS is still working. If we give the router a domain, it will resolve it by sending it to a nameserver and it will keep searching till if finds the IP, which it will send back to us. Now if you specify a subdomain (“mail” in mail.google.com) it will ask the nameserver of the subdomain (if it exists) to give the right IP and relay it back.

This means that if we control the subdomain we are looking up, and we control the nameserver assosiated with it, we can decide which IP (or better DNS record) to send back. The result is that we can upload data through an extra attached subdomain and download data encoded in the DNS-record that is send back. This process is called DNS-tunneling. To encode this data, there are multiple tools available but iodine is a great one, and this is that is used in this article.

What you need to setup:

• Spare (Linux) machine at home, this can be an existing server or desktop.
• Dynamic DNS that resolves to public IP of server (explained in this article)
• A subdomain that holds a NAMESERVER-record (explained in this article)
• Iodine-daemon on the server (explained in this article)
• Router which you can setup with static IP’s and Port forwarding

Setting up the DDNS and NS-record

You can use freedns.afraid.org for the dynamic DNS and the NS-record. So make an account and go to “subdomains”. You need to make 2 subdomains. One is a normal A-record (domain name to IP) and one of the type NS that is redirected to the A-record so it points to the public IP of the server at home.

For the A-record fill in a sub domain (can be anything, just remember it) and choose a domain (these are donated by a large community to use). fill in the captcha and done.
The NS-record do the same, but change the destination to the A-record you just made (<subdomain>.<domain>).

The IP of the A-record was auto-filled when the subdomain was created but it needs to be periodicly updated by the server, so it keeps pointing at the public IP of you home-router with the server behind it. There are many ways to do this (can be found here), but one of the easiest is fetching an url with a curl-command every 60 seconds.If you go to freedns.afraid.org/dynamic, you can choose your subdomain of your A-record and get the link behind ‘direct link’.

It looks like this:

ddns.sh:

Put this on the server at home. This is a script that calls the url every 60 seconds so it keeps updated over time. You probably want to execute it on boot. On a system with systemd you can use this service file:

/usr/lib/systemd/system/ddns.service:

Then run these commands to check if it works and if so, make it persistent.

sudo systemctl status ddns.service #check if ok sudo systemctl enable ddns.service #make it persistant over boot

Now if you ping your A-record subdomain you will get the IP of your router at home. The ddns.service will keep it that way.

Configuring the Iodine-daemon

First you have to install the iodine program on the server at home, find it in the repository as “iodine” or “iodine-server”. For Arch-Linux this is the following command:

Now you want to configure the daemon with the info of your record and make it start at boot. This is the command that has to run on boot:

On Arch-Linux the service file is already supplied and the settings can be found at /etc/conf.d/iodined:(you only need TOP_DOMAIN and IODINE_PASSWORD)

When ready run these commands to make it run at boot on an Arch-Linux system:

Note: You really want to set a password, this is not for encryption, this is not encrypted in any way, but for authentication, so not everybody can use your DNS-tunnel.

Now you need to port-forward port 53 (the port DNS uses) on your home-router to your device, used as server. This is different for every router but generally you also want to make the internal IP “static” for this device so it does not change after a reboot. Now your Iodine-daemon is accessible from outside of your network.

You can check if everything is properly setup by filling it in on this page http://code.kryo.se/iodine/check-it/. It will tell you were it failed if something is not in order. If it works, let’s bypass some captive portals!

Usage

You should install the iodine-client before you get stuck somewhere without internet.
It is found in many repositories as “iodine” or “iodine-client”. On Arch-Linux:

Then to use this technique when you are behind a captive portal, make sure you are connected to the hotspot. Then, when you have confirmed there is a hole in the security of the captive portal with the ping method described in the first part of this article, run the following command. (it will ask a password if set)

Awesome! We have a tunnel. Now we can contact every port on the server at 172.18.42.1, for example we can SSH to the server:

Now to tunnel a internet connection through, you can use the built in SOCKS-proxy of SSH. To use it supply the -D option with a local port to put the proxy on. All your internet will be tunneled over the ssh-connection if you specify the proxy in your program. example of the command:

Research how to setup your programs on your system to use the proxy or use this quick tip which explains how to run commands through a proxy. There is also a transparent way that tunnels all internet through a ssh tunnel explained here.

Hope you learned something about how the internet works and have some free internet in the meanwhile. Have fun!

Share this:

Related

[…] for this purpose. There are also many attack-vectors which require physical devices. Exploits like DNS-tunneling, HID-attacks and BadUSB are only a couple of […]

Abusing the one open port on a network to get things done

Have you ever read about a trick and then thought it was ridiculous because you're too dignified to use something that dirty? Have you then found yourself in a situation where you have to go back to that trick and use it anyway, because you really are that desperate? When it comes to technology, you don't get to keep your hands clean for very long.

Not too long ago, I found myself in a quasi-coworking place where you get office space, a markerboard and all of that stuff. It's the sort of thing where you can bring a client and hash out a big project. They provide the bathrooms and drinking fountain and all of this.

One thing they supposedly had was wireless Internet. I assumed it would work, but hadn't actually tested it. While waiting on my client to arrive, I tried using it. I found that it would just sit there and spin forever before finally yielding something ridiculous like '5 0 0 S e r v e r e r r o r'. Yes, it actually stretched the letters out like that.

Router Port 53

I knew it had to be one of these dumb 'walled garden' things, and really just wanted it to get out of my way. All I needed was enough connectivity to fling my VPN packets to my tunnel host. Usually that means starting up a sacrificial browser session and clicking through their annoying page to get unfettered access.

This time, it wasn't happening. All I got was that stupid error page. One thing I noticed during all of this was that I was actually able to resolve hostnames. Not only that, but I could bounce queries off specific servers. Apparently UDP port 53 would get through. I confirmed this by logging into my tunneling host and using tcpdump to watch for traffic. Sure enough, I could emit some stuff on my laptop and see it back on my host.

As for how I got on my tunneling host, well, that was also a stretch. I barely had a cell signal in this weird office place, and was just able to ssh from my phone and kick off tcpdump. It's the sort of thing I only use when absolutely necessary since it's such a pain: the tiny keys, limited terminal space, and horrible packet loss leading to laggy sessions.

It was just enough connectivity to let me add an iptables rule. This is where it gets really dirty. I basically did this:

iptables -t nat -I PREROUTING -s external.ip.of.office.network -p udp -j REDIRECT --to-ports port_of_tunnel_server_daemon

Basically, I took *ALL* UDP from that office and shoved it into the program which runs the VPN/tunnel. That way, if I'm able to find so much as a single port which will pass traffic unmolested, I can get on.It just so happens that port 53 works... some of the time, at least.

Open Udp Port 53

It was just enough of a pipe to let me do things like git sync operations. Trying to look at web pages was asking too much of this laggy, lossy connection. It was shades of my 4800 bps cellular modemhack,only far worse.

When I say it's possible to be in the middle of Silicon Valley and have miserable Internet access, I mean it. If I end up working at this site again, I'm going to have to buy my own little cellular hotspot and find a place with decent cell reception. There's just no way around it.

Tunneling over port 53. What a horrible hack.