Apple’s handling of location data has made its way back into headlines recently due to a tool written by security researcher Hubert Seiwert. Seiwert presented the iSniff GPS tool, which makes it easy to capture potentially sensitive iPhone user data, last July at the Blackhat USA security conference and posted the source code to Github a month later. While the tool isn’t particularly new, it has been the recipient of some media attention after being covered earlier this month by SC Magazine. While the disclosure of the sensitive information by iPhones was previously known, iSniff makes the information more easily accessible and is worth a closer look to determine if users need to worry.
iSniff has two primary components; the first extracts relevant data from traffic captures while the other provides a web interface to interact with collected data. The first component, iSniff_import.py, captures ARP requests from iPhones on the same network and SSID probes from iPhones not currently connected to WiFi. While SSID probes are something normal for all WiFi enabled devices not currently on a network to send out, these particular ARP requests seem to be unique to iOS devices and were initially reported on by Ars Technica after Mark Wuergler initially discovered them.
Normally ARP requests are sent by networked devices in order to resolve the network IP address of other devices on the network to their hardware MAC addresses. Upon joining a network, iOS devices send ARP requests addressed to MAC addresses belonging to the DHCP servers for the last three wireless networks they’ve been connected to. Nobody quite seems to understand why, but one guess is that it’s an attempt to speed up the device’s joining to the network. This means that if your iPhone is connected to WiFi at your house, then you head to Starbucks to get some work done and connect your iPhone to the network there, upon connecting, your iPhone will send an ARP request on Starbucks’ wireless network containing the MAC address of your home router. What makes this concerning is that the geographical location of most wireless access points, along with their MAC address, have been mapped, placed into databases, and are available for anybody on the Internet to lookup. If somebody on Starbucks’ network was monitoring for these ARP requests, they could acquire your MAC address and do a lookup to find out where it is located, potentially revealing to them where you live.
When your device is trying to determine your current location, it can use GPS, but depending on the availability of satellites, this can take a while to determine your location. Nearby WiFi base stations offer a faster way to determine a user’s approximate location. As you walk around with your iPhone and it detects various wireless signals, it sends anonymous data back to Apple, reporting the device’s location and information about nearby wireless base stations (concerned users can disable this in Settings > Privacy > Location Services > System Services > Diagnostics & Usage see update below). Apple adds this information to their giant database of known wireless base stations and locations. By crowd-sourcing this data gathering out to the millions and millions of iOS devices used worldwide, Apple is able to keep a fairly accurate database which allows users to get relatively accurate location services readings when they’re near any known base stations. Of course, such a database requires a way for iOS devices to read from it in order to make any use of it. This is precisely what the second major component in iSniff is for.
iSniff makes a location query to Apple’s servers with a single MAC address to find out the MAC’s location. By spoofing the user-agent in the request to appear to be from iOS’ location daemon (locationd), iSniff gets Apple to return not only the latitude and longitude of the given MAC address, but information on up to 400 nearby base stations. iSniff will then plot all of this data onto an interactive map in your browser, making it easy to view the data held by Apple’s location services servers... 400 APs at a time.
While interesting to see, this also raises a number of privacy concerns for users. But should regular users need to worry? Not really. While there are issues with sensitive information being disclosed without customer awareness or control, the likelihood of this information being leveraged in any sort of attack on a user is quite slim. While you could capture and use the information to figure out where somebody lives, you would not only need to get them to join your network, but you’d also have to know which one of the three MAC addresses, if any, belong to their home router. In specialized cases like security audits performed on companies by hired penetration testers, it might make sense to exploit this information in order to track employees back to their houses to try and acquire more sensitive information. But for day-to-day users, it’s extremely unlikely that anybody would try to perform an attack like this in order to learn where a user lived. After all, since physical proximity is required to be on the same WiFi network, in many cases it would seem just as easy to simply follow the person when they drive home.
It would be interesting to know why exactly Apple’s devices exhibit this behavior. You also can’t help but wonder if it’s possible to exploit Apple’s location services servers in other ways. In fact, Seiwert has mentioned in some of his talks that he’s currently exploring this possibility. It might be wise of Apple to try and lock those servers down a little tighter before information disclosed by them becomes a bigger concern for users.
In the meantime, this isn’t something users should be too concerned about. If you’re already joining untrusted wireless networks or networks with malicious users on them, your problems are likely much bigger than somebody getting the MAC address of your router.
Update: Seiwert has informed me that while initially it was believed turning off Diagnostics and Usage in Settings would opt you out of contributing access point data, he has since witnessed devices still transmitting this information even when the Diagnostics and Usage option is disabled.
