Get Personal, Gogo

Last Sunday I took a flight equipped with Gogo in-flight WiFi so that I could work in an office with guest WiFi. The difference in security was stark, and Gogo should make changes to fix their poor (and, in my opinion, negligent) WiFi security.


Gogo in-flight WiFi is a service that I've blogged about before, but I feel compelled to mention it again because the security problems I complained about a year and a half ago are still there even as hacking knowledge and applications have grown. To recap Gogo's poor security design:


  • Open System authentication with no encryption is used for Gogo's WiFi security. This means that applications like Firesheep allow hackers to do sidejacking attacks, like the one that seems to have been performed on Ashton Kutcher recently. 
  • Captive Portal authentication is used to charge passengers for Internet access. This means that anyone who knows how to spoof a MAC address (link is for XP, but the same can be done in Vista/Win7 via the Networking and Security Center) can wait until someone buys Gogo's service and then use the purchaser's MAC address to piggyback on the service for free.
  • Since Open System authentication is used, any device that sends Probe Request frames when looking for WiFi networks will become vulnerable to an Evil Twin AP attack from applications like KARMA the moment the device leaves the plane.
All of these problems have been well known, but the implicit justification from providers of paid WiFi service is that, A) the network must use Open System authentication in order to allow the largest possible number of users to potentially pay for the service, and B) users can always setup their own SSL encryption using services like WiTopia (there are other SSL services, but I tout WiTopia because I use it and I've been very happy with their service and support). This justification is balderdash. On the latter point, it is negligent (in my opinion, to the point where they deserve to be legally liable) for such a large service provider to force their users to provide their own way of even the most basic security. I think that this would be akin to Target allowing their parking lots in Milwaukee to ice over in the winter, and then posting signs telling their patrons to bring a bag of salt so that they don't break their elbow on their way in to buy a Tassimo

The point about Open System authentication being necessary to allow the largest number of potential customers to access Gogo in-flight WiFi used to be a good one, but the guest network at the office I'm working at this week is evidence that Gogo needs to change. In this office the guest WiFi uses a Preshared Key (PSK) passphrase that matches the SSID of the network. This makes it easy for guests to remember and even allows people to make an educated guess if they miss the official notification that the guest WiFi network is using encryption.

WPA/WPA2 Personal (the Wi-Fi Alliance's name for PSK-based networks) solves the fundamental problems with Gogo's current security plan. To wit:
  • Applications like Firesheep don't work because each station negotiates a unique AES-CCMP or TKIP encryption key after association. Even if an attacker knows how to decrypt frames in a protocol analyzer, it wouldn't work with Firesheep because Firesheep uses promiscuous mode and protocol analyzers use monitor mode when decrypting frames.*
  • The captive portal would be more secure because each station MAC address would be tied to the AES-CCMP or TKIP encryption key that was negotiated after association. If an attacker spoofed a MAC address, they would get no access because the attacker would lack that unique encryption key.
  • Stations that send probe request frames would be more secure from Evil Twin AP attacks because they would not automatically associate to an open network that uses the SSID of "gogoinflight". Evil Twin AP attacks would still be possible, but only if the attacker is able to create an Evil Twin AP that uses the correct PSK passphrase. Currently KARMA does not do that.
Do the right thing, Gogo. Add a PSK passphrase of "gogoinflight" to the SSID of "gogoinflight" and then run the captive portal after users have created that AES-CCMP or TKIP encryption key. Or heck, just create a second SSID of "gogosecure" with a PSK passphrase of "gogosecure" so that we at least have the option of thwarting Firesheep attacks and you have less MAC addresses that can be spoofed. There may be some initial pains while that type of change is made, but it'll probably cost less than a lawsuit if anyone ever loses anything really important while connecting to your poorly (and, I would argue, negligently) secured WiFi service.

*Decryption can be done by attackers if PSK passphrase (WPA/WPA2 Personal) authentication is used, but it can only be done on one station at a time and currently available software only does it to TKIP-encrypted frames (meaning not AES-CCMP encrypted frames). -I was wrong. CommView for WiFi and Wireshark both now decrypt AES-CCMP encrypted frames. That's what I get for avoiding mediocre sniffing software. :)

Comments

  1. 3."The captive portal would be more secure because each station MAC address would be tied to the AES-CCMP or TKIP encryption key that was negotiated after association. If an attacker spoofed a MAC address, they would get no access because the attacker would lack that unique encryption key." – I'm puzzled. Exactly how is this going to work? A legitimate portal user might close the notebook lid. When he reopens it, he gets associated again, right? And the captive portal doesn't mind that. So when you spoof a MAC address, your PC becomes an exact replica of the victim. You send a deauth frame using Wireshak or CommView for WiFi, which is basically "closing the lid" on behalf of the victim, and then you associate. If the victim cannot connect a minute later is not your problem. It becomes his problem.

    I agree that using WPA-PSK on any public hotspots is a great idea simply because typically, there are very few hackers around. You get at least some security. Additionally, the hacker must be pretty close to the victim to capture all EAPOL packets undamaged. But that's security through obscurity.

    NetMind

    ReplyDelete
  2. Ben,

    Your blogs posts are usually impeccable from the technical standpoint (although I sometimes disagree with them ideologically.) But this one if full of factual mistakes. I hope you don't mind your readers correcting them:

    1. Changing MAC in Windows. No, it cannot be done in Vista/Win7. Since Vista, Windows restricts the choice of client-configured MAC addresses. You can't spoof just any address; Windows restricts what you can use as the first byte. You cannot use 00 (but you can use, for example, 02 or 04), which in practice means that you cannot spoof addresses of 99% of all existing Wi-Fi adapters.

    2. Regarding the decryption footnote (no concurrent decryption, no AES) – I don't know where this info comes from. Just look at http://wiki.wireshark.org/HowToDecrypt802.11 and http://www.tamos.com/htmlhelp/commwifi/wepkeys.htm. There are at least two tools that can easily decrypt AES-CCMP frames. As for one station at a time, I didn't try that in Wireshark, but I tried that in CommView for WiFi, and no, there is no such limitation, as long as you capture all the EAPOL handshakes, you can decrypt all WPA2-PSK traffic in real time.

    ReplyDelete
  3. Interesting comment. You can change MAC addresses to any string on certain adapters. I had to use an external USB adapter (WUSB600Nv1) last time I was testing it. I was unaware that CommView now supports AES-CCMP decryption, and I'll change that in the post. On the third point I see what you're saying, but I still don't see how the hacker gets access. Why would the authorized station stop associating/creating PTKs? As long as they do the hacker would never keep a vaild PTK for long enough to access the network.

    ReplyDelete
  4. About PTKs. Suppose the lid is closed. STA disassociates from the WLAN. When you reopen the lid, it associates again, and a new PTK is generated. Now, suppose a legitimate user is reading a web page he's just loaded. The notebook is "silent", no packets are being sent. You sit next to that user and send a deauth frame with the source MAC address of the AP. Then *you* associate (having set the victim's MAC as your adapter's MAC.) From the AP's point of view, you're as good as the victim. You and the victim cannot be distinguished. You perform an EAPOL handshake, get a new PTK, and Bob's your uncle. All that happens while the victim's adapter is disconnected (because you "deauthed" it a few seconds ago.)

    ReplyDelete
  5. I'm sorry Ben, I can't fight with this broken comment posting thing here any more. It doesn't accept long comments, if you split it deletes the first one, and when you finally manage to post all you wanted to say, one of the comments vanishes in 5 mins. I'll wait until you move to a better blogging platform.

    ReplyDelete

Post a Comment

Popular posts from this blog

Five Facts About 6 GHz Wi-Fi

Chips, Glorious Wi-Fi 6E Chips!

Go To Sleep, Go To Sleep, Go To Sleep Little iPhone