Slipping past the hotel login page with some simple tunneling tricks

Tunnel Vision


The experts have been saying for years that blocking well-known ports is not a real security solution, yet the myth persists. This simple experiment by an inquisitive road warrior is a cautionary tale for anyone who has ever had the urge to take a short cut on network security.

By Tobias Eggendorfer

Aleksandar Jovanovic, 123rf

Anybody who spends time on the road with a laptop, as I do, is probably familiar with the downright cheeky prices charged for Internet access by most hotels. WLAN use sometimes accounts for a quarter of the hotel bill, and this really bugs me, especially because I have to pay for it out of my own pocket.

One fine evening a while ago, while I was staying in the Munich branch of a well known hotel chain, an inquisitive urge suddenly replaced my annoyance. These access systems, it occurred to me, can't be all that sophisticated. After all, the approach is fairly simple.

Until your own MAC address is approved for billable use of the Internet, all web access is redirected to a startup page.

The company that handles the tech support for the hotel uses a fairly primitive approach to blocking IMAP, IMAPS, and POP ports. When I tested this system with an IMAP server, I noticed that the client actually established a connection to the target system.

However, as soon as this connection was up, the response data couldn't get back to it. This behavior causes most mail clients just to give up in desperation.

While I was investigating the system, I had a spot of luck: Although I wasn't registered for billing, my instant messaging client suddenly went online, and I found I could exchange messages with friends.

Was this just a tiny glitch or a vulnerability in the system? My IM client doesn't use port 5190, which is used for most IM protocols. Instead it uses port 443. Setting the IM protocols to the HTTPS port (port 443) has often turned out to be useful on trips for working around pesky firewalls.

HTTPS is normally open no matter how restrictive the connection is, assuming you register for billing. But at the hotel, I hadn't even done that! I had a sneaking suspicion that the HTTPS port 443 wasn't being routed via a proxy but was, instead, provided direct access. Soon I discovered that my suspicions were correct: If I used HTTPS, I wasn't taken to the usual startup page.

Be Prepared

When I got back home, I decided to prepare for my next stay in a hotel. I needed an HTTP proxy on a server somewhere on the Internet that would accept traffic on port 443. This is easily written in Perl using the CPAN HTTP::Proxy module.

After installing the module with CPAN,

perl -MCPAN -e 'install HTTP::Proxy'

I followed the example in the code for HTTP::Proxy [1] to create the mini-proxy shown in Listing 1. However, this simple solution suffered from a couple of issues. For the program to be able to open port 443, it has to run with root privileges. For security reasons, this is not a good idea for a permanent setup; my home-grown server application would be a sitting duck out there on the wild and woolly Internet. Also, the computer would only serve as a HTTP proxy - an unnecessary restriction.

Still, launching the beast by typing ./http_proxy.pl & would do for initial local testing. Then I entered my server's IP address in my browser as my HTTP proxy. Serious browsers let you use different proxies for different protocols, but you only need to set up the HTTP proxy. The fields for the other protocols, and especially for HTTPS, must be empty.

Listing 1: http_proxy.pl
01 #!/usr/bin/perl
02 use HTTP::Proxy;
03 my $proxy = HTTP::Proxy->new( port => 443);
04 $proxy->start;

Digging a Tunnel

My experiments with the proxy went well, but I was looking for a superior approach that would work with more than just HTTP. The way to do this was clear; I needed an SSH tunnel where my laptop would act as a client, set up an SSH connection to a server on the Internet, and forward a couple of ports as needed.

To let SSH listen on the HTTPS port in addition to port 22, I just added a Port 443 line to /etc/ssh/sshd_config and then did this to enable the hook:

kill -HUP `cat /var/run/sshd.pid`

SSHD can be configured to accept SSH connections on multiple ports at the same time. In my case, this was useful because I share my SSH tunnel entry machine with a couple of colleagues, and I didn't want to let them in on the planned port manipulation.

Now I needed to move the proxy from port 443 to, say, the port suggested in the sample code, port 3128, which can be used on the server without root privileges:

ssh tunnel.example.com -p 443 -L48080:localhost:3128 -f './http_proxy.pl &'

This line tells SSH to connect to port 443 on the specified computer then run the Perl script when it gets there. SSH will also establish an encrypted tunnel from the local port 48080 to localhost, as seen from the remote SSH server, port 3128. The -f option sends the SSH client into the background before the command executes and after the password has been entered, whereas & would send SSH to the background immediately. Now I can enter the HTTP proxy as localhost 48080 in my browser (Figure 1).

Figure 1: After drilling the tunnel, road warriors need to enter the HTTP proxy.

On the Road Again

Back in the hotel in Munich, I just had to try this out straight away. As I hoped, the SSH client and server connected via port 443, and tunneled a way through the restrictions, and I could surf the Internet for free.

Of course, you could extend this approach to access email:

ssh tunnel.example.com -p 443 -L48080:localhost:3128 -L60110:pop.example.com:110 -L60993:imap.example.com:993 -L60025:smtp.example.com:25 -f './http_proxy.pl &'

Using an SSH tunnel to receive email via unencrypted protocols such as POP3 is useful anyway, and anybody who travels frequently should do this. You can also protect SMTP authentication using an SSH tunnel. At the same time, you can avoid the spam blocker for external SMTP servers that some providers install.

Alternatives

As you have seen, I took the SSH server approach for my experiments, but I could have chosen something else. For example, typing

ssh tunnel.example.com -p 443 -X -f '/usr/local/mozilla/mozilla &'

launches Mozilla on the remote machine and surfs in server-based computing style. But the sheer volume of traffic that you need to transfer to surf the web makes this experience no fun. Redirecting the more classy protocols used by VNC or NX [2] to 443 would make this approach faster.

You could also have an OpenVPN server listen on TCP port 443 at home. OpenVPN can tunnel a whole network via one TCP or UDP port, so you could connect your laptop to your home network. OpenVPN could also collaborate by redirecting all network traffic over VPN [3].

What Providers Can Do

How could the provider have avoided this problem? As far as I can tell, the system makes major use of proxies that differentiate between paying and non-authorized users by checking their IP or MAC addresses. A simple firewall would improve the situation by blocking all ports for guest computers until the guest paid. This would not help combat guests sniffing IP addresses and MAC addresses to hijack other guests' connections. But, this problem is one that the existing system also suffers from. Complexity and security are not always the same thing. I informed the hotel immediately after completing my test. The desk clerk at reception promised to tell the provider, and lo and behold, the next time I visited Munich, the hole was patched.

INFO
[1] HTTP::Proxy: http://search.cpan.org/~book/HTTP-Proxy-0.24/lib/HTTP/Proxy.pm
[2] "Remote Terminal Service with NX" by Markus Feilner, Linux Magazine, December 2007, pg. 28, http://www.linux-magazine.com/Issues/2007/85/FASTER-X
[3] OpenVPN HowTo: http://openvpn.net/index.php/open-source/documentation/howto.html
THE AUTHOR

Tobias Eggendorfer is Professor of Applied Informatics and IT Forensics in Hamburg and a freelance IT consultant focusing on security. Not even the tasty mini-sausage the hotels in Munich serve him for breakfast can make up for the exorbitant pricing of Internet access.