Title: Preferred Network List (PNL) disclosure vulnerability in Android based on the method used to add Wi-Fi networks
Vulnerability ID: TAD-2011-003
Credits: This vulnerability was discovered by Raul Siles, Founder and Senior Security Analyst with Taddong (
www.taddong.com)
Publication date: May 5, 2011
Vendors contacted: Android Security Team
Vulnerability Summary:
Depending on the method the user followed to add a Wi-Fi network to its Android mobile device, selecting it from the Wi-Fi networks scan list or manually through the “Add Wi-Fi Network” button, the network name could be disclosed in the air by Android and be used by an attacker to impersonate that network, forcing the victim mobile device to connect to it to capture and manipulate its traffic and launch more advanced attacks.
For all broadcast Wi-Fi networks the user has previously connected to from the “Add Wi-Fi Network” button, it is advised to delete them all and re-add them back from the scan list once the user is under the network coverage.
Android users should preferably connect to a new broadcast Wi-Fi network from the scan list and use the “Add Wi-Fi Network” button only for connecting to a non-broadcast Wi-Fi network. A non-broadcast Wi-Fi network does require a Wi-Fi client to expose the network name in its probe request packets in order to be able to successfully connect to the network, making the client vulnerable to the previously mentioned security threats.
Vulnerability Description:
Android mobile devices, as most Wi-Fi clients, keep a list of the wireless networks manually configured, plus the networks it has connected to in the past, on the Preferred Network List (PNL). Every time the Wi-Fi interface is turned on, and periodically once it has been activated (for example, to roam between access points), the device checks through 802.11 probe requests what networks in its PNL are available in the current location. Based on the responses obtained, it tries to connect to the most preferred network.
In the past this network discovery process was performed by sending a generic probe request for the broadcast (or any) network plus specific requests for every network in the PNL. This meant devices disclosed the full PNL in the air [1], exposing themselves to karma-like attacks [2], where an attacker can identify all the networks (or access points) the mobile device is trying to connect to and impersonate them, forcing the victim device to connect to the attacker's network to capture and manipulate its traffic and launch more advanced attacks.
In order to avoid this vulnerable behavior, modern operating systems and Wi-Fi supplicants changed the previous vulnerable behavior not to advertise the wireless networks in its PNL. Modern Wi-Fi clients only generate 802.11 probe requests for the broadcast network, generically asking for the networks available in the area. An exception to this behavior is presented by the existence of Wi-Fi hidden networks in the PNL: due to the fact hidden (or non-broadcast) networks do not include their SSID (Wi-Fi network name) in the beacon frames, and do not respond to generic queries asking for any network available, the Wi-Fi clients need to specifically ask for these hidden networks, disclosing its name and existence inside the device PNL. This makes devices vulnerable again to the aforementioned attacks.
Android mobile devices provide two methods to add and configure Wi-Fi networks into the device. If the network is visible, it will appear on the Wi-Fi networks scan list. By simply selecting it form the list, and after providing the network credentials, the user can add the Wi-Fi network to the device. Additionally, Android provides an “Add Wi-Fi network” button at the bottom of the scan list, to manually add Wi-Fi networks. This is the only method available to add hidden networks, as they will never appear on the scan list.
However, Android does not provide any specific configuration option through this method to specify if a network is hidden (non-broadcast) or visible (broadcast). Although the most natural way of adding a network for end users is from the scan list (fortunately, for Android, this is the secure option), unfortunately, the method of manually adding Wi-Fi networks to a device is very common too, and recommended from a security perspective, as advanced users have more control over all the Wi-Fi network settings and options.
This subtle configuration behavior has serious security implications. Depending on how the user added the Wi-Fi network to the device, selecting it from the scan list or through the "Add Wi-Fi network" button, you are vulnerable or not. As a result, all the Wi-Fi networks (hidden or visible) added to Android through the “Add Wi-Fi network” button are implicitly considered as hidden, its details will be revealed in the air, and the mobile device will be exposed to Karma-like attacks [2].
The expected non-vulnerable behavior implies the propagation of probe requests only for the broadcast (or any) network plus all the intentionally configured hidden networks in the PNL. By default, unless it is clearly specified by the user, all networks should be treated as visible, not generating any probe request frames for them.
The vulnerable behavior exists on the default Android configuration when adding a Wi-Fi network through the “Add Wi-Fi network” button; the Wi-Fi networks connected from the scan list are not exposed and hence not vulnerable.
This vulnerable behavior is similar to TAD-2010-003 [3], but in the case of Android, only those Wi-Fi networks added through the “Add Wi-Fi Network” button are disclosed, instead of the full PNL.
Security Solutions, Workarounds, and Countermeasures:
Every time a user connects to a Wi-Fi network for the first time from her Android mobile device, it must select it from the Wi-Fi networks scan list, instead of using the “Add Wi-Fi Network” button except when connecting to hidden networks (option not recommended). This method ensures the Wi-Fi network will be added to the PNL in a secure way and won’t be disclosed through probe request scans.
End users, corporate administrators, and security professionals, using or managing Android mobile devices must be aware of this behavior and ensure that all the Wi-Fi networks available on the device PNL are treated as visible.
Unfortunately, Android does not provide any indication on the user interface to be able to differentiate between the two types of networks (hidden or visible) for the already configured Wi-Fi networks. Once a Wi-Fi network has been added, the user cannot know if it was securely added or not. Thus, for all Wi-Fi networks previously added to the device the user must delete them all and re-add them again, selecting each of them from the scan list (and not using the “Add Wi-Fi Network”) once the user is under the network coverage (and it is visible).
A similar scenario occurs for those Wi-Fi networks that were configured as hidden in the past, were manually and insecurely added to Android, and are configured as visible now because the administrator learned about Karma-like attacks and improved the security of the network by making it visible. It is highly recommended not to setup or connect to Wi-Fi hidden networks, as the Wi-Fi clients will be exposed to the attacks previously mentioned.
A more granular solution is to monitor the mobile device Wi-Fi traffic, identify what Wi-Fi networks Android is generating probe requests for, and delete and re-add again only those networks.
The recommended solution would be for Android to add a new configuration setting to the user interface that allows the user to specify if the network must be considered hidden or visible every time a new Wi-Fi network is added to the mobile device, independently of the method used, or at least when it is manually added through the vulnerable “Add Wi-Fi Network” button. The default value for this new setting must reflect that the network to connect to is visible (unless the user specifies otherwise by changing the default value).
Besides that, Android users should be able to see and change this “type of network” setting at any time, that is, when the Wi-Fi network is added for the first time, or afterwards, through the "Edit network" button.
Vulnerable Platforms:
The vulnerable behavior was discovered on Android 2.2.
The Android Security Team has confirmed this vulnerable behavior also affects all currently available Android 2.x and 3.x versions (such as 2.2.1, 2.2.2, 2.3, 2.3.2, 2.3.3, or 3.0).
Vendor Information:
The Android Security Team confirmed the existence of this vulnerable behavior and is working on changing the "Add Wi-Fi Network" dialog box to read "Configure a non-broadcast network". The original intent of the "Add Wi-Fi Network" dialog box was only to add non-broadcast networks; the wording will hopefully make that clearer.
The new dialog box text will inform aware users that probe request messages will be sent from their device. They also confirmed there is no Android documentation available which describes the “scan list” versus the “Add Wi-Fi Network" behavior, hence the importance of the distribution of this security advisory in an effort to raise awareness on this issue.
In the “Vulnerability Description” section above, Taddong generally recommends from a security perspective the method of manually adding Wi-Fi networks to a device so that advanced users have more control over all the Wi-Fi network settings and options. The Android Security Team thinks that adding a network via the scan list is more secure, because more critical security information can be conveyed automatically, rather than relying on the limited options available to the user. We (at Taddong) agree this could be true for the average user, especially to avoid misconfiguration and user mistakes, IF the user connects to a secure and properly configured Wi-Fi network, but unfortunately, this is not always the case.
We at Taddong honestly believe this finding must be publicly known by end users and by the information security community in order to take appropriate countermeasures and mitigate the vulnerable behavior. Therefore, we have tried to coordinate the release of this security advisory together with the vendor, following responsible disclosure principles. This vulnerable behavior is especially relevant considering the broad market adoption of Android mobile devices (with significant increasing adoption estimations for the upcoming years), and its extensive usage to connect to Wi-Fi networks.
Vulnerability Report Timeline:
2011-04-08: Taddong contacts the Android Security Team to provide details about this vulnerable behavior. The Android Security Team requests more details and clarifies the expected behavior.
2011-04-09: Taddong provides extra details after reanalyzing the expected behavior and ratifies the vulnerable behavior only when the “Add Wi-Fi Network” button is used. Taddong asks for details to differentiate the two types of networks, available documentation, expected behavior, and future plans to mitigate the vulnerable behavior.
2011-04-12: Taddong asks for feedback, and the Android Security Team replies back clarifying the previous questions and notifying future plans to improve the Android user interface. Both parties start to coordinate the public disclosure of this issue.
2011-04-15: Taddong completes and provides an initial security advisory draft to the Android Security Team for its review and comments. The Android Security Teams confirms its reception, internal distribution, and feedback is expected for next week.
2011-04-22: The Android Security Team confirms it is still collecting feedback regarding the security advisory draft.
2011-04-28: Taddong tries to get an update of the status of the security advisory draft review process.
2011-05-04: Taddong again tries to get an update of the status of the security advisory draft review process. The Android Security Team provides its review and comments to the security advisory draft.
2011-05-05: Taddong publishes security advisory TAD-2011-003.
References:
[1] "Trying to shut up your wireless chatty Windows". Raul Siles. 2005.
URL:
http://www.raulsiles.com/docs/Chatty_Windows_Wifi_Sep05.html
[2] "KARMA Wireless Client Security Assessment Tools". Dino A. Dai Zovi. 2005.
URL:
http://theta44.org/karma/index.html
[3] “TAD-2010-003: Full 802.11 Preferred Network List (PNL) disclosure in windows Mobile 6.5”. Raul Siles. Taddong. 2010.
URL:
http://blog.taddong.com/2010/09/vulnerability-in-indiscreet-wi-fi.html
About Taddong:
Taddong (
www.taddong.com) is a company established in Spain in 2010 with the purpose of improving customer's information security, by discovering and eliminating or mitigating the real risks that threaten their networking and information technology infrastructures. To achieve this goal, Taddong's portfolio includes specialized information security services, requiring an in-depth technical knowledge and broad understanding of the information technology market, as well as training services, focused on providing customers with auto-defense skills. Taddong remains at the forefront of the security market through continuous research and education activities.
Disclaimer:
The contents of this security advisory are copyright (c) 2011 Taddong S.L., and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.
Posts
