iSniff your Wi-Fi and GPS your House

http://intrepidusgroup.com/insight/2013/05/isniff-your-wi-fi-and-gps-your-house/

It’s been a while since I thought much about location-based services on iOS systems, in particular their privacy implications. Of course “Locationgate” happened back in March 2011, when researches called public attention to a database of location points saved on iPhones. A year later, Mark Wuergler reported on a possible information leak where iOS devices disclosed the MAC addresses (more properly, BSSIDs) of the last few access points they’d linked to.
These two issues were brought together last summer, at the Black Hat Arsenal, when Hubert Seiwert (@hubert3) presented a tool called iSniff GPS. The tool was described in more detail at Syscan in Singapore just a couple of weeks ago, but finally came to my attention in a tweet Wednesday night pointing me to SC Magazine (Australia).
Intrigued, I spent some time yesterday installing the iSniff tool and putting it through its paces, and have a few thoughts I’d like to share.

You can easily map access points by name using queries to the WiGLE database.

The iSniff GPS tool contains two main components: A sniffer, and a GUI. The sniffer watches for leaked ARP packets, identifies the BSSIDs they’re probing for, and fetches information about them from Apple. The web-based GUI (built on Django) shows you the devices that have been “noticed” on the local network, and lists networks those devices have visited. When a probed network was matched in Apple’s database, a link will also take you to a visualization of all the data Apple has on file regarding that access point’s location.
After installing the tool, I took an old access point, connected my laptop directly to it, and joined a few iOS devices to see what happened. The tool was definitely working as designed — devices immediately appeared in the list, along with a list of BSSIDs each client probed for. Clicking on each client in the list displays a detail screen with latitude and longitude for each network BSSID found in the Apple DB, and a link to display the information on a map. Another tab pivots the data, listing it by network (with the relevant clients next to each), while other tabs offer direct mapping of selected BSSIDs and even searching and mapping of the wigle.net SSID database.

Clients detected, and the APs they queried for (anonymized, obviously).

Interestingly enough, none of the access points the devices queried were in Apple’s database. The access point at work was found in the WiGLE DB (listed both by name and BSSID), but not in the Apple DB. My home access point didn’t show up in either database, despite having several iOS devices connecting on a daily basis, not to mention multiple visiting family members most of whom have iOS devices as well. [Note: Not entirely correct, see update below.]
However, another network in the building did show up in Apple’s DB, and I was also able to accurately geolocate several access points near our sister company (iSEC Partners) in Manhattan. Perhaps there hasn’t been enough traffic by our building in the year since we moved in? We just haven’t been reported frequently enough to be included in the database?

The red dot is where Apple thinks the AP is (it’s actually just inside the adjacent building)

That’d be a great theory, except that the BSSID for the access point I was testing with also appeared in the Apple DB. That seemed really odd, since this AP is almost never on, and when it is, it’s rarely for more than a few days at a stretch, and almost never accessed by anything other than my own devices. Occasionally it’ll be set up as “attwifi” for testing, and I’ll get a few people in doctors’ offices connecting (and enjoying free internet access), but that’s probably no more than a dozen devices, all told, ever. Finally, the AP gets brought to the beach every year (and lots of people use it there) but that’s obviously a totally different location, and even then, not more than a couple dozen additional devices. And again, only for a week.
So why is an access point, active 24×7 for over a year, not in the database, and another one, in use for maybe 3 or 4 weeks total time over the same year (and one of those weeks in a different state), not in the database? There’s definitely some odd criteria in play here that I haven’t yet been able to guess at.
What does all this mean? It’s clear that the Apple BSSID database has real utility: It helps devices quickly, and more accurately, determine exactly where they are. There might be a way that Apple could restrict how queries are performed on the database, but it’s possible that would be difficult to do effectively. And of course, Apple isn’t the only entity maintaining such a database. Trying to keep your AP information out of a publicly-accessible database just isn’t going to happen.
On the other hand, the leakage of the BSSID data when a device joins another network is a little harder to justify. What exactly is the utility the user gets from this? A faster recognition by the device that it’s on a network it knows? What services benefit from this, and to what degree? It may well be acting in accordance with RFC 4436, but that doesn’t necessarily make it right (and very few, if any, Android devices exhibit the same behavior).
Ultimately, the real question is whether the daily benefit to the end user outweighs the risk that the location of their home, or school, or workplace, might be disclosed to an eavesdropper at a coffee shop. Which, in a strict risk analysis, probably falls far short of requiring elimination of the leakage. Perhaps it could be mitigated with a user preference setting, but this problem is pretty esoteric even for information security researchers, and I suspect clearly describing the problem (and its implications) to the average user in the space of a few lines on a preference pane would be flat-out impossible.
At any rate, this is a very interesting demonstration of fusing publicly-accessible data from multiple sources to gain information not otherwise explicitly revealed. And that in itself definitely makes the iSniff GPS tool worth checking out.
Quick Update, 5/13/2013: I was out of town over the weekend, but now have done a little more checking, based on Hubert’s comments below and on Twitter.
Turns out, of the two networks at work (open/guest and closed/employees), one of the guest BSSIDs is in Apple’s DB, but none of the closed BSSIDs are, which still seems odd to me. Of four neighboring business’ BSSIDs checked, all four are in Apple’s DB. And I looked again for my home AP, and it was in there — I’d been querying the wrong MAC address.
So the AppleDB is a little more complete than I’d thought, though there’s still something keeping our main work net from showing up.
And I also verified that the ARP queries being sent out by iOS devices upon joining the network are not for our local APs, but for the router / DNS server (which are both the same here). So for places where the router / DNS is also the Wi-Fi access point (many, many places), the ARP disclosure can lead to geolocation via Apple’s DB. But where the Wi-Fi and router / DNS are split to multiple devices, it’s a bit harder to find.