Apple’s huge database, which usually records the locations of Wi-Fi base stations to the nearest metre, has apparently been exploited without hindrance: With little effort, attackers are able to create a ‘global snapshot’ of all the location data of the WLANs recorded there. This allows them - over a longer period of time - to track changes in the location of the routers usually belonging to a household or sometimes even of individuals, as two researchers from the University of Maryland have now demonstrated.

The researchers consider it particularly problematic that Apple’s Wi-Fi database can be read out practically unhindered and immediately provides the location data for ‘several hundred’ additional BSSIDs (the physical MAC addresses of the routers) to the requesting client without being asked via an apparently unlimited API. In this respect, Apple’s Wi-Fi database also differs fundamentally from other Wi-Fi databases, such as the one operated by Google.

  • Darkassassin07@lemmy.caEnglish
    314·
    6 months ago

    Apple’s got one, so does Google, and Microsoft. They’re common tools for scam baiters tracking down call centres and individual scammers. Pretty effective actually.

    • GamingChairModel@lemmy.worldEnglish
      31·
      6 months ago

      Apple’s got one, so does Google, and Microsoft.

      They’ve got beacon location data, yes, but Apple is the only one that gives up that information without first conforming that the query is coming from someone who sees that BSSID. As OP notes:

      In this respect, Apple’s Wi-Fi database also differs fundamentally from other Wi-Fi databases, such as the one operated by Google.

      If you click through to the paper, it describes 2 approaches for using BSSIDs to identify location:

      1. Client submits a query listing each BSSID and its signal strength, and the server calculates position and returns where it believes the query is coming from.
      2. Client submits a query listing each BSSID it’s interested in, and the server responds with the location of each BSSID so that the client can calculate its own position.

      See the problem there? Approach 2 gives more raw information away, by outsourcing the positioning calculation to untrusted clients.

      And the paper outlines how Apple goes even further than that:

      Apple’s Wi-Fi geolocation API [4] works in the latter manner, but with an added twist: In addition to the geolocations of the BSSIDs the client submits, Apple’s API opportunistically returns the geolocations of up to several hundred more BSSIDs nearby the one requested. These unrequested BSSID geolocations are presumably then cached by the client, which no longer needs to request the locations of the nearby BSSIDs it may soon encounter, e.g., as the user walks down a city street.

      It goes on later:

      Apple’s WPS API is free and places few restrictions on its use. It requires neither an API key, authentication, nor an Apple device; our measurement software is written in Go and runs on Linux. Moreover, Apple appears to make no attempt to filter physically impossible queries. The BSSIDs submitted to the WPS need not be physically proximate to each other nor to the device submitting the query; Apple’s WPS will respond with geolocations for BSSIDs on two different continents in the same request to a querier on a third.

      That’s the discussion here. Apple keeps a large database, like many other big tech/mapping firms, but does nothing to keep that database hard for strangers to scrape in bulk.

      In contrast, Google uses the first approach and keeps the information a bit more restricted by performing the location calculation at the server:

      Han et al. reverse-engineered Google’s WPS’s method of operation [17]. Google’s WPS functions differently than Skyhook’s and Apple’s insofar as Google’s service attempts to geolocate the device submitting the query, providing it with only the device’s computed position given a list of BSSIDs from the client.

      So it’s possible to run this type of service with this type of database, without sharing BSSID locations with anyone else who asks.

      • sramder@lemmy.worldEnglish
        5·
        6 months ago

        So it’s possible to run this type of service with this type of database, without sharing BSSID locations with anyone else who asks.

        Seems like apple was hoping to keep their API hits down at the expense of everyone’s privacy including their own customers. Very uncool.

        • GamingChairModel@lemmy.worldEnglish
          4·
          6 months ago

          It seems that Apple may be interested in at least requiring authentication that the query comes from an Apple device (or even an Apple-approved API key), which would go a long way in alleviating the security flaw.

          I can see some value in the server returning BSSID location data directly (especially with risk of intermittent or slow data connections), but the combination of all the factors seems sloppy.

          • sramder@lemmy.worldEnglish
            1·
            6 months ago

            …the combination of factors seems sloppy. Well put.

            It could even be privacy preserving with the right implementation. With a bunch of device locations nearby you’re not hitting the server constantly and leaving a trail… but I think Apple just had limiting API hits and maybe computing.