A Captive Portal Puzzle at Sea

by IceQUICK

The following occurred on a wonderful cruise ship in a beautiful part of the world.  The whole experience was like a dream.  In fact, it may have all been a dream...

I never intended to get online.

I had just boarded the cruise ship and was looking forward to spending the next two weeks disconnected from the world.  It was my first cruise and I wanted to get familiar with where the majority of the next 14 days would be spent.

Before the ship set sail, we went exploring and found the theater, three or four bars, the coffee shop, a few restaurants, and the library.  In the library, there were fliers advertising the ship's satellite Internet access.  Instead of selling it per megabyte, access was being sold by the minute.  It was priced between $0.25 and $0.75 USD per minute depending on the volume purchased.

My curiosity was awakened.

What kinds of wireless APs were in use?  What kind of authentication?  Captive portals?  How fast would it be?  My mind, like other hackers, wasn't actually interested in getting online.  The real challenge was figuring out how to solve this puzzle.

I opened my phone, which was being carried to take pictures, and successfully connected to the unsecured access point.  I tried to open yahoo.com (the site I use exclusively to trigger captive portals) and was redirected to a simple captive portal page.

Later that same day, we got back to the room and I opened my sticker-covered MacBook Pro.  I had read about bypassing captive portals using things like ICMP and DNS tunneling but had never attempted it.  No time like the present to figure it out!  I got connected and saw the same captive portal page.

I opened a terminal and first tried ICMP.

$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=532 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=10.3 ms ^C --- 8.8.8.8 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 10.289/271.262/532.235/260.973 ms

Success!

That was easy.  ICMP appeared to be unfiltered and ICMP tunneling was a likely option.  Next, I tried DNS.

I opened up nslookup, set the server to Google's DNS (8.8.8.8), and tried to resolve yahoo.com.

$ nslookup > server 8.8.8.8 Default server: 8.8.8.8 Address: 8.8.8.8#53 > yahoo.com Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: yahoo.com Address: 98.139.183.24 Name: yahoo.com Address: 98.138.253.109 Name: yahoo.com Address: 206.190.36.45 ... >

Success!

It resolved.  Direct outbound DNS was also open, and so DNS tunneling was another option.

I also tried to connect using SSH on a variety of ports (most of my servers use something other than port 22 for sshd), but none of those worked.

Since I hadn't planned on doing any "impromptu field systems administration," I didn't have any proxy servers set up back home or any real tools loaded on my laptop.

The only thing useful was the Tor Browser Bundle.

Tor's default direct connect settings didn't work, so I began trying the built-in bridges.  When I got to the last bridge in the list, ScrambleSuit, the familiar "Congratulations! This browser is configured to use Tor" popped up on the screen.

Success!

Now I could research and download tools, but couldn't authenticate to most of the services I use because they blocked or viewed traffic from a Tor exit node as suspicious.

I usually always have one or two servers online to experiment with, but since I couldn't SSH directly to them, I had to find a way to tunnel the SSH over Tor.

Again, I knew this was possible from previous reading, but hadn't ever had a need to do it.  After a little bit of Google-fu (Startpage-fu doesn't quite have the same ring to it...), I connected with this command from tor.stackexchange.com/a/127:

$ ssh -o ProxyCommand='nc -x localhost:9150 %h %p' -l <username> <public VPS IP>

The connection was stable, but very laggy due to the satellite link, bouncing around Tor, then running on a VPS with a single core and 512 MB memory.

Now that I had access to the VPS, it was time for the proxy software. &nbso;After a little more research, I decided to use ICMP tunneling and used "Hans."

On the Server (Ubuntu 14.04 LTS)

Download and compile the Hans source.

Invent a new subnet (10.140.100.x) and password (freewifi) for the tunnel.

$ sudo ./hans -s 10.140.100.0 -p freewifi

This will give the server the ".1" address in this new subnet and start the ICMP listening service.

On the Client (Mac OS X)

Download the Hans binary.

Download the prerequisite OS X tun (virtual network interface) driver.

Launch Hans.

$ sudo ./hans -c <public VPS IP> -f -p freewifi

In another terminal, test out the connectivity:

$ ping 10.140.100.1

Success!

The only thing that stood in the way of full, open Internet access was routing the traffic over this new tunnel.

I considered two options on how to do this: updating both the client and server routing tables; or setting up a proxy server.  I considered the routing table option to be too risky since I could potentially lock myself out of the remote server and would have no way to revert the changes.

Install and Configure Squid Proxy

How to Setup "Squid Proxy" Server on Ubuntu and Debian

$ sudo apt-get install squid $ sudo vim /etc/squid3/squid.conf

Pay special attention to the following options:

acl localnet src 10.0.0.0/8 # use the new subnet you used in the hans command above acl SSL_ports port 443 # without this, you'll only be able to use the proxy for HTTP

Configure Firefox on OS X

"Preferences" > "Advanced" > "Network" > "Settings"

"Manual Settings" > 10.140.100.1 and port 3128 for HTTP and HTTPS

I tried to browse, using www.2600.com.

Success!

I double-checked that the traffic was going out via the proxy (using ifconfig.me).

Success!

In order to keep a low profile, the tunnel was shut down when not in use.  Also, large files were not downloaded or uploaded.  Now that this puzzle was complete, I closed the lid on my laptop and headed down to our favorite bar on the fifth level.  To celebrate, I ordered myself a Jameson Whisky Sour (or maybe it was a White Russian?) and shared my success with my travel mates.  They were impressed, and posed a good question: Could I make it work on their iPad?  The next puzzle in the series had been discovered.

A day or two later I found myself still thinking about how to provide access to an iPad.

I found a product called SquidMan for OS X.  It's a GUI tool that lets you run a Squid-based proxy on your local machine.

I downloaded, installed, and configured it to use a parent proxy (using the ICMP tunnel IP above) and fired it up.

OS X prompted me for permission to allow inbound traffic for the application, and I approved.  I grabbed my phone, set the HTTP proxy to "manual," and input in the local IP of my laptop and port 3128.  I flipped over to the mobile browser and once again was able to load HTTP and HTTPS sites.

Puzzle number two was complete and it was getting late.  I shut down for the night, feeling victorious and wondering what puzzles awaited me in the morning.

For the remainder of the trip, I managed to spend the majority of the time disconnected.  There are always more puzzles to solve, but my time with these people at this magnificent location was running out fast.

The ship's network had numerous issues, and in an effort to relax (and stay out of trouble), I didn't pursue any of the other puzzles presented.  The puzzles not explored include a combination of the following:

Wireless clients could talk directly to each other.

Captive portal was presented via HTTP on the same subnet as the clients.

The wireless subnet had a /18 bit mask (16,382 hosts, or 64x bigger than a standard /24 subnet).

The logout page was hosted on the same IP as the captive portal.

Fun with proxies, e.g. Upside-Down-Ternet

Shout out to: Ch0wn35