The initial introduction to the "Attacking Wi-Fi Clients" DinoSec blog post series highlighted multiple topics involved in current Wi-Fi client weak behaviors and potential attack opportunities. This next installment in the series focuses on understanding why and when Wi-Fi clients disclose their PNL still today.
State-of-the-Art: The PNL
When Do Wi-Fi Clients Disclose their PNL?
The following paragraphs detail different modern scenarios in which Wi-Fi clients still might disclose their PNL, including some curious references to constraints you will find when you try to manage the PNL of your Wi-Fi clients.
Wi-Fi Client State and Other Peculiarities
The PNL disclosure behavior is highly influenced by the Wi-Fi client state, such as if it is currently connected to a known Wi-Fi network, or if there are no well known networks in its vicinity. However, distinct clients and implementations behave differently, and even when connected, it is still possible for a client to disclose its PNL, while looking for more "interesting" known networks. Sometimes, they do when trying to connect to a new network, or when the network they were previously connected to disappears or the signal is low enough. Besides that, an attacker can also force a victim Wi-Fi client to disassociate from the current network, forcing it to disclose its PNL.
Unfortunately, by default there are multiple Wi-Fi clients that continuously disclose their PNL in the air. Others, however, only disclose it sometimes. If you try to fix both of these scenarios, you suddenly realize this behavior is heavily influenced by several complex factors, such as the specific hardware used by the client, that is, the chipset used on its Wi-Fi interface or card, the firmware version, the version of its Wi-Fi drivers (used by the operating system to interact with the card), and the supplicant implementation (the Wi-Fi client capabilities at the software level). For example, I saw iOS 7.0.4 tended to disclose the PNL if running on an iPhone 4, but not on an iPhone 4S (even when running iOS 7.0.3), but iOS 6.1.3 didn't disclose it either when running on an iPad 3.
New features introduced in modern Wi-Fi clients, such as the MAC address randomization capabilities of iOS 8 when it scans for Wi-Fi networks, open the door to evaluating how effective this behavior is both from a privacy and security point of view, and promote additional research.
As a result, while researching about why and when Wi-Fi clients disclose their PNL, I have found difficult to consistently reproduce some scenarios in which it's not very clear why the PNL has been revealed. A complex combination of factors is behind the root cause, such as the surrounding Wi-Fi networks and signal levels, the existence of hidden Wi-Fi networks nearby, the current state of the client mobile (2/3/4G) interface, the current and previous Wi-Fi client states and transitions, the PNL contents, and even if the device is getting power through a computer USB port or from a power plug... a very long list of sometimes unrepeatable facts. But the truth is that Wi-Fi clients still disclose their PNL.
For all these reasons, it is required to design a very thorough methodology to evaluate why and when a target Wi-Fi client discloses its PNL.
Hidden Wi-Fi Networks
Hidden or non-broadcast Wi-Fi networks are one of the most common scenarios why Wi-Fi clients disclose their PNL. In fact, the only way a Wi-Fi client can connect to a hidden network is by disclosing its PNL. This is definitely one of the main reasons why you should never configure Wi-Fi networks as hidden (although still today there are people recommending this as a best practice), as this is not providing any effective security to the Wi-Fi infrastructure, but it is in fact exposing the Wi-Fi clients that connect to it.
A very specific case related to mobile devices is when Wi-Fi networks are added manually to, for example, iOS or Android. In the case of mobile devices, manually adding a Wi-Fi network (check the various advisories I published during the last few years) commonly implies this network will be considered as hidden by the device and, therefore, it will be disclosed. To sum up, if a Wi-Fi network (hidden or not) is manually added to a mobile device, there is a very high probably it will be disclosed by that Wi-Fi client.
Case Study: iOS 5.x
On early 2012 I discovered a scenario where Apple devices based on iOS 5.x (at that time), like iPhones and iPads, fully disclose their PNL (including both hidden and visible networks) every 45 seconds when they enter sleep mode (also referred as suspend or standby mode). Therefore, an attacker can force a victim device to disclose its PNL if he has temporary physical access to it, making the device going to sleep by pressing the power (or Sleep/Wake) button, the device owner can make the device to enter standby mode by its own, or even the device will do it automatically after not being used for a few minutes, depending on its settings.
I can briefly mention this vulnerability at this point as the impact today is clearly low, due to the existence of newer iOS versions, and because this is still the default behavior of lots of Wi-Fi clients.
Managing the PNL
On the one hand, some Wi-Fi clients allow you to manage their PNL, such as Android 4.x devices although it would be great to be able to prioritize the entries in the PNL or identify if they correspond to hidden or visible networks. On the other hand, other widely used Wi-Fi clients, such as Apple devices running iOS, do not provide capabilities to manage it. Therefore workarounds are required in case you want to easily remove some entries from the PNL, such as using iStupid. Although this seems to only affect mobile devices or other "dumb things" from IoT (Internet of Things) with Wi-Fi client capabilities, this is not always the case and surprisingly, even modern operating systems used in traditional computing might be affected, taking a step back.
Case Study: Windows 8 & 8.1
Another more traditional scenario where managing the PNL has taken a step back is Windows 8 (even if it does not disclose the PNL by default, you may want to edit or remove previously added hidden networks). If you thought the already mentioned issues were just affecting mobile or embedded devices nowadays, it is not the case. Although in Windows 7 it was trivial to manage the PNL via the Wireless Profile Manager (for Windows 7), these capabilities were removed from the graphical user interface (GUI) in Windows 8. As a result, you can only view or remove a network from the PNL from the Wireless Network List if it is currently in range (as it is the case with iOS devices); remember you can always use iStupid [0] to help you making those faraway networks reappear ;-)
The other options available to manage the PNL in Windows 8 are through third-party tools, such as WiFi Profile Manager 8 or Classic Shell, using the command prompt via "netsh" (including managing the priority of networks within the PNL), or manually, by accessing or removing the XML files where the Wi-Fi networks profiles are stored: "C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces\{Interface-ID}\{Profile-ID}".
Windows 8.1 has slightly improved the manageability of the PNL. Although it does not include full capabilities as Windows 7, at least from the "Settings - Change PC settings - Networks - Connections" menu it is possible to manage and change some properties for each PNL entry. Still, to delete an entry you need to go to the command prompt and execute the "netsh" tool (probably an alternative not suitable for the average user).
[0] For the sharp reader, there are newer versions of iStupid in DinoSec Lab, apart from v1.0, waiting for you :-)
Security & Privacy Risks and Implications of Disclosing the Wi-Fi PNL
Finally, as it seems vendors and manufacturers of Wi-Fi products with client capabilities still do not take this issue seriously, we need to evaluate what are the real privacy and security risks of disclosing the PNL, that is, letting everyone know what are the Wi-Fi networks the Wi-Fi client device wants to connect to.
Privacy
On the one hand, an attacker can gather the PNL details to exclusively fingerprint a Wi-Fi client, with direct privacy implications. The fingerprinting process is based on identifying a very unique network name (SSID) used by that client, match that SSID to the client Wi-Fi MAC address, and be able to track its common locations and activities. If a very unique SSID is not found, most probably the Wi-Fi client will disclose a unique set of SSIDs. Even if some of these SSIDs are commonly used by millions of users, the whole set of SSIDs of a given client PNL tends to be a good distinguishing factor (even when the MAC address is randomized). This fingerprinting capabilities definitely help to launch very targeted attacks against key individuals, such as a high level executives of a given target organization.
Changing the default SSID and selecting a unique value is a positive countermeasure when protecting the Wi-Fi infrastructure, and in particular WPA(2)-PSK networks, as it acts as a deterrent against pre-calculated (raibowtable) password attacks on the PSK, because the master key (PMK) is based on the SSID (it acts as a salt). However, when talking about Wi-Fi clients, that unique SSID can help to identify a specific target.
Security
On the other hand, an attacker can gather the PNL details with the goal of impersonating one of the legitimate networks the client is trying to connect to, and as a result, get the Wi-Fi client to effectively connect to the attacker's infrastructure automatically, with serious security implications. In future installments of this series we will provide more details about these attacks, no matter what security mechanism is used by the legitimate Wi-Fi network (Open, WEP, WPA(2)-PSK, or WPA(2)-Enterprise). At this point, the victim client is sharing the network (at layer 1&2 and above) with the attacker. This is, at least, scary and opens the door to several direct and Man-in-the-Middle (MitM) attacks!
It is time to take this issue very seriously and responsibly address it, specially considering the impact it will have with the upcoming industry trend associated to the Internet of Things (IoT) or Internet of Everything (IoE), and the enhanced Wi-Fi bandwidth capabilities of 802.11ac networks. More and more, critical devices and gadgets used on a daily basis are going to provide Internet and data communication capabilities, some of them through LAN/Ethernet ports, but I foresee most of them (to get away of the uncomfortable wires) through a Wi-Fi interface.
Solutions
The sort term solution is to start evaluating if your personal, or your organization, Wi-Fi client devices disclose their PNL through specific Wi-Fi assessments and research. By Wi-Fi client devices I mean everything that has Wi-Fi client capabilities, from mobile devices to "everything" (IoT) in the residential, corporate, and mobile environments. If they disclose their PNL, at least you know it and can take informed security decisions, although there is not to much you can do if the vendor does not fix it, apart from carefully and diligently managing your PNL. Try to reduce the number of entries in the PNL and be sure all the known networks are using robust security... because you, or your organization employees, never ever connect to a free and open Wi-Fi hotspot, right?
The mid term solution is to implement some of the tools or solutions currently available that try to change the default behavior of some Wi-Fi client platforms, such as Smarter Wi-Fi Manager or Wi-Fi Privacy Police for Android mobile devices, to name a couple.
The long term solution is to promote a modification (I'm making this request public here!) of the next version of the IEEE 802.11 specification to, on the one hand, completely remove the existence of hidden Wi-Fi networks (Wi-Fi access points shouldn’t provide an option to configure a Wi-Fi network as hidden, and Wi-Fi clients should never allow users to add a Wi-Fi network as hidden), and on the other hand, mandate that Wi-Fi clients must never check for the availability of the specific Wi-Fi networks contained in their PNL through directed Probe Request frames. Instead, Wi-Fi clients must always discover the surrounding networks by sending a generic (or broadcast) Probe Request frame with a wildcard (or empty) SSID.
NOTE: For the record, this year updated "Técnicas de ataque sobre clientes Wi-Fi" session, 2015 RootedLab, complements the workshops I run in RootedCON on previous years, 2011 RootedLab, "Seguridad en Bluetooth, Wi-Fi, GSM y GPRS", the 2012 RootedLab, "Analizando y explotando aplicaciones web con Samurai-WTF", and the 2014 RootedLab, "Técnicas de ataque sobre clientes Wi-Fi" (all 2014 links have been removed from the official website).
Posts
