Vulnerabilities in Subscription Wireless

by wishbone

Most hotels, cruise ships, and cafes use the same techniques for host identification on their subscription wireless service.

Every single wireless service I have come across thus far all have the same OSI Layer 2 vulnerability in their host identification.

It's unfortunate that developers ignore Layer 2 security far too often.  Or worse, they think it has some kind of security by obscurity benefit.

The method I will describe here will normally only work on wireless connections because it is difficult to implement physical hardware controls on a wireless medium.  It will work on any wireless system that use the MAC address as the only authentication mechanism after the initial service purchase.

This includes most hotels, Internet cafes, and cruise ships that offer wireless connections.

There are major flaws in assuming that Layer 2 inherently has any kind of security.  There certainly are options at that level (802.1x for example), but currently the technology hasn't reached maturity yet for the masses.

Most of these systems close everything but port 80 to unauthorized machines, which is automatically forwarded to their gateway page for user authentication.

Once the user authentication is given and the purchase plan is chosen it will automatically allow all of your connections to pass.  The auth system sends a message to the gateway or access point to tell it that your mac address is authorized for access.

Some of these systems differ in how they authenticate or what kind of hardware they use.

However, all of them rely on one simple fact; you have a unique MAC address that no one else can use.  I do honestly hope that isn't what they were thinking when the system was designed, but there seems to be no additional security beyond Layer 2 after the web authentication has taken place.

The method I will outline here is simple MAC spoofing technique.  Which is as easy as changing your IP address.

For the first step you'll need to do some passive snooping of the airwaves.

There are several good utilities these days out there for this, but I prefer Kismet on Linux.  Kismet really gives you a lot of information including full-packet capture of everything you see.  If you're not familiar with war driving or wireless reconnaissance, do a search.

You'll find lots of help out there on the subject.  You might want to just turn your particular wireless data capture program on and walk around the area for a few minutes.  This will allow you to capture lots of data that you'll need to use for later.

If you're using Kismet, re-sort and view the info of the particular wireless network you think might belong to the provider you are trying to gain access to.  This is important because you need actual data packets from subscribed users and not just LLC or broadcast packets from network equipment.

Once you've captured enough packets and scoped out the available wireless networks you can move on to investigating what you've found.

Next, we need to find a MAC address of a machine that is authorized to use the Internet connection from the data we've collected.

At this point if you're in a major city you might already see completely open networks that allow outbound Internet traffic and are even nice enough to supply an IP to you via DHCP.

If so, great.  If not, find the packet dump from Kismet or another packet capture program and open it for viewing.

Ethereal can be very helpful here as it has a very nice browser for looking at packets and an incredible breakdown of every layer.  It will present this info in easy to read expandable menus.  What you are looking for here is someone who has already paid for service and is using the wireless connection.  This is where those data packets will come in handy.

I like to start with the ARP packets because they always sort to the top easily and give me lots of information about what addresses are on the network.  However, any data packet on the same network will work.  Choose one of these packets, expand the Layer 2 information (IEEE 802.11 in this case), and look for the source address (MAC).

You'll need to find a MAC of a device that is not the default route and hopefully not some other network device.  In order to make sure the device is what you want, try to find other packets from the same source IP or MAC and verify that it is a real customer.

You can easily identify this from the porn web surfing or various chat networks.  You'll probably even see some passwords in there from various authentication attempts.  Being the curious but responsible people we are, we will login to these accounts and let them know that they should change their password to nothing, since a blank password would be almost as secure.  I suppose you could also simply leave them alone to wallow in their ignorance.

Now that you have a MAC address you believe will provide you with the access you seek, you'll need to borrow it for a little while.

This is where MAC spoofing comes into play.  We need to change our hardware address to match that of the person who is already authorized.

In Linux this is a very simple thing to do.  Issue the command: ifconfig INTERFACE_NAME hw ether MAC_ADDRESS

With INTERFACE_NAME being the name of your wireless interface and MAC_ADDRESS the new MAC address you wish to spoof.

See Google/Yandex for other operating systems on how to do this.

After you verify that your changes have taken you'll need to connect to the wireless network you wish to gain access to.  This can vary across platforms and hardware so see your hardware's and driver's documentation for information on that.

Finally, run a DHCP client to request an IP address for the wireless interface.  It should respond immediately and you should notice that you now have the same IP as the host you wish to spoof.

ping the default gateway and verify network connectivity.

Congratulations, you're now able to send out packets that appear to be coming from the same host!  Keep going onto the next section even if the ping does not work.

Some systems do actually block ICMP to the default route.  You may try to ping some other host you noticed from your earlier scans to do additional verification.

At this point you are breaking a major TCP/IP commandment.  "Thou shalt not have the same IP or hardware address in the same broadcast network without suffering a bloody byte battle."

Both you and your target will now be battling it out for the rights to those addresses.  The great thing about Linux is that it will just keep on chugging even if it sees someone with the same hardware or IP address.

Most M$ platforms aren't as lucky.  Some may even shut down their stack if they detect IP collision.

Try to browse to something fast, google.com for example.  This will test if you have grabbed the identity of a machine that is already authorized to use the Internet.  If the site comes up then you're "In the butta zone baby."

You may get a blank or timed out page on the first try.  Keep in mind that both machines will be receiving packets from each other's network connection requests.

Each machine will be confused by the answer from connections they never asked for.  When this happens, you'll see the other host reset your connections for you.

Just keep trying until you get something though.  Sometimes it works right away, sometimes it takes a few reloads.  If the local auth page comes up, then there could be several issues.

It's possible they have not yet authorized their connection, or they decided not to after reading the terms and available plans, or maybe their connection has already timed out.

You have a couple of choices here: You can either wait and see if they do authenticate or try another MAC address you believe that might have access.

Now that you've seen it work, just give the connection back and find a free wireless connection somewhere.  There are plenty of those around.

Otherwise you'll be fighting for the connection until one of you gives up.  I found that protocols like web or ICMP will work well even with address collision, but persistent connections, like SSH or FTP, have a lot of trouble.

This example is meant to demonstrate the issues of using a public hardware address as the main authentication mechanism on a wireless network.  It is quite easy to perform a denial-of-service on the authorized machine at this point in order to win the conflict, but that isn't the intent of this article.

There are several things that might make these systems more secure.  The difficulty here is the identification of a particular machine.  It's obvious that MAC address isn't going to work as a unique identifier.

A completely different identification mechanism needs to be selected or another layer of authentication needs to happen on a more regular basis.

As always, please use information responsibly, remember that knowledge is power and those that abuse power do not deserve knowledge.