Enter your email address to be notified of new blog entries:



03/07/2007 - 3:50am

HOWTO: Using the Starbucks/T-Mobile Network Without an Account


    del.icio.us

This HOWTO is monitored regularly. If there are any questions, comments, suggestions, or additions, feel free to post them here.

Introduction


This concept was created and proven by myself (Nick Coons) and Christopher Lewis (aka "shadow"). We'll start off with a standard disclaimer. Setting this up involves connecting to and using the Starbucks/T-Mobile wireless internet service without a valid account. Doing so may be against their terms of service, and in certain jurisdictions may be illegal. These procedures are intended to be a proof-of-concept. If you implement these steps, you take full responsibility for the consequences of your actions.

Concept


Now, on to the fun stuff. We've found a vulnerability in the Starbucks/T-Mobile network that allows us to connect and use the internet service without having an account, without a brute-force attack to uncover another account's credentials, and without spoofing a valid user's MAC address.

Upon our initial connection to their network, we found that all of our web traffic was redirected to their login page, and all other traffic was blocked, except DNS. We were able to fulfill DNS queries for external domains. To verify that this was not just being handled by an internal DNS server, we made queries on our own servers and were allowed to connect and receive the response. By scanning through server responses and various tests with nmap, we knew that we weren't going through a DNS proxy, but instead making DNS queries directly to external servers, something that the Starbucks/T-Mobile network seems to allow. Knowing that we could now get traffic out on UDP port 53, we believed we could use OpenVPN on UDP port 53 to establish a connection, then redirect all internet traffic over the VPN. This document will explain how to do exactly that.

Prerequisites


You will need the following:

- Your laptop, or other wifi/wireless-enabled device to connect to the Starbucks/T-Mobile network.
- An internet connection at a remote location (i.e. your broadband connection at home).
- A system on your remote internet connection that can act as a VPN server.
- OpenVPN installed on both of the above machines, along with a basic understanding of how OpenVPN works and how to use it.

Configuration


First, you'll want to generate your keys. The specific procedure for that is outside the scope of this document. Those steps can be found at the OpenVPN website.

Next, here is the server configuration, which I've placed into /etc/openvpn/server.conf on my own system:

port 53
proto udp
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
ping-restart 0
user nobody
group nobody
persist-key
persist-tun
log /var/log/openvpn
verb 3

And the client configuration:

client
dev tap0
proto udp
remote [server] 53
ping-restart 0
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client.crt
key /etc/openvpn/keys/client.key
verb 3

Replace [server] with the hostname or IP address of your OpenVPN server.

Notice the option "ping-restart 0". Normally, the OpenVPN client pings the server periodically to make sure that the server is still there. If there is no response, it disconnects and can attempt to reconnect. The problem with leaving this at default is that the Starbucks/T-Mobile network (from our experience) does not allow pings. The client will believe that it lost the server and drop the connection, then try to re-establish it, leaving you with a broken connection for a few seconds every couple of minutes as it tries to re-establish a connection that was never actually lost. This option prevents the client from performing this periodic ping test and just assumes that the server is always there.

Once these configuration options are in place, you can now start OpenVPN. But here are a couple of things to watch out for:

Potential Pitfalls


DNS Issues
Once you're connected to the VPN, all of your internet traffic will be routed over the VPN, except the traffic specifically needed to keep the VPN active (or more accurately, the traffic specifically destined for the VPN server's public IP address). From our experience, the Starbucks/T-Mobile name servers are not accessible from the outside, and technically you would be connecting into them from the "outside" over your VPN. So upon connection to your VPN, you may lose DNS. There are a couple of ways to solve this:
  • Use a free public recursive DNS service, like OpenDNS.
  • Use your remote internet location's ISP's name servers.
  • Install a DNS server on your laptop and use it.
  • Install a DNS server on your VPN server and use this one.
With this last option, you'll need to be careful. UDP port 53 is already bound to OpenVPN, so it cannot be bound to a DNS server. But you can install a DNS server that will bind itself to UDP port 53 only on OpenVPN's "tap" interface, and then use this IP address as your name server.

For each of these options, you'll want to configure the OpenVPN server to push the DNS information over the network so that your laptop will automatically be reconfigured to use this information once the VPN connects. To do that, use this directive in your server's OpenVPN configuration file:

push "dhcp-option DNS 1.2.3.4"

...where 1.2.3.4 is the IP address of the name server you wish to use.

Network Managers
This is another area where attention must be paid. With desktop network managers such as those that come with KDE or GNOME, they like to re-write your /etc/resolv.conf file periodically with the name server information provided by the DHCP server, which would undo any custom DNS settings you've provided via the OpenVPN configuration. Make sure you modify your network manager to avoid this.

Conclusion


Once you're connected and your DNS issues have been resolved, you should be up and running. Services such as web, email, or even other VPNs should work just fine. Note that the overall performance will be degraded somewhat as all traffic is being routed over UDP packets and making several extra hops as it must all go through your remote internet connection.

Have fun with this setup. It was an interesting proof-of-concept project. If nothing else, we hope it will make system administrators more aware of their networks and plug up potential security holes.



Comments
Add Comment

Posted by: Carl-Erik
05/16/2008 11:45am

Thanks! Sitting at Starbucks in Vienna, Austria at the moment, and this was just what I was looking for. To bad my ISP filters out all connection attempts < port 1024... Well, nice to know, anyway!

Posted by: Bill
10/11/2008 4:27pm

the ping or ping-restart option in openvpn only pings the vpn server over the TCP/UDP control channel (with in this case would be port 53) so there should be no reason to disable this.

Posted by: Nick Coons
01/24/2009 2:54pm

Bill,

The reason I noted this in the HOWTO was because it wasn't disabled initially. When it was first enabled, I lost the connection like clockwork at about two minutes (I don't recall the exact timing, but it was the same every time). Once it was disabled, that problem was solved and I could maintain a persistent connection.

Posted by: Anon
03/03/2009 9:54am

nice,you can also use this <a href="http://world-secure-channel.com/why/">vpn</a>

Posted by: Nick Coons
03/03/2009 9:56am

Anon,

Actually, no you can't. The VPN solution you provided uses PPTP or L2TP. The specific reason the solution suggested in this blog post works is because it uses UDP port 53, making the Starbucks network believe that it is DNS traffic which is then allowed. You VPN solution would not be able to establish a connection.

Posted by: Bill
03/03/2009 10:50am

http://alwaysvpn.com/
This openvpn provider has udp access on port 53.

Posted by: Nick Coons
03/03/2009 10:52am

Then that should do the trick. However, given that it's a paid service, it may be simpler just to pay for the Starbucks connection :-).

Posted by: beakmyn
06/03/2009 5:01am

Per the DNS options. It appears that I have DnsMasq running on my server machine, which I assume is occupying port 53. Since OpenVPN can't start right now because port 53 is being used. Note: OpenVPN has already been configured and was previously running on 1134 so it's been validated.

This machine is setup for just the VPN and some file sharing. I have my DSL router perform DNS to OpenDNS servers. So, would the better option be to set dnsmasq's port =0 or completely disable dnsmasq? I've already got the push DNS to 192.1268.254.254 (DSL router).

Posted by: Nick Coons
06/03/2009 8:29am

You'd want to disable dnsmasq completely. If you moved it to another port, it would be pointless to even have it running since nothing could use it.

Posted by: alu
09/29/2009 11:45am

Some people might needto run : # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source <eth0-ip>

Posted by: guardianx
12/11/2009 5:13pm

does this trick still work.. i tried it at 12-12-2009 and it doesnt work. when i tried to connect via port 53 it doesnt work.

did they fix the trick. dns tunneling still work tho.

Posted by: Nick Coons
12/11/2009 5:36pm

I haven't tried it recently since I now have a mobile connection via Sprint whenever I'm somewhere that doesn't have free wifi. I would imagine that if DNS still works that this would still work as well, unless they're examining packages that come through port 53 to make sure that they are actually DNS packets.

Posted by: guardianx
12/11/2009 5:38pm

i validated the connection on port 1194.
but when i change it to port 53 and connect it via starbuck. the connection fail to complete. i guess starbuck fix the problem. but dns tunneling still work but too bad dns tunneling is uber slow.

Add Comment





Copyright 2004-2017 Arizona Paths

Arizona Paths Weather Button