Chiggity-Check Your Phone (With a Sniffer)

It should come as no surprise that many WiFi-enabled mobile phones sometimes exhibit behavior that makes them vulnerable to attack. In at least one case, you can use a WiFi sniffer to view such behavior so that the proper changes can be made to your phone.


When a WiFi device associates to an access point, it must first go through the process of Discovery so that it can decide which AP is best (based on SSID, signal strength, etc.). Discovery is done either by listening for Beacon frames or transmitting Probe Request frames in hopes of eliciting a Probe Response frame. The Discovery process reveals the same information about an access point (SSID, channel, rates, security, etc.) whether it is through a Beacon or a Probe Response, it's just that the probing process can be faster because the station can initiate it at any time.

The problem with the Probe Request/Response sequence is that it could lead to an attack. Hackers running sniffing software (for the types of nefarious purposes not advocated on this blog, that is) may view the SSID carried in the Probe Response as a way of figuring out what networks a station is trying to connect to. Hackers may then search for that SSID at wardriving sites like wigle.net (perhaps trying to find out where you live or work) or create an Evil Twin access point in hopes of causing your station to make a direct association to the hacker's laptop. Katy, bar the door if that happens. A hacker that has an unsuspecting station associated to his Evil Twin access point can attempt all sorts of attacks, as has been shown over and over again.

To prevent such post-Evil Twin access point attacks from occurring, it is wise to disable the sending of Probe Requests in station devices, especially if those devices don't need the faster reassociation that those frames were designed for. In Mac OS X, Windows Vista, Windows 7 and Windows XP SP3 stations, this is trivial. OS X stations only send Probe Requests for a short time after the WiFi radio is turned on, and Windows stations disable the sending of Probe Requests by forcing the user to check a checkbox indicating that the SSID is non-broadcasting in order to enable probing. The fault, dear readers, is not within our laptops, but in our phones; that they are probing.

Solving the problem of phones (and tablets, at least in the case of the iPad) sending Probe Requests can be a complicated task. The WiFi client software used by these devices is often primitive. In the case of iOS devices (iPhones, iPod Touches and iPads), users are not presented with a list of Preferred Networks. When you turn the iOS device on, it just starts probing for every SSID you've ever connected to unless you've tapped the Forget This Network button before leaving the network. And if you forget to tap Forget This Network? Well, you're stuck. The iOS device will continue to send Probe Requests containing the SSID, but you won't be able to Forget the SSID until you connect to it again.

So what to do if you have an iOS device (or any other device that you want to protect from Evil Twin access points)? If you want to know which SSIDs your device is sending Probe Requests for, you just need to run a frame capture and filter on the unassociated probes. Here's how:

  • In AirMagnet WiFi Analyzer, you go to the Infrastructure screen and select Listed By SSID (I'll add a screenshot next time I'm in Windows) in the drop box at the top of the screen. Any SSIDs that don't have an AP underneath them are SSIDs that stations are probing for.
  • In WildPackets Omnipeek, you go to the WLAN screen and look under ESSID Unknown --> BSSID Unknown. SSIDs shown there come from Probe Request frames.
  • In Wireshark, use the filter, "wlan.fc.type_subtype == 0x04". After applying that filter, scroll through the Probe Request frames and see which SSIDs your station is probing for. 
Once you find out which SSIDs your device is probing for, you can adjust your device to make its operation less vulnerable. If your device has a Preferred Networks list, just go into that list and remove unsafe SSIDs (meaning unencrypted SSIDs or SSIDs that would reveal your location in a Wigle search). If your device doesn't have a Preferred Networks list (like in iOS), then just configure an access point with the SSID you were probing for, and then after your device sees that SSID, tap that Forget This Network button. It may not solve all of the problems with mobile device security, but it will solve one of them.

Comments

  1. I’m wondering if several devices probing for SSIDs could be enough to saturate a channel and severely hamper it – and if so, how many would it take. After reading this blog entry it makes sense, and it would explain the cross channel interference / ST probing I’m seeing on the AirMagnet WiFi Analyzer I’m trying to understand.

    ReplyDelete
  2. It would take a massive amount of probing to take down a whole channel. I've never done the math on how much it would take, but Probe Request frames are awfully small and are sent at sizable intervals.

    ReplyDelete
  3. Nice blog! I will suggest your page to my colleagues.

    ReplyDelete

Post a Comment

Popular posts from this blog

Chips, Glorious Wi-Fi 6E Chips!

Five Facts About 6 GHz Wi-Fi

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