Showing posts with label iOS. Show all posts
Showing posts with label iOS. Show all posts

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


Wednesday, September 24, 2014

Bypassing iOS Lock Screens: A Comprehensive Arsenal of Vulns

UPDATED: Up to iOS/iPadOS 26.0.1, 18.7.1, 17.7.10, 16.7.12, 15.8.5, 14.8.1, 13.7 & 12.5.7 (Sep 30, 2025)

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:
  • (last session) Future SANS SEC575 sessions with Raul Siles in 2026...

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: 12 vulnerabilities.
  • iOS 16.x: 11 vulnerabilities.
  • iOS 17.x: 19 vulnerabilities.
  • iOS 18.x: 21 vulnerabilities.
  • iOS 26.x: 2 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).
  • iOS 18.0.1 (Oct 2024): https://support.apple.com/en-us/121373
    • N/A (empty).
  • iOS 18.1 (Oct 2024): https://support.apple.com/en-us/121563
    • Accessibility: An attacker with physical access to a locked device may be able to view sensitive user information (CVE-2024-44274).
    • Siri: An attacker with physical access may be able to access contact photos from the lock screen (CVE-2024-40851).
    • Spotlight: An attacker may be able to view restricted content from the lock screen (CVE-2024-44251).
    • Spotlight: An attacker may be able to view restricted content from the lock screen (CVE-2024-44235).
    • VoiceOver: An attacker may be able to view restricted content from the lock screen (CVE-2024-44261).
  • iOS 18.1.1 (Nov 2024): https://support.apple.com/en-us/121752
    • N/A (empty).
  • iOS 18.2 (Dec 2024): https://support.apple.com/en-us/121837 
    • VoiceOver: An attacker with physical access to an iPadOS device may be able to view notification content from the lock screen (CVE-2024-54485).
  • iOS 18.2.1 (Jan 2025): N/A (This update has no published CVE entries)
    • N/A (empty).
  • iOS 18.3 (Jan 2025): https://support.apple.com/en-us/122066
    • Accessibility: An attacker with physical access to an unlocked device may be able to access Photos while the app is locked (CVE-2025-24141).
  • iOS 18.3.1 (Feb 2025): https://support.apple.com/en-us/122174 
    • Accessibility: A physical attack may disable USB Restricted Mode on a locked device; reports of exploitation in targeted sophisticated attacks (CVE-2025-24200).
  • iOS 18.3.2 (Mar 2025): https://support.apple.com/en-us/122281
    • N/A (empty).
  • iOS 18.4 (Mar 2025): https://support.apple.com/en-us/122371 
    • Focus: An attacker with physical access to a locked device may be able to view sensitive user information (CVE-2025-30439).
    • Kernel: A malicious app may be able to attempt passcode entries on a locked device and thereby cause escalating time delays after 4 failures (CVE-2025-30432).
    • MobileLockdown: An attacker with a USB-C connection to an unlocked device may be able to programmatically access photos (CVE-2025-24193).
    • Photos: A person with physical access to an iOS device may be able to access photos from the lock screen (CVE-2025-30469).
    • Share Sheet: A malicious app may be able to dismiss the system notification on the Lock Screen that a recording was started (CVE-2025-30438).
    • Siri: An attacker may be able to use Siri to enable Auto-Answer Calls (CVE-2025-30436).
    • Siri: An attacker with physical access may be able to use Siri to access sensitive user data (CVE-2025-24198).
  • iOS 18.4.1 (Apr 2025): https://support.apple.com/en-us/122282
    • N/A (empty).
  • iOS 18.5 (Apr 2025): https://support.apple.com/en-us/122404
    • Notes: An attacker with physical access to a device may be able to access notes from the lock screen (CVE-2025-31228).
  • iOS 18.6 (Jul 2025): https://support.apple.com/en-us/124147
    • N/A (empty).
  • iOS 18.6.1 (Aug 2025): N/A (This update has no published CVE entries)
    • N/A (empty).
  • iOS 18.6.2 (Aug 2025): https://support.apple.com/en-us/124925
    • N/A (empty).
  • iOS 18.7 (Sep 2025): https://support.apple.com/en-us/125109
    • Notes: An attacker with physical access to a device may be able to access notes from the lock screen (CVE-2025-43203). - Not specific to the lock screen, but related -
  • iOS 18.7.1 (Sep 2025): https://support.apple.com/en-us/125327
    • N/A (empty).
  • iOS 26.0 (Sep 2025): https://support.apple.com/en-us/125108
    • Notes: An attacker with physical access to a device may be able to access notes from the lock screen (CVE-2025-43203). - Not specific to the lock screen, but related -
    • Text Input: Keyboard suggestions may display sensitive information on the lock screen (CVE-2025-24133).
  • iOS 26.0.1 (Sep 2025): https://support.apple.com/en-us/125326
    • N/A (empty).
                                            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.