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.

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

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

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?

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/Xcode-Beta.app" (vs. the default "/Applications/Xcode.app" 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
/Applications/Xcode.app/Contents/Developer

$ sudo xcode-select --switch /Applications/Xcode-Beta.app/
$ xcode-select -p
/Applications/Xcode-Beta.app/Contents/Developer

$ 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:


Monday, October 13, 2014

Attacking Wi-Fi Clients: Introduction

During the last decade, an uncountable number of articles, whitepapers and presentations have been published about Wi-Fi security, hacking, attacks and defenses. Most of that research, including attack techniques and tools, has focused on the infrastructure side, that is, Wi-Fi access points (APs) and networks. These have been the main targets since the early WEP weaknesses announced around 2001. As the Wi-Fi technologies matured, and assuming nowadays (with the right skills and knowledge) it is possible to build a robust and reasonably secure Wi-Fi network, Wi-Fi attacks started to move towards the client side a few years ago. However, despite Wi-Fi client attacks got some early attention around 2005 (thanks to Karma), they blurred over the years. Attacks focused on the Wi-Fi clients have evolved slowly, progressively, sometimes silently but significantly since then, nevertheless from an end user awareness perspective, corporate security perspective, or even from the point of view of major industry leaders and vendors, they have not been taken seriously enough. The reality is that, still today, Wi-Fi clients present multiple vulnerable behaviors that can be leveraged for targeted attacks or even mass exploitation. The situation can only get worse in the upcoming Internet of Things (IoT) or the Wi-Fi Internet of Everything (IoE) age:



On the one hand, the current Wi-Fi client vulnerabilities and misbehaviors might allow an attacker (or pen-tester; I will use the term 'attacker' from now on) to accurately fingerprint specific targets, with significant personal privacy and tracking implications. On the other hand, they can be used to force a victim Wi-Fi client to reveal the networks it is trying to connect to, their security type, and even the associated Wi-Fi network key or user credentials. Additionally, the attacker might force the target Wi-Fi client to connect to its own network, an scenario that opens the door to a huge range of traditional network-based attacks.

The following list briefly outlines multiple aspects that are relevant when describing these kind of Wi-Fi client weaknesses and attacks. These topics are going to be covered in future installments of this "Attacking Wi-Fi Clients" DinoSec blog post series, following this introduction:
  • First of all, it is crucial to understand how modern Wi-Fi clients behave, discover and connect to Wi-Fi networks, including the different options available for the end user to select a new network, as well as the technical details and 802.11 frames involved in the process.
  • One critical element that is involved in that selection and connection process is the Preferred Network List (PNL), that is, a local client repository (or database) that contains the list of known Wi-Fi networks the client has connected to in the past.
  • From a security perspective, the way the PNL is used by Wi-Fi clients determines the attack opportunities. Multiple factors influence the PNL usage, including if the client connects automatically to known networks, which network is selected when multiple known networks are available, what specific Wi-Fi network details the identification process is based on, etc.
  • In addition to the PNL usage, the PNL management features available for the end user (or corporate environment) also determine the PNL contents and the defensive capabilities. Wi-Fi clients should provide features to fully manage the PNL, including its visualization, selecting the priority of the different networks available in the PNL, as well as management options to add, delete or edit all the properties of any Wi-Fi network contained inside the PNL. However, we are currently facing various challenges, such as anomalies to be able to properly manage the Wi-Fi PNL (Preferred Network List) in modern mobile devices, like iOS, or even in traditional operating systems whose previous versions had the required capabilities, like Windows 8. The iOS constraints can be partially overcome by skilled users or enterprises via the iStupid tool (that I already described in several previous blog posts).
  • Unfortunately, and although some traditional Wi-Fi clients fixed this specific vulnerable behavior a few years ago, still today several Wi-Fi clients disclose the contents of their PNL for free. There are multiple scenarios and reasons where Wi-Fi clients unnecessarily reveal their PNL all over the air (the details will be covered latter in the series). For example, multiple vulnerabilities have been published since 2010 affecting modern mobile devices and the way a new Wi-Fi network is manually added by the user to the PNL through the user interface. Anyone monitoring the wireless traffic can easily obtain the details of the PNL, and as a result, identify the list of Wi-Fi networks the client device is trying to connect to.
  • The fact that Wi-Fi clients still disclose their PNL for free today, together with its MAC address, entails significant privacy implications and security risks. Although recently the EFF emphasized the associated privacy risks, something we knew about wireless pervasive technologies since around 2008, the main concern must be centered on the security threats. Anyone that identifies the PNL of a given target, that is the list of Wi-Fi networks the client device is trying to connect to, can easily impersonate these legitimate networks through a fake AP. As a result, multiple attack scenarios are viable, depending on the security mechanisms used by the legitimate network. By the way, the legitimate Wi-Fi network security type can be easily identified using different impersonation techniques.
  • The simplest and easiest scenario is targeting an open Wi-Fi network, as only the network name is required to impersonate the legitimate network and get the victim client to automatically connect to it. However, even for the security conscious (or "paranoid") user, that never ever connects to an open (or WEP-based network), there are additional security risks to consider.
  • When a WEP or WPA(2)-PSK network is impersonated, the legitimate Wi-Fi network key is required for the victim client to establish a connection with the fake AP. There are two WEP-based attacks that can obtain the original key from the victim Wi-Fi client: Caffe-Latte and Hirte. Similarly, for WPA(2)-PSK networks it is possible to capture two frames of the initial 4-way WPA(2) handshake in an AP-less scenario with the goal of cracking the PSK via dictionary attacks or rainbowtables (for the name of that specific Wi-Fi network). These kind of attacks provide two benefits to the attacker: On the one hand, the valid key for the legitimate network can be obtained, therefore, if the location of that legitimate network is known or can be obtained through other methods, the attacker would be able to connect to it. On the other hand, the victim client will connect to the attacker's network regardless of where the attack is taking place.
  • Finally, Wi-Fi network impersonation attacks focusing specifically on Wi-Fi Enterprise networks based on 802.1x/EAP can use various offensive methods to obtain the user enterprise credentials, and once again, even get full client connectivity between the victim and the attacker (in some scenarios). The following handmade draft table shows four different Wi-Fi enterprise client attacks, including their main pros and cons, FreeRADIUS-WPE, EAP LEAP-Down, EAP Dumb-Down, and LEAP2PEAP Relay:
  • Once the network is shared at layer 1 & 2 (and above) between the attacker and the victim, traditional full Man-in-the-Middle (MiTM) attacks are possible, via ARP poisoning and other TCP/IP (and upper protocols and services) tricks.
  • Besides attacking Wi-Fi clients using legitimate 802.11 traffic through a fake AP, it is possible to manipulate 802.11 frames to launch other types of attacks, such as Denail of Service (DoS) attacks affecting specific Wi-Fi chipsets, launch web-based injection attacks throughout 802.11 frames, or go deeper into the almost forgotten 802.11 driver attacks.
  • Finally, understanding in detail these weaknesses and attacks, as well as the associated countermeasures and defensive opportunities and alternatives both at the user and the enterprise level, is the only way to properly mitigate the risk against these real-world Wi-Fi client attacks.
Some related contents are available on my RootedCON 2013 presentation, named "Wi-Fi: Why iOS (Android & others) Fail inexplicably" (video available in Spanish), and several presentations that followed and were part of a subsequent awareness campaign I did at the end of 2013 and early 2014.

How Can I Start Taking a Look At The Wi-Fi Client Activities Around Me?

As this introduction is mainly theoretical, for the curious readers that cannot wait until the publication of the next blog post in this series and want to start taking a look at the Wi-Fi client activities around them, and the potential disclosure of the PNL from vulnerable Wi-Fi clients, there are a few options, depending on the operating system you plan to use: Linux, OS X or Windows

In Linux you only need to have a Wi-Fi card that supports monitor (or RFMON) mode. Configure the card in monitor mode (via the "airmon-ng" command available in the aircrack-ng suite, or by directly using the "iw phy phy0 interface add mon0 type monitor" command), and start using Wireshark (or tshark from the command line) to capture the traffic from that specific Wi-Fi interface (commonly identified as "mon0").

In OS X you can follow similar steps when using the default 802.11 Airport Extreme Wi-Fi card. From the "Capture - Options..." menu in Wireshark, by double clicking on the Wi-Fi card (commonly identified as "en1"), the interface can be configured in monitor mode via the "Capture packets in monitor mode" option.

In Windows, although there have been significant constraints to put Wi-Fi cards in monitor mode in the past, thanks to Acrylic Wi-Fi you can configure its associated Wi-Fi driver in monitor mode for your built-in Wi-Fi card. By running Wireshark as Administrator, start capturing traffic from the Acrylic Wi-Fi driver, named with the prefix "Acrylic NDIS" followed by the name of your native Wi-Fi card in the "Capture Interfaces" windows in Wireshark (available from the "Capture -> Interfaces..." menu). If you want to use tshark instead from the command line, using a command promt (cmd.exe) running as Administrator, run "tshark.exe" with the "-D" option to identify all the network interfaces available. The Acrylic Wi-Fi driver associated to your card (in this case, ID number 3) will look like this:
...
3. \\.\airpcap11_{ABC...-...-...DEF}-{012...-...-...789}-0000 (Acrylic NDIS <your_Wi-Fi_card_name>)


If you are using Wireshark, your favorite display filter in order to capture the 802.11 probe request frames that may disclose specific names for the Wi-Fi networks contained in the PNL of vulnerable Wi-Fi clients should be:

(wlan.fc.type_subtype == 0x04) && !(wlan_mgt.ssid == "")

If you are using tshark from the command line, you can use the following command in order to extract some of the most relevant details from the same interesting 802.11 probe request frames:

(Linux, OS X & Windows; simply change the Wi-Fi interface name with the "-i" option)
C:\Temp>tshark -i 3 -n -l -s 0 -T fields -E separator=, -E quote=d -e wlan.sa -e
 radiotap.dbm_antsignal -e wlan_mgt.ssid -Y "wlan.fc.type_subtype == 4 and !(wla
n_mgt.ssid == \"\")"

or
$ sudo tshark -i mon0 ...


Shameless Plug - "Attacking Wi-Fi Clients: Hands-on Workshop"

I have authored a hands-on technical workshop, called "Attacking Wi-Fi Clients" (or "Técnicas de ataque sobre clientes Wi-Fi" in Spanish), with the goal of bringing together real-world personal experience, research, and pen-testing tips & tricks for Wi-Fi client attacks collected during the last few years. The workshop covers in-depth all the topics of the upcoming "Attacking Wi-Fi Clients" DinoSec blog post series (of which this is the first installment), and much more... The material is available in English and is delivered both in English or Spanish.

This workshop  focuses on providing the attendees real-world hands-on experience identifying and researching Wi-Fi clients weaknesses, and executing multiple Wi-Fi client attacks in different scenarios, with specific emphasis in the layer 2 802.11 and associated protocols, like 802.1x/EAP, versus more traditional TCP/IP client attacks. The attendees get their own Alfa Wi-Fi USB card (in particular the current best model identified for this kind of Wi-Fi client offensive activities) and leave the workshop with a fully functional virtual machine based environment ready for Wi-Fi pen-testing activities or deeper research and vulnerability discovery. At the end of the session, the defensive countermeasures required to mitigate the previously covered Wi-Fi attacks are also analyzed. The workshop is available in both a very intense one-day session (bootcamp style) or in a two-day extended format, that can be delivered in both security conferences and private onsite events (contact me if you are interested).

The first sold-out workshop session took place during the RootedCON trainings (called RootedLabs) on March 3, 2014, with very good feedback from the audience. Recently, the workshop has been significantly updated for an upcoming session that will take place in about three weeks during the NoConName (NcN) trainings (October 30, 2014). The NcN workshop price includes a conference ticket, so... if you are in Spain at the end of this month and speak Spanish, you cannot miss it! :-) My goal by offering this highly specialized but affordable workshop is focused on helping to improve the overall quality of Wi-Fi security pen-tests and assessments, and in particular, in identifying the current Wi-Fi clients risks and threats, while promoting future additional related Wi-Fi research in the upcoming Wi-Fi Internet of Everything (IoE) era (contributing to the health and wealth of the Spanish security conferences and local security community is an added value :-)

Image source: http://www.wi-fi.org/sites/default/files/images/IoE_Graphic.jpg
Image source: http://www.wi-fi.org/sites/default/files/images/Wi-Fi_Connect_your_life.jpg

Wednesday, September 24, 2014

Bypassing iOS Lock Screens: A Comprehensive Arsenal of Vulns

UPDATED: Up to iOS 8.1.1 & iP-BOX (Jan 21, 2015)

The iOS mobile platform has been subject to numerous lock screen bypass vulnerabilities across multiple versions. Although Apple strives to fix these vulnerabilities in various updates to iOS (http://support.apple.com/kb/ht1222), it is important for information security professionals and pen testers to pay close attention to the current unfixed lock screen bypass scene at any given time, evaluate its risks, and promote enforcing physical security and tight access controls on iOS devices.

Shameless plug: If you are interested in this kind of information and want to learn more, Raul Siles will be teaching the 6-day SANS SEC575: Mobile Device Security and Ethical Hacking course in London, UK (Nov 17-22, 2014), Amsterdam, The Netherlands (May 11-16, 2015), and (again in the Summer) London, UK (Jul 13-18, 2015).

Many pen testers tend to focus more on traffic or network activity analysis and attacks, Mobile Device Management (MDM) and back-end systems auditing, jailbreaking or rooting opportunities, or in-depth mobile applications analysis, leaving unattended scenarios with physical access to a target device, or the stolen or loss device threat. However, real incidents constantly confirm unattended or stolen devices with a lockscreen bypass vulnerability are a serious threat that should be included, or at least evaluated, when scoping a mobile pen testing exercise.

Throughout the years, I've been researching, testing, and collecting a list of all these iOS lock screen bypass vulnerabilities for pen testing engagements, presentations, and training sessions. Some of them are related to other hardware components, such as the SmartCover or the SIM card, while others are purely driven by new software features and capabilities, such as Siri or the new Control Center in iOS 7. Some issues impact only iPads or just iPhones, while others affect them all. History ratifies it is hard for Apple to fully mitigate this threat, as the attack surface is significantly wide, and it even increases with newer versions of the iOS platform.

The following list summarizes the history of all the lock screen bypass vulnerabilities that iOS has suffered from iOS 5 to the recent iOS 8. It also includes links to demos and/or videos associated with each vulnerability. The vulnerabilities have been classified based on the iOS version that provides the appropriate fix. Therefore, iOS versions earlier than the one providing the fix are potentially effected by each vulnerability.

The official number of screen lock bypass related vulnerabilities addressed in each major iOS version are:
  • iOS 5.x: 4 vulnerabilities.
  • iOS 6.x: 8 vulnerabilities.
  • iOS 7.x: 12 vulnerabilities.
  • iOS 8.0: 6 vulnerabilities (so far!!!).

iOS Lock Screen Bypass Vulnerability History

The following list has been sorted by iOS version, starting first with a list of generic lock screen bypasses with no officially recognized CVE associated to them (only for this generic section, entries are sorted by date and the iOS version specified refers to the vulnerable iOS version):
NOTE: Since all of these vulnerabilities have not been officially acknowledged by Apple, it is sometimes complex to identify duplicates or missing ones. If you identify any discrepancy, inaccuracies, or additional references or videos, please let me know.

Protecting iOS Devices Against Lock Screen Bypass Vulnerabilities

This extensive list of iOS lock screen bypass vulnerabilities can be exploited by anyone that gets physical access to a target device, even temporarily. It is therefore crucial for both security professionals and pen testers, as part of their recommendations within pen test reports, to provide countermeasures that mitigate the associated risks. In fact, unless an organization is impeccable in their patching and update process, you are pretty much guaranteed to find an older version of iOS on some of their devices that could lead to a significant finding. And, if the organization employs a Bring Your Own Device (BYOD) policy, again you are ensured of a proliferation of older versions ripe for attack. If you can gather information about the use of such devices, you’ll have a nice finding for your report.

In order to minimize the impact of lock screen bypass vulnerabilities in iOS devices, it is highly recommended to always update the mobile device to the latest iOS version available, which supposedly fixes all the publicly known vulnerabilities, and manually (or though an MDM solution) verify that you really are in the latest and expected iOS version (http://blog.dinosec.com/2014/06/ios-back-to-future.html).

Besides that, in iOS some of the (current and future) lock screen bypass vulnerabilities can be mitigated by limiting the functionality available in the lock screen. The following list (that applies to the current iOS 8 version, with additional clarifications for iOS 7) summarizes various recommended configuration options currently available to protect the lock screen on iOS devices. Of course, turning off these functions can improve security by lowering the attack surface, but also may anger users who aren’t able to utilize the latest gee-whiz features of their devices. Evaluate each of these actions before applying them, as there is always a security versus usability trade off associated to disabling the functionality and features available in the lock screen without requiring the user to enter a passcode. For organizations requiring a high degree of security, though, these hardened configurations should at least be considered:

  • Disable Siri (or Voice Dial, if Siri is not enabled; watch out as Music Voice Control is always enabled (*)) when the device is locked: Navigate to "Settings –> Passcode –> Siri (or Voice Dial)" and disable it there ("Allow access when locked: Siri = OFF"):
  • Disable Passbook when the device is locked: Navigate to "Settings –> Passcode –> Passbook" and disable it there ("Allow access when locked: Passbook = OFF").
  • Disable the Control Center from the lock screen to avoid exposing sensitive controls, such as enabling/disabling the Wi-Fi or Bluetooth interfaces, or even airplane mode: Navigate to "Settings –> Control Center –> Access on Lock Screen = OFF". The multiple controls available in Control Center cannot be customized; therefore it can only be enabled or disabled completely.
  • Disable the Notification Center, and specifically, its availability from the lock screen, including Today View (new since iOS 7). In iOS 8, navigate to "Settings –> Passcode –> Allow access when locked:" and disable both "Today" and "Notifications View":
  • To accomplish the same task in iOS 7, navigate to "Settings –> Notification Center –> Access on Lock Screen" and disable both, "Notifications View" and "Today View".
  • More granular notification settings can be configured for each individual app from the "Include" section of Notification Center. Apps can be completely unlinked from Notification Center by accessing their settings and turning off notifications. In iOS 8, go to "Settings –> Notifications –> –> Allow Notifications = OFF". The app will be moved to the "Do Not Include" section at the bottom (e.g. Twitter app):
  • Additionally, the "Show on Lock Screen" setting from the same menu allows defining if the individual app notifications will be available on the lock screen or not. In iOS 7, these and other adjustments in the next set of recommendations were available under "Settings –> Notification Center –> ..." instead. In iOS 7, to unlink an app from the Notification Center go to "Settings –> Notifications –> –> Show in Notification Center = OFF".
  • iOS allows answering back a phone call without knowing the passcode by simply swapping the missed call notification available in the lock screen. This behavior cannot be disabled, except by not showing this kind of missed call notification in the lock screen (go to "Settings –> Notifications –> Phone –> Show on Lock Screen = OFF"):

  • Similar recommendations apply to other apps that can also show sensitive information in the lock screen, such as Messages. It is recommended to disable the preview of Messages by going to "Settings –> Notifications –> Messages –> Show Previews = OFF" (a specific issue with this setting has been fixed in iOS 8, CVE-2014-4356):
 
  • In order to avoid issues with the SmartCover in iPad devices, its usage can be disabled from "Settings –> General –> Lock/Unlock":

  • Disable the camera: In order to remove the quick camera access icon from the lock screen, completely restrict access to the camera via "Settings –> General –> Restrictions" and disable the 'Camera', which will also turn off FaceTime. As there is no other way to simply disable the quick camera access icon, this radical countermeasure is the only option available to avoid someone taking pictures from your iOS device:
  • Establish a passcode with at least one alphabetic character, so that the look & feel of the iOS lock screen does not disclose if your passcode is just a PIN (4 digits), is made up of just digits (more than 4), or (preferred option) is alphanumeric.
  • ... and remember to frequently physically clean up the screen of your iOS devices too to avoid fingerprints, residues and smudge revealing your passcode :-)
(*): Voice Dial is always enabled since iOS 7.1, and there is no configuration option to disable it, as it was the case in previous iOS versions (e.g. 7.0.x) from "Settings -> General -> Passcode Lock -> Voice Dial" (since iOS 7.1 it should be under "Settings -> Passcode").

All these recommended actions can be manually implemented through the Settings app or (most of them) via a configuration profile that can be pushed to the target iOS mobile devices through an MDM solution. Both offensive attack opportunities and defensive protections are thoroughly covered in the SANS SEC575: Mobile Device Security and Ethical Hacking course, with the main goal of testing and improving the overall security of corporate mobile environments.

NOTE: This article has been crossed posted in both the SANS Pen-Testing Blog (here) and DinoSec's Blog (here) in September 2014.