Enter your email address to be notified of new blog entries:
03/07/2007 - 3:50am
del.icio.us
This HOWTO is monitored regularly. If there are any questions, comments, suggestions, or additions, feel free to post them here.
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.
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.
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.
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:
And the client configuration:
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:
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:
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.
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.
Add Comment
HOWTO: Using the Starbucks/T-Mobile Network Without an Account
del.icio.us
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.
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.
Add Comment
Copyright 2004-2008 Arizona Paths
