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
By Raul Siles at October 13, 2014 0 comments
Labels: , ,

Wednesday, September 24, 2014

Bypassing iOS Lock Screens: A Comprehensive Arsenal of Vulns

UPDATED: Up to iOS/iPadOS 18.0, 17.7, 16.7.10, 15.8.3, 14.8.1, 13.7 & 12.5.7 (Sep 20, 2024)

The iOS mobile platform has been subject to numerous lock screen bypass vulnerabilities across multiple versions during the last years. Although Apple strives to fix these vulnerabilities through various iOS updates (https://support.apple.com/en-us/HT201222), it is important for information and cyber 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 technical details and want to learn more, Raul Siles will be teaching future SANS courses, such as the 6-day "SANS SEC575: Mobile Device Security and Ethical Hacking" course in:
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 unauthorised physical access to a target device, or the stolen or loss device threat. However, real incidents constantly confirm unattended or stolen devices with a lock screen bypass vulnerability are a serious threat that should be included, or at least evaluated, when scoping a mobile pen testing assessment.

Throughout the years, I've been researching, testing, and collecting a list of all these iOS lock screen bypass vulnerabilities for pen testing engagements, security 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, VoiceOver or the new Control Center introduced since 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 summarises the history of all the lock screen bypass vulnerabilities that iOS has suffered from iOS 5 to the most recent iOS version (until the last update :-). 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 (and since September 2019, in iPadOS) version are:
  • iOS 5.x: 4 vulnerabilities.
  • iOS 6.x: 8 vulnerabilities.
  • iOS 7.x: 12 vulnerabilities.
  • iOS 8.x: 11 vulnerabilities.
  • iOS 9.x: 6 vulnerabilities.
  • iOS 10.x: 10 vulnerabilities.
  • iOS 11.x: 10 vulnerabilities.
  • iOS 12.x: 8 vulnerabilities.
  • iOS 13.x: 4 vulnerabilities.
  • iOS 14.x: 7 vulnerabilities.
  • iOS 15.x: 11 vulnerabilities.
  • iOS 16.x: 10 vulnerabilities.
  • iOS 17.x: 12 vulnerabilities.
  • iOS 18.x: 4 vulnerabilities (officially, so far!!!).
NOTE: Throughout this article, iOS refers to both, iOS and iPadOS.

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 recognised 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):
By iOS version:
  • iOS 18.0 (Sep 2024): https://support.apple.com/en-us/121250
    • Accessibility: An attacker with physical access to a locked device may be able to Control Nearby Devices via accessibility features (CVE-2024-44171).
    • Accessibility: An attacker may be able to see recent photos without authentication in Assistive Access (CVE-2024-40852).
    • Siri (2 CVEs): An attacker with physical access may be able to access contacts from the lock screen (CVE-2024-44139) (CVE-2024-44180).
                                            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 summarizes various recommended configuration options currently available to protect the lock screen on iOS devices (it is outdated, as it applies to iOS version 8, with additional clarifications for iOS 7; however, the concepts can also be applied to newer iOS versions). 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.
                                            By Raul Siles at September 24, 2014 0 comments
                                            Labels: , ,

                                            Tuesday, June 24, 2014

                                            iOS: Back To The Future

                                            UPDATE (January 25, 2015): New details regarding "iOS: Back to the Future II" released.

                                            UPDATE (September 17, 2014): Apple has addressed the "iOS: Back to the Future" vulnerability in iOS 8 and it has been identified with CVE-2014-4383.

                                            Apple mobile devices based on the iOS platform, such as iPhones and iPads, implement multiple protection mechanisms and platform restrictions to fulfill several security requirements and support Apple's lucrative business model.
                                            In early 2012 I found a vulnerability that allows the manipulation of a sensitive core default iOS capability, the iOS device update process. The iOS update process is protected by System Software Authorization, which prevents downgrading iOS devices to previous versions of this operating system. This measure can be partially circumvented by freezing the mobile device to its current iOS version.

                                            An attacker in a Man-in-the-Middle (MitM) position (e.g. connected to the same public Wi-Fi hotspot as the victim, or by impersonating one of the legitimate Wi-Fi networks the iOS device wants to connect to)  can intercept the iOS update check traffic of a target device. Through the modification of HTTP requests and/or responses, specifically some dates in the headers, as well as implementing replay attacks, can force the target device to think its current version is the latest iOS version available.

                                            The vulnerability can be used in carefully planned targeted attacks to temporarily or permanently freeze the current version of an iOS device. Before notifying the vulnerability to Apple (on February 6, 2014), the iOS version of Apple's devices could be permanently frozen to any time in the future, effectively setting its iOS version forever. In its current state, the version of iOS 7 devices can be permanently frozen up to the next update, while previous iOS versions still remain completely vulnerable. The temporary attacks still apply to all affected iOS versions.

                                            Once the iOS version has been frozen, this attack facilitates the exploitation of other vulnerabilities potentially targeting a specific version of this mobile platform, such as the 197 vulnerabilities fixed in iOS 6.0, or the 80 vulnerabilities fixed in iOS 7.0 (plus all the others fixed between major iOS versions). It is scary to think how many potential victims could have been attacked by this vulnerability during the last two and a half years, allowing both massive device manipulation attacks as well as stealthier and targeted attacks (that can also be reverted back silently).


                                            The design flaw affects the multiple Apple mobile devices (iPhone, iPad, iPad mini, iPod Touch..) since iOS version 5 up to the latest iOS 7 version (7.1.1). In iOS 5, Apple introduced new wireless capabilities to perform specific operations Over the Air (OTA), actions that previously required the usage of USB cables, such as iCloud backups, iTunes data synchronization and backups over Wi-Fi, or iOS software updates. This behavior introduced the aforementioned vulnerability, which can be exploited in iOS 5, 6 & 7 by applying core principles from movies like Back to the Future, Star Wars or Matrix ;)


                                            Although the flaw was discovered in early 2012, it has remained private while researching and evaluating first hand the current immature and controverted vulnerability disclosure models, the real interests of modern vulnerability markets and brokers, as well as other vulnerability discovery implications, topics that have also been discussed during my talks.

                                            I disclosed this vulnerability this year both at the 5th anniversary of the RootedCON 2014 conference (Madrid, Spain, March 2014) and at the 1st anniversary of the "new" Area 41 conference (Zurich, Switzerland, June 2014). More information about the vulnerability is available on both slide decks, as well as in the associated videos, with exploitation demos. They include the overall impact of the vulnerability, all the associated technical details surrounding System Software Authorization and how the iOS update process works, the vulnerability behavior in iOS 5, 6 and 7, and its history, limitations, and complementary tools used during the research process, such as iCamasu (new 0.42 version released):


                                            NOTE: The video is currently available only in Spanish from RootedCON. The English version of the video (and presentation) from Area41 will be released in a few weeks. Follow @dinosec for updates.

                                            Unfortunately, due to the fact the vulnerability has not been completely addressed by Apple yet, the iProxy tool and the archive of previous iOS software update plist files mentioned in the talks are not going to be publicly released. These two allow weaponizing its exploitation in real-world scenarios. However, it is crucial for organizations at this point to know about this vulnerability in order to take proactive countermeasures, such as verifying their managed iOS devices are running the latest, or expected, iOS version via their MDM solution.

                                            My hope is that the vulnerability will be fixed in iOS 8 later this fall, but still several unanswered questions remain open: Why Apple didn't use HTTPS (and certificate pinning) for the iOS update check process? Was it due to performance reasons? Even in this case, it is crucial to differentiate between the update check process (to verify if there is a new version available) and getting the update contents, that is, the update process itself (to download and install the new available version).

                                            We definitely do not learn from the past and repeat the same mistakes, again and again, regarding how to use technology in a secure way... Perhaps due to its increasing complexity or perhaps, wait... intentionally... Once again, the debate opens the door to reflect on the current technologies and the inherent weaknesses of our modern information society, sophisticated but vulnerable.
                                            By Raul Siles at June 24, 2014 0 comments
                                            Labels: , ,
                                            Subscribe to: Posts ( Atom )