![](https://webarchive.library.unt.edu/dentonfracking/20141114114430im_/http://cdn.arstechnica.net/wp-content/uploads/2014/11/chattysamsung-640x278.png)
Every time you use Google or Apple mobile location services, you’re not just telling the services where you are. You’re also shouting many of the places you’ve been to anyone who happens to be listening around you—at least if you follow Google’s and Apple’s advice and turn on Wi-Fi for improved accuracy.
Wi-Fi is everywhere. And because of its ubiquity, Wi-Fi access points have become the navigational beacons of the 21st century, allowing location-based services on mobile devices to know exactly where you are. But thanks to the way Wi-Fi protocols work, mapping using Wi-Fi is a two-way street—just as your phone listens for information about networks around it to help you find your way, it is shouting out the name of every network it remembers you connecting to as long as it remains unconnected.
The problem with Wi-Fi “probe” requests is nothing new—Dan Goodin covered the vulnerability for Ars two years ago. The problem poses a significant security issue in some cases—particularly for AT&T customers, whose phones automatically join networks named “attwifi” when their probe requests are answered. That’s something we’ve demonstrated ourselves in controlled test at Ars’ security skunkworks.
We wanted to get an idea of just how much we could learn about people by passively listening to their smartphones’ Wi-Fi broadcasts. During a brief test, we submitted a small sample of volunteer smartphones to a simple test—we turned them on, with Wi-Fi enabled, to see what they gave up about where they had been, using a low-power Wi-Fi adapter in monitor mode and a packet capture utility.
We got more than we bargained for. In the course of the test, because we didn’t have a Faraday cage erected around us, we also picked up a few other signals—cell phones in adjoining buildings, passing cars, and even the handheld computer of an express delivery driver. After reviewing the data, we purged it.
Update: In a foillow-on test with an HTC Windows Phone and the BlackBerry Passport, Windows Phone did not send out probe requests with network names, instead using a "broadcast" probe. However, it consistently broadcast the same MAC address in any mode, making it passively trackable. The Passport sent out a probe requests for networks by name, in the order that they had been added as known networks.
The results were not surprising to us, but they are still eye-opening, and indicative of the security and privacy risks that result from wandering around with Wi-FI turned on but not connected. We were able to match specific devices with recent (and some not really recent) movements of the owners of the phones—where they worked, where their homes were, and in some cases where they had shopped recently—using publicly available Wi-Fi base station mapping data.
Cloud atlas
When Google collected Wi-Fi data using its Street View cars, it kicked off a wave of concern over privacy in many countries. And it also landed Google in court, as the FCC slapped the company with a $25,000 fine for “payload sniffing”—pulling snippets of data out of unprotected Wi-Fi traffic. The Supreme Court refused to hear Google’s appeal in June, and Google no longer is collecting payload data.
After the privacy flap over its data collection, Google still collects Wi-Fi base station MAC addresses and SSID names—the names users assign to their routers to identify them from devices—but now offers a way for owners of Wi-Fi hotspots to opt out of its database. All they have to do is add “_nomap” to the end of their base stations’ SSID names.
Apple also collects Wi-Fi network data. And both Google and Apple no longer have to depend on wandering mapping vehicles to collect their data for them—they can just turn the mobile phones of their customers into little wandering signals intelligence platforms. Whenever mapping or location services are enabled, they’re not just checking the databases of base stations to get a fix—they’re also collecting data on new base stations and putting a fix on their location, even inside buildings.
According to Apple’s Location Services support page, “If Location Services is on, your device will periodically send the geo-tagged locations of nearby Wi-Fi hotspots and cell towers in an anonymous and encrypted form to Apple to augment Apple's crowd-sourced database of Wi-Fi hotspot and cell tower locations.”
Apple and Google aren’t the only ones collecting this data. There are a variety of public and private databases of Wi-Fi network geolocation data—some private and some public. Odds are, if you live in a relatively densely populated area, your Wi-Fi network has already been mapped by someone.
The Wireless Geographic Logging Engine, for example, is a publicly-accessible database of Wi-Fi and cellular station geodata, built from contributions from “wardrivers”—individuals who walk or drive or ride the bus while using a Wi-FI equipped computer or smartphone app to match GPS data to discovered networks. Skyhook Wireless offers a number of commercial services based on its own database of wireless access points and “beacons.” Skyhook was recently acquired by TruePosition, which builds cellular-based geolocation services for E911 services and national security customers.
Putting it together
To analyze our captured data, we used Wireshark to filter wireless LAN packets down to just the “probe” requests—the “Marco” part of Wi-Fi’s game of “Marco Polo.” The captured requests gave us the MAC address of the phone making the probe, the SSID names of the networks they were looking for, and other data the phones advertised about their advanced wireless networking capabilities if any. We tested phones from a variety of vendors (including Apple, Samsung, HTC, and Motorola).
In all cases, the probe requests have eliminated a major problem that was exposed in our original coverage of smartphone SSID shouting—giving up the actual BSSID, or MAC address, of the base station they were looking for. However, all of the phones gave up extensive lists of SSIDs in probe requests. One user’s device revealed:
- Their workplace network name, easily found with WIGLE.
- Their home network name, also geolocatable on WIGLE.
- The SSID of their swim club.
- The SSIDs for the guest networks of two stores they shopped at.
- The SSID of a guest network for an auto dealer.
- SSIDs for hotel and airport networks.
- The SSID of a location visited on a recent overseas business trip.
With that sort of profile, just from a brief burst of wireless traffic, an attacker would be able to screen a group of smartphones for potential targets, and attempt to execute a man-in-the-middle attack on a target phone by spoofing one of its known networks . Additionally, the data could be used for social engineering attacks, or to fingerprint the user’s phone for further tracking.
So maybe it’s not such a great idea to get that increased location accuracy, after all.
For Android users, installing Kismet Smarter Wi-Fi Manager makes it possible to geo-fence where Wi-Fi is turned on, preventing your phone from constantly looking for a hook-up. Enterprise mobile policies can also be used to geofence when Wi-FI can be turned on on corporate devices, so they're not giving up internal access point names and potentially allowing man-in-the-middle attacks on sensitive applications.
Apple has actively tried to reduce the risk of probe sniffing by adding MAC address randomization in iOS 8. There's just one problem—it doesn't work very well, as Bhupinder Misra of AirTight Networks found. The problem is that the randomization (which is limited) only happens when the phone's screen is asleep, location services are turned off and Wi-FI is turned on.
For most people, the best bet may be simply turning off Wi-Fi in transit. That won't keep you from being stalked whenever you arrive somewhere and turn on Wi-Fi, but it will stop your phone from shouting network names along the way.
You must login or create an account to comment.