Hotel Internet and ISP Paywalls

So, I’m currently in a hotel, to remain nameless here, for BlackHat 2009 and DefCon 17. As is usual for expensive hotels, Internet access is available — both wired and wireless — for a substantial fee ($13.99/day here.) This is enforced via a paywall.

For anyone who has never tried to use Internet in a hotel, the way this works is as follows:

  1. You connect to the wired or wireless network, and are assigned an IP address via DHCP.
  2. All Internet connections are directed by the gateway to the same IP — one that rejects everything but ports 80 and 443, and redirects those to a web page that asks you to confirm your acceptance of the exorbitant fees and provide your room number.
  3. Once you accept the terms, the redirect goes away and you have unfettered access to the Internet, usually via a true Internet-routeable (not RFC 1918) IP.

Now, for me, the first thought I have is, “How have they implemented this? Doing it ‘for real’ would require tons of custom hardware and software! Surely they took shortcuts.” So, I booted into BackTrack 4, fired up Wireshark, and took a look around on the wired network.

The first thing I noticed was that, for the most part, all the traffic I was seeing was my own. So at least this wasn’t some kind of dreadful 1990’s-era shared-backbone network. However, there were two exceptions to this rule — ARPs, and DHCP Offers and ACKs.

So, what can we learn from this? We’re on the equivalent of switch-based Ethernet, where the only traffic that reaches our PC is that destined for our MAC address. The switch remembers which MACs are one which ports, and won’t forward us anything that doesn’t correspond to our MAC. We get ARPs and DHCP because those are sent to the Broadcast MAC — switches forward them to everybody. This tells us one avenue for attack — we can get other traffic routed to us by sending out packets with a spoofed MAC. If the switch learns that a given MAC is on our port, it will start sending us the traffic for it.

But that’s not useful. MACs are 48-bit numbers; I’m certainly not going to start guessing them. What’s probably of most interest to people on hotel Internet is how to get it without paying, not how to route others’ traffic to themselves. Okay, at BlackHat and DefCon, routing others’ traffic is probably of interest, but not generally.

But this tells us another avenue for attack, too. If we’re receiving broadcast traffic meant for others (presumably other hotel rooms) on switch-based Ethernet, then this means that the system doesn’t have the ability to send the DHCP and ARP traffic to only one room! If it were really designed securely, it would — there would be point-to-point traffic to each room. Since there’s not, then it must simply be addressing traffic to each room and putting it into a switch.

We have a clue as to how it addresses traffic to the room. The charge of $13.99 per day is per laptop — that is, if you use multiple machines, you have to pay for each of them. This policy is clearly daft — it seems very unlikely that the hotel expects anyone to actually pay the fee 2-3 times per day, and so all it does is curtail usability for no reason. Which means that it’s likely a technical limitation — which is to say, they’re identifying unique customers by MAC address.

MAC (Media Access Control) address is assumed by most people to be static. It comes with your network card, and whatever MAC your card has is the one you have for life. And in Windows, this is true with most network drivers — they provide no facility to change your MAC. On a Linux such as BackTrack, though, this assumption is wrong.

The easiest way to get free access on a hotel network, then, is to just use the MAC of someone who already paid. We fire up Wireshark, and add a filter excluding our own IP, such as:

ip.src != && ip.dst !=

Where is the IP we get from ifconfig. This should filter down to nothing but DHCP offers & acks. We then pick any random DHCP ACK, and open the “Bootstrap Protocol” node, where we find a line labeled “Client MAC address.” This will list the address, both in the form that enumerates the manufacturer, and in the form we want — six colon-separated octets (e.g. 00:11:22:aa:bb:cc).

Now we just tell the system that we are, in fact, someone else. This is a simple task in Linux:

macchanger eth0 00:11:22:aa:bb:cc
/etc/init.d/networking restart

Now we’ve just changed or MAC to someone else’s, and requested a new IP address. But, how do we know that the MAC we changed to is any better than our own? Well, it stands to reason that if someone is connecting to the hotel network, they intend to access the Internet. If the ACK is brand new it may not work, but anything more than a few minutes old is probably golden — and if it’s not, you just pick a different DHCP ACK out of Wireshark and try again.

Drawback to this method: it is possible, depending on how the hotel runs its network, that you just DOSsed the legitimate user, which is clearly undesirable. It’s not likely, though — the gateway probably just redirects users who aren’t on a MAC whitelist to the paywall, and lets everyone else through. The switch is now routing that MAC to two different rooms, each of which have their own IP, and apart from occasional glitches from layer 2 or 3 collisions, it will probably work fairly well. Nevertheless, don’t fool yourself into thinking this sort of thing is totally harmless.

From the hotel’s perspective, this sort of thing is not trivial to foil. If they want to prevent this from happening, they need a way to address rooms, not laptops, and that means assigning a switch port or IP address to each one rather than doing a continuous dynamic re-provisioning. This is expensive… probably much more expensive than just allowing the occasional network-security geek with a Linux install bypass their paywall.

attacks, authentication

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.