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.
                                            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: , ,

                                            Wednesday, June 4, 2014

                                            iCamasu

                                            For the iOS updates security research I presented at both RootedCON and Area41 this year (more details will be published in an upcoming blog post... still waiting for a fix!), I processed and analyzed (several times and in multiple ways over the last 2.5 years) the PLIST files used by Apple devices to check for new iOS updates. Since iOS 5, and due to the new OTA (Over-the-Air) update capabilities introduced with that version, every time a new iOS update is available, a new file containing the list of official iOS versions and the mobile devices supported by each of them is published at http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdate/
                                            com_apple_MobileAsset_SoftwareUpdate.xml, together with the associated iOS documentation file, available at http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdateDocumentation/
                                            com_apple_MobileAsset_SoftwareUpdateDocumentation.xml.

                                            iCamasu, iOS com_apple_MobileAsset_SoftwareUpdate, is a Python-based tool that parses and extracts multiple details from Apple iOS software update PLIST files,"com_apple_MobileAsset_SoftwareUpdate.xml" (BTW, the tool does not parse the associated documentation files).

                                            iCamasu provides multiple parsing options to select the input file (-f), extract the minimum (-m) and maximum (-M) iOS versions currently available, show a brief summary (-s or -S) including the SHA-1 hash for the file and its size, the number of assets or entries, devices, and iOS versions, and allows classifying the current iOS versions by device (-D) or iOS version (-I). Additionally it includes search capabilities by device (-d) or iOS version (-i), and a more verbose output and extended details via the "-v" and "-F" options.

                                            iCamasu usage examples:



                                            If you plan to do any iOS research related with new updates or iOS versions, I hope you find iCamasu useful to easily dig deeply into the PLIST file contents. As usual, the tool is available at DinoSec's Lab (where future major versions will be published too) and also in the new DinoSec GitHub repository, in case you want to contribute updates and feedback. The first public version is 0.41, as for the Area41 conference where it was released, and runs on Linux, OS X and Windows.
                                            By Raul Siles at June 04, 2014 0 comments
                                            Labels: ,
                                            Subscribe to: Posts ( Atom )