Friday, February 20, 2015

Why Do Wi-Fi Clients Disclose their PNL for Free Still Today?

Shameless plug: Don't miss this year 2015 RootedLab, a great opportunity to learn and practice effective client Wi-Fi attacks (& defenses) though a new updated hands-on workshop full of tips and tricks and real-world pen-testing advice: "Técnicas de ataque sobre clientes Wi-Fi". It will take place in Madrid on March 4 (in two weeks) in Spanish, and right now there are only a few seats available (check also the other interesting workshops, called RootedLabs, that are running before this year RootedCON conference). During the workshop we will cover in-depth all the topics from the introductory blog post, from this blog post, and put in practice traditional and new advanced attacks (FreeRADIUS-WPE, EAP LEAP-Down, EAP Dumb-Down, LEAP2PEAP relay...), and much more..., such as (not released yet) new FreeRADIUS-WPE patches for the LEAP-Down attack, or a new iStupid version (v1.4) implementing the DoS Wi-Fi Direct attack against Android 4.x devices (CVE-2014-0997).

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

There are scenarios where Wi-Fi clients still disclose their PNL, that is, the list of known Wi-Fi networks the client has connected to in the past, and it is willing to connect to again, now and in the future. This weakness in the default behavior of Wi-Fi clients (part of the IEEE 802.11 specification) was discovered around the end of 2004, early 2005, and tools were released to exploit it by automatically impersonating any open network the client device tries to connect to, such as Karma. Alternative tools have been published over the years, such as Karmetasploit or airbase-ng. Although in January 2007 Microsoft released an optional client update to prevent the wireless advertising of the PNL for Windows XP SP2, still today lots of Wi-Fi clients are vulnerable.

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.


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.


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.


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).

Friday, February 6, 2015

iOS Passcode Recovery with iPhone Data Protection Tools (Using Yosemite)

Shameless plug: During the first half of this year I will be teaching the 6-day SANS SEC575 training, "SEC575: Mobile Device Security and Ethical Hacking", in Amsterdam, Netherlands (May 11-16, 2015), Madrid, Spain (May 25-30, 2015 in Spanish), and London, UK (July 13-18, 2015).

UPDATE: Xcode 6.2 (March 9, 2015).

Since the early days when the SANS "SEC575: Mobile Device Security and Ethical Hacking" class made its debut around May 2012, Joshua Wright, the SEC575 author, included details for the iPhone Data Protection Tools presented at HITB 2011 in Amsterdam.

We cover this toolset in SEC575 during the "Mitigating the Stolen (or Lost) Device Thread" section on day 2. We like not only covering the tool internals, but are used to run a live demo in class showing attendees how the tool works and how easy it is to obtain a 4-digit passcode in a few minutes without leaving any significant trace on the mobile device. I particularly love to run the live demo and go deeper into the technical details about how the built-in iOS full device encryption and data protection is implemented, the impact of firmware/hardware vulnerabilities (such as the bootrom vulnerability leveraged by the by limera1n's exploitation process), the importance of software and hardware security updates, and how the full keychain contents can be decrypted once the passcode is obtained, exposing multiple sensitive user credentials. Although this particular attack (based on limera1n) can only be launched against Apple devices up to the iPhone 4 and the iPad 1 (using the vulnerable Apple A4 SoC), it can be used to emphasize the attack possibilities and impact of future similar vulnerabilities in other modern Apple devices.

Definitely, running this kind of impressive attack demos in front of C-level executives really help to make the point and create individual users, and corporate, awareness regarding the risks of using 4-digit passcodes, or leaving mobile devices unattended for a few minutes (due to an urgent phone call or meeting, etc) or more (a tablet left in a hotel room during dinner, etc). For this reason, apart from covering the attack details and running the demo in class, in order for the attendees to be able to reproduce it, the SEC575 DVD contains a thorough step-by-step guide describing how to prepare your OS X pen-testing system to launch the attack. Originally, the guide was available for OS X Lion (10.7) and we updated it for OS X Mountain Lion (10.8) a few months later. 

However, due to the fact this is an "old" attack, one of the most challenging tasks over the years is making it work with the latest operating system versions, libraries and modules, development frameworks and languages, and other required dependencies. For this same reason, I have recently updated the guide for OS X Yosemite (10.10), so that you can demonstrate the attack still today if you are running the latest OS X version, and we are making it public out of the SEC575 realm (perhaps reaching out to potential future SEC575 candidates):
This new version of the guide was tested under OS X Yosemite (10.10.1), the associated official Xcode version (6.1.1) and using a couple of target mobile devices, an iPad 1 (running iOS 5.1.1) and an iPhone 4 (running iOS 7.0.4).
Is Your Xcode Environment Vulnerable?

UPDATE: Finally, on March 9, 2015, Apple released Xcode 6.2 fixing the following Git vulnerability (CVE-2014-9390) after more than two and a half months. The new default Git version is "1.9.5 (Apple Git-50.3)".

On December 18, 2014, a vulnerability in Git was released (CVE-2014-9390; in reality this CVE includes three vulnerabilities), affecting multiple Git versions both for Windows and Mac OS X Git clients. It allows remote code execution by rewriting the contents of the ".git" directory, such as the "config" file or the "hooks" sub-directory, for example, through "git pull" or "git checkout" operations. Microsoft released patches for their different Git implementations, GitHub also updated their GitHub for Windows and GitHub for Mac clients, and Apple addressed it in Xcode 6.2 beta 3.

On early January 2015 a Metasploit module was released to exploit this specific vulnerability through an HTTP server designed to simulate a Git repository.

If you are an Apple developer, I expect you to update your Xcode environment frequently to be able to benefit and test the latest features, including the iOS 8.2 SDK with WatchKit support (for Apple Watch) in Xcode 6.2 beta versions. But if you are a security professional and use Xcode for security testing, for tasks like the ones described in this blog post, your Xcode environment might be vulnerable.

At the time of this writing, end of January 2015, the latest official Xcode version available through the App Store is Xcode 6.1.1 (released on Dec 02, 2014). This Xcode version still uses Git v1.9.3 and it is still vulnerable (for almost one and a half months) to CVE-2014-9390:

$ git --version
git version 1.9.3 (Apple Git-50)

In order to install Xcode 6.2 beta 3 (or later beta versions) you need to manually download Xcode using a free (or paid) Apple developer account, and proceed with the installation. The Xcode beta version goes into "/Applications/" (vs. the default "/Applications/" directory). However, even when the beta version has been installed, the Xcode command-line tools (of which Git is part of) will still use the official Xcode version. To switch between the different versions of the Xcode command-line tools, you need use the xcode-select tool (as root):

$ git --version
git version 1.9.3 (Apple Git-50)

$ xcode-select -p

$ sudo xcode-select --switch /Applications/
$ xcode-select -p

$ sudo xcodebuild -license
$ git --version
git version 1.9.5 (Apple Git-50.3)

Therefore, the Git version for Xcode 6.2 beta 4 is 1.9.5, not vulnerable to CVE-2014-9390. Time to update your Xcode version!

Sunday, January 25, 2015

iOS: Back To The Future II

Last year I disclosed publicly the "iOS: Bact to the Future" vulnerability affecting iOS Apple devices, from version 5.x up to version 7.x (the video of the presentation is available in Spanish, and dubbed into English). Anyone intercepting the target mobile device traffic could freeze a iOS victim device into its current operating system (OS) version forever. Once I notified Apple, in March last year they modified their update servers to behave differently when they identify a client request with a future date (in the "If-Modified-Since" header). As a result, the vulnerability could be still exploited but limited to freezing the iOS victim device into its current OS version till the next update is released, that is, bypassing the most recent updates available.

In September 2014, Apple addressed the "iOS: Back to the Future" vulnerability in iOS 8 and identified it with CVE-2014-4383. After doing some research I discovered that the changes introduced by Apple in iOS included similar checks as the ones previously described for the update servers but on the client side, in particular when iOS identifies a server response with a future date (in the "Last-Modified" header). However, again, the new verifications only check for future dates, opening the door to manipulating requests and responses with a date between the date of the last update and the current date.

Therefore, last month I presented the current state-of-the-art for this vulnerability as "iOS: Back to the Future II", emphasizing not only that nothing has changed from an exploitation perspective since March 1, 2014, but some deep thoughts about the fact that vulnerabilities might be supposedly fixed, even when a CVE gets assigned to them, but perhaps they are not. Perhaps involving the researchers in the verification process for the fix might help to confirm if the vulnerability is really solved...

Although the presentation is in Spanish, I think you can easily follow the timelines on slides 11 and 19, and the technical details on slides 12, 14, 16 and 17.

The following videos demonstrate the current iOS 8.x behavior in different exploitation scenarios:

1. The first video shows an iPhone device running iOS 8.0.2 attacked using the StarWars (Jedi) temporary variant, although the most recent iOS version available is 8.1:

2. The second video shows an iPhone device running iOS 8.0.2 attacked using the Matrix permanent variant (as if iOS 8.0 were the most recent version on 07 Nov 2014), although the most recent iOS version available is 8.1 (officially published on 20 Oct 2014):

3. The third video shows how the update server replies with the current update when receiving a request with a date in the future (07 Nov 2024), and how when an iPhone device running iOS 8.0.2 is attacked using the Matrix permanent variant (with a response using a date in the future, year 2024), it does not process it, requesting subsequent updates from scratch. The most recent iOS version available is 8.1 (officially published on 20 Oct 2014):

4. The fourth video shows how a previous victim iPhone device running iOS 8.0.2 is manually forced (on purpose, "07 Sep 2014") to discover the most recent iOS version available, 8.1 (officially published on 20 Oct 2014) and it even downloads the current update documentation. Then, it is attacked again using the Matrix permanent variant (as if iOS 8.0 were the most recent version on 07 Nov 2014), and it becomes a victim again:

5. The fifth video shows how the attack is not possible once the victim iPhone device has already downloaded the most recent update (e.g. iOS 8.1), as it does not even try to check for new updates till the local pending update gets installed: