WiFi Data Leaks and Prevention
Got a device capable of connecting to WiFi networks? The answer is most probably “yes”. In that case, you should know that it’s most probably leaking potentially private information. Keep reading if you’re interested in knowing what is being leaked and how to prevent it.
When your device is fully asleep, your WiFi chip leaks two pieces of information periodically:
- The names of the networks you’ve previously connected to.
- Your device’s MAC address.
Note that we’re talking about deep sleep. Your screen being turned off isn’t necessarily enough, as music playback or other services can keep your phone awake.
The Names of Remembered Networks
The first type of leakage happens because of «Preferred Network Offload» (PNO). This feature was added in Honeycomb, and basically scans for WiFi networks in the background by sending a probe request¹ for each remembered network. It keeps doing that until a response is received, which indicates that the network’s access point is in range.
: probe requests are used by WiFi devices to scan for known access points. This is usually done when not connected to any network. However, many brands also send probe requests to determine whether networks with a stronger signal are in range. On recent versions of Android, the non-PNO scanner used when the device is awake does not leak the data we listed above.
Contrary to passive scanning, where you wait for the access points to broadcast their presence, this is quicker and doesn’t require the device to stay awake for prolonged periods of time. In short: it saves battery.
The default behavior sends the names of the remembered networks (SSIDs) as part of the probe requests, even though that is not required except for hidden SSIDs.
What can your remembered SSIDs indicate about you? They can actually be used to determine locations you regularly visit and your habits (e.g. coffee shops or hotels), or even specific homes if the names are indicative (e.g. «Jim’s router») or indexed in a wardriving database. A popular example is the WiGLE.net wardriving database. By looking at all the networks you’ve connected to in the past, one can also determine your main location with higher accuracy. There’s an interesting experiment that shows this in practice: SASQUATCH).
Let’s take a random person as an example. We’ve got some innocuous network names that don’t indicate much on their own: “Home”, “HHonors”, “ATTwifi”, “Columbia University”… but put them together and you already know quite a bit. If that person went on vacation, it would also make the set of remembered networks more unique for the user. In turn, that makes finding out their identity much easier, despite those details being rather minor on their own.
Your Device’s MAC Address
As for your device’s MAC address, it can act as a unique identifier and reveals your smartphone’s manufacturer. Each MAC address actually contains an Organizationally Unique Identifier.
If used with multiple detectors, this can allow a third party to track your movements over a mall, for example. That’s also been done in an experiment by the same team behind SASQUATCH, if you’re interested to read more about it. With some creativity, the information can even be linked to your actual identity over time — imagine, for example, mall owners coupling your device’s MAC addresses with your visits to the register.
Evil Twin Attacks
This isn’t a leak, but we’ll discuss it quickly since it’s useful to understand what one of the proposed solutions does later on. It does make use of the networks list leakage, though.
An attacker can use a network’s name to specifically target you or a group a people, by impersonating another access point (either a personal one or a popular network, such as a coffee shop’s). This is called an «Evil Twin» attack, and basically consists of a new access point using an SSID known by your device. The MAC address of the access point can also be faked with ease. This is possible in many cases, such as open networks or even WPA personal networks where someone else knows the password. Using WPA Enterprise is more complex, but protects against this.
In most cases, this means normal traffic can be read by others if they’re connected to the same network, either because the network/key is shared (again, think of the shop example) or because of an Evil Twin attack. Using HTTPS, or even a VPNs or an SSH tunnel usually keeps you safe in those cases, unless you accept a custom root certificate.
Prevention and Solutions
That last part’s covered, then — be aware of the risks connecting to public networks entails, and act accordingly. What about the rest, though?
Ideally, your device would broadcast probe requests asking nearby access points to announce their presence instead of “calling” each by name. This would work well for normal SSIDs, and sending out SSIDs in the probe request could only be done for hidden SSIDs. As a side note, this is why you shouldn’t consider hidden SSIDs to be a measure of security. Doing so would take care of location tracking concerns, but needs to be implemented at the WiFi chip’s level, which is what’s active and leaking data when the device is in deep sleep.
Another alternative is to manually remove remembered networks when you’re no longer in range, or only sending probe requests for nearby access points after determining the device’s location. The first requires manual work, and the second can be a huge battery drainer.
Fortunately, better solutions exist…
Wi-Fi Privacy Police
Wi-Fi Privacy Police has two functions:
- First, it automates the “forgetting past access points” part by disabling WiFi networks that aren’t in range, therefore preventing your device from sending out remembered networks’ SSIDs when it’s in deep sleep.
- Second, it’ll ask you about new access points with a known name but a different MAC address. This aims to prevent access point impersonation.
The first point works as expected. There will be a short delay before a network is forgotten, but that’s probably not an issue since you likely just got out of range.
The second would indeed protect you from access point impersonation, if only the SSID is faked. If the attack is targeted towards a specific (public or personal) access point, however, the MAC address would also be trivial to fake. You should be aware of this, as the illusion of security is worse than knowing about the flaws.
This is a good choice if you want to avoid having your network list leak, especially if you’re not rooted since root is not required. You can grab it from the Google Play store. The application is also open source (licensed under the GPLv2+), and you’re welcome to check its source code out on GitHub.
Pry-Fi prevents your device from announcing the list of the remembered networks, but still allows automatic connection to networks.
Additionally, your MAC address is constantly randomized when you’re not connected to a WiFi network, making tracking useless. It is also randomized once again when you connect to a WiFi network (you won’t use the same MAC address for future connection attempts).
Last but not least, Pry-Fi comes with a «War mode», which constantly and rapidly changes your MAC address. This makes it harder to track a single device and can poison the tracking data for your surroundings to a certain degree, although if you’re the only one using it, it would be feasible to attribute these tracks to a single person.
In short: use this if you’d like to stop your network list from leaking and MAC tracking.
Please note that Pry-Fi hasn’t been actively developed for the last few months, so you may be out of luck if your device isn’t supported. You can read more about the reasons here.
Pry-Fi Source Patches
These patches can be applied by a ROM developer (they may require additional testing/fixing on some devices). They provide two functions, and are generally more reliable than other solutions for the same functions:
- First, your device’s MAC address is randomized when scanning for networks, but not when you connect to a network.
- Second, your device will no longer leak the list of remembered networks.
For more information, make sure to check out the XDA forum thread and the linked commits.