Vulnerability ID: TAD-2010-002
Credits: This vulnerability was discovered by Raul Siles, Founder and Senior Security Analyst at Taddong (www.taddong.com)
Publication date: September 1, 2010
Last update: February 16, 2011 - Windows Mobile 6.1 is vulnerable too. See (UPDATE) marks.
Vendors contacted: Microsoft
Vulnerability description:
Windows Mobile manages Wi-Fi (or 802.11) wireless communications through the Wireless Zero Configuration (WZC) client or service, similarly to the equivalent Windows-based desktop operating systems. Windows Mobile keeps the previous Wi-Fi interface state during the boot process, that is, if the Wi-Fi interface was active during the last shutdown, it will remain turned on after the boot process; if the Wi-Fi interface was off during the last shutdown, it will remain turned off after the boot process.
Unlike the mobile data capabilities (2-3.5G), organizations (and individuals) interested on disabling, or not using at all, the Wi-Fi capabilities of Windows Mobile-based devices can simply switch off the Wi-Fi interface and it will remain disabled unless the user turns it on explicitly. This default behavior is particularly useful in untrusted or "dangerous" locations, where the device owner does not want to disclose the mobile device presence while the phone is turned on (but its data wireless capabilities are turned off), presenting a completely silent profile.
However, Windows Mobile 6.5 is vulnerable to an information disclosure flaw where the mobile device generates 802.11 traffic during the boot process even when the Wi-Fi interface is turned off. As a result, it generates Wi-Fi traffic in the form of 802.11 probe requests asking for the broadcast (or any) network, plus requests for all the hidden networks available on its Preferred Network List (PNL).
This is the expected behavior when the Wi-Fi interface is switched on, but the device should not generate any traffic while the interface is disabled. As a result of this vulnerable behavior, the MAC address of the Wi-Fi interface is revealed into the air, together with all the hidden networks available on the device PNL:
The image above shows the 802.11 probe requests generated for the broadcast network, plus two hidden networks ("wifi" and "Taddong").
The disclosure of the MAC address could seem low impact at first sight, as it is revealed every time the Wi-Fi interface is switched on. However, the impact is much bigger in very sensitive environments (defense, finance, healthcare, etc) where the Wi-Fi interface is always turned off, but other wireless technologies might be used, such as Bluetooth.
Bluetooth uses the device address, knows as the BD_ADDR (Bluetooth Device Address), as a secret, as it is required to establish a connection with a non-discoverable (or non-visible) Bluetooth device. Some vendors (even outside the Windows Mobile world, such as Apple with the iPhone 2G & 3G) assign correlative or sequential addresses to the different wireless interfaces of mobile devices, such as Wi-Fi and Bluetooth. As a result of this vulnerability, the knowledge of the Wi-Fi MAC address automatically discloses the BD_ADDR of the mobile device, exposing it to undesired Bluetooth communications and attacks.
The disclosure of the hidden networks available on the device PNL can be used to launch karma-like attacks [1]. The mobile device discloses the hidden networks while trying to find and connect to these networks if they are available. An attacker can identify the hidden networks (or access points) the mobile device is trying to connect to and impersonate them, forcing the target device to connect to the attacker's network to capture its traffic and launch more advanced attacks.
However, these karma-like attacks will only be possible if the Wi-Fi interface is switched on afterwards, so that the attacker can interact with the device wirelessly. The activation of the Wi-Fi interface will disclose the hidden networks (again), therefore, this vulnerability has the same impact as the one associated to configuring hidden Wi-Fi networks on the device.
The vulnerability exists on the default configuration and there is no setup option to mitigate it or make the mobile device not vulnerable.
Security solutions, workarounds and countermeasures:
We think Microsoft should release a software update to change this vulnerable behavior and keep the Wi-Fi interface silent until it is turned on. Due to the absence of a current or future software update, users must evaluate the physical locations where their Windows Mobile-based devices are switched on. A potential attacker located around the target mobile device during the boot process (in the range of several kilometers or miles, depending on the Wi-Fi hardware available) will be able to capture the information previously mentioned.
Additionally, users can reduce the impact of this vulnerability removing all the hidden networks from the PNL, and as a result, only allowing connections to not hidden or broadcast Wi-Fi networks.
Vulnerable platforms:
Windows Mobile 6.5 Professional (5.2.21869 - 21869.5.0.82)
Windows Mobile 6.1 Professional (5.2.21006 - 21006.1.5.74) (*)
(*) Windows Mobile 6.1 presents the same behavior described for Windows Mobile 6.5,
(UPDATE) Additional tests on Windows Mobile 6.1 confirm that this OS version is also vulnerable to this issue, disclosing the hidden networks contained in the PNL during the boot process like Windows Mobile 6.5.
Non-vulnerable platforms:
Windows Phone 7 (**)
(**) Microsoft states Windows Phone 7 is not affected by this vulnerability, but this fact has not been tested and/or confirmed.
Vendor information:
Microsoft has confirmed the existence of this vulnerability, although an update for the Windows Mobile WZC won't be released:
"We have completed our investigations and can confirm that we saw the behavior reported by you on the Windows Mobile 6.5 phone. However, this issues constitutes a Low severity Information Disclosure issue which does not meet our bar for a security bulletin release."
We at Taddong honestly believe this finding must be publicly known by the information security community in order to take appropriate countermeasures and mitigate the vulnerable behavior. Therefore, we have coordinated the release of this security advisory together with the vendor, following responsible disclosure principles.
Vulnerability report timeline:
2010-08-05: Taddong notifies the Microsoft security team about the vulnerability and sends a brief technical report.
2010-08-05: The Microsoft security team acknowledges the vulnerability report.
2010-08-20: The Microsoft security team confirms the vulnerability and notifies that an associated security bulletin or software update won't be released.
2010-08-23: Taddong notifies the Microsoft security team about the behaviour in Windows Mobile 6.1 (initial research was focused on Windows Mobile 6.5).
2010-08-23: The Microsoft security team acknowledges the vulnerability update.
2010-09-01: Taddong publishes security advisory TAD-2010-002.
2011-02-16: Additional tests on Windows Mobile 6.1 confirm it is vulnerable to this issue.
References:
[1] "KARMA Wireless Client Security Assessment Tools". Dino A. Dai Zovi. 2004.
http://theta44.org/karma/index.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) 2010 Taddong S.L., and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.
Posts
No comments:
Post a Comment