Wednesday, September 24, 2014

Bypassing iOS Lock Screens: A Comprehensive Arsenal of Vulns

UPDATED: Up to iOS 8.0.2 (Sep 25, 2014)

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

Tuesday, June 24, 2014

iOS: Back To The Future

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.

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.

Thursday, February 20, 2014

DinoSec Challenge 0: Solution and Winners

This article provides details about the solution and winners of "DinoSec Challenge 0" (... and also explains how you can ruin a challenge trying to publish a nice blog post with images that fit on the web page ;)

Solution

The original goal of the challenge was to use the three images referenced by the "DinoSec Challenge 0", called "dinosec1.png", "dinosec2.jpg"and "dinosec3.jpg". However, due to the large size of some of these images, and in order to publish a nice looking blog post, I decided to use a reduced version of them for the challenge description, called "dinosec1_blog.png", "dinosec2_blog.jpg"and "dinosec3_blog.jpg", as you can see in the source code of the web page:


Google allows you to search for images by using terms (text) or 'Search By Image' capabilities, via URLs (pointing to image files) or by uploading local image files, both manually or using drag & drop. In the following video you can see how, depending on the web browser you are using, the Google Images search behavior varies. For example, when using Safari, the full URL of the image file pointed by the link (that is, the URL in the "<a href=…>" HTML tag, such as "http://.../dinosec1.png") is loaded into Google Images. As a result, Google cannot find any reference to any of the three images apart from the DinoSec challenge blog post (this was the expected behavior for this challenge). However, when using Chrome or Firefox, the reduced image used for the publication within the blog post (such as "dinosec1_blog.png", 320x212 pixels) is used instead. As a result, for images 1 and 3 Google is capable of finding direct references to the original images (in the case of the first one, even pointing to the original source, commons.wikimedia.org: 1, 2 & 3) and, therefore, helping to directly and easily solve the challenge:


As a result, I ended up trying to identify the reasons behind the described behavior. When creating that reduced version of the images for publication, I probably used derivatives of the original images, an obviously, none of the SHA1 hashes of the different files match. On the one hand, Google is capable of visually matching image 1 (in PNG format, 320x212 pixels) with the original source image 1 (in JPEG format, 4,288x2,848 pixels). However, image 2 is not found by Google. On the other hand, image 3 (in JPEG format, 320x212 pixels) is also matched with the original image 3 on a third-party website (same format but 4,288x2,848 pixels) and with another JPEG image of a different size (780x518 pixels) on another website. You can read some of the details regarding reverse image and photo search from multiple articles around the web, based on mathematical models, computer vision and machine learning technologies, combined with EXIF metadata and web pages context.

Although this was designed as an introductory challenge, the idea for it was not to be so easily solved, unless you were really lucky searching for dinosaur images through the web. Instead, it was designed to be solved by inspecting the raw images, finding and decoding a few artifacts added on purpose.

Images 2 and 3 ("dinosec2.jpg" and "dinosec3.jpg") are JPEG files with 4,288x2,848 pixels. If you look inside their metadata you can find a couple of messages.

The "IPTC-NAA data (IIM)" metadata section for image 2 contains a "RAW File Info" field with the following obfuscated message: "NTQ0OTUwMzEzYTIwNTc2ODZmMjA2NDY5NjQyMDYzNzI2NTYxNzQ2NTIwNzQ2ODY5NzMyMDYzNjg2
MTZjNmM2NTZlNjc2NTNmMjA0ZDcyMmUyZTJl". If it is decoded as base64 and that output is decoded again as ASCII hex, you get the first ASCII message: "TIP1: Who did create this challenge? Mr...". The image bellow shows the decoding process using Burp Decoder, but other tools or scripting languages can be used to obtain the same result:


The "IPTC-NAA data (IIM)" metadata section for image 3 contains a "RAW File Info" field with the following obfuscated message: "56456c514d6a6f67535851675a57356b63794231634342336158526f4948526f5a53423362334a6b49
434a7a5958567964584d6949446f744b513d3d". If it is decoded as ASCII hex and that output is decoded again as base64, reverting the decoding process for image 2, you get the second ASCII message: "TIP2: It ends up with the word "saurus" :-)". The image bellow shows the decoding process using Burp Decoder, but again, other tools or scripting languages can be used to obtain the same result:


Putting together the answer for both tips you can solve the challenge: Silessaurus. Yes, indeed, it is my oldest ancestor I'm aware of :)

Image 1 ("dinosec1.png") is a JPEG file with 800x531 pixels, that still contains a hidden message. Although the message is not required to solve the challenge, I'm not going to disclose how to obtain it, so that the inquisitive reader can still play around with it :) (tip: stego)

Winners

This challenge winners are Juan Manuel Fernández (@TheXC3LL), with a very fast and correct answer using search engines, and @neosysforensics, with a correct technical answer based on decoding the image files metadata. Based on the details and epic fail previously explained, and although initially I thought on having a single winner, I decided it was fair this time to select two winners, one for the first correct answer (even when using the easy path :-), and a second one for the first technical answer. The winners books are on its way, "Apply Security Visualization" and "File System Forensic Analysis", both related somehow to the techniques used to solve the challenge.

Honorable mentions go to other participants like Ricardo, José Manuel, Román, Daniel, and David, that also provided a valid answer by using Google, TinEye (reverse image search engine), or technical analysis using base64 and Python. Thanks for all your submissions!

Lessons Learned

Designing a challenge is always tough, specially finding the right balance between difficulty and affordability. Even for introductory challenges, never underestimate the minor details, manage them as more advanced and complex challenges, and always give a much higher priority to the challenge than to its publication :-) Seriously, in order to solve this first challenge speed of submission was a key factor, especially if you followed the easy path. Thus, in this case the "luck" of been aware of the existence of the challenge influenced a fast and timely response. Therefore, future challenges will be published in advance, with a well known deadline, and all submissions will be evaluated based on their quality, accuracy, creativity, and technical contents.

Besides that, prizes will be announced in advance too, so that you can evaluate your participation based on them. Quite honestly, if you participate because of the prizes and not the enjoyable learning experience, I'm sure you will find wealthier challenges and CtFs out there... although I cannot think of an easiest way of winning a security book than dragging & dropping an image into Google :-D

Follow the @dinosec Twitter account and this blog... and get ready for the next challenge!!

Monday, February 10, 2014

DinoSec Challenge 0: What is the name of this dinosaur?

At the end of last year, during the CCN-CERT conference, I challenged the audience when I reached my speaker bio slide. There, I showed "my picture" and how I "look like" nowadays as a member of DinoSec :-) The question was: "What is the name of this dinosaur?". Nobody answered it...


Throughout my professional career I've really learned a whole lot and enjoyed both participating and creating security challenges. Thus, I would like to start posting again security challenges from time to time using the DinoSec blog. As I don't like unanswered questions to last forever, this is the first introductory challenge where you need to use your investigative, exploratory, and digital paleontologist skills to be able to get the generic name of this dinosaur. To help with its identification, I have provided you three pictures, so that you can see the dinosaur physiognomy and details:




I will hand over prizes for the winner(s) of these challenges, like information security books or other gadgets. In this case, the challenge does not have a deadline. It will be open until someone answers the question and submits the right generic name for this dinosaur. Please, send your submissions to info @AT@ dinosec .dot. com, with the title "DinoSec Challenge 0", and briefly describing in a couple of paragraph how you "guessed" the dinosaur name.

Suggestion if you have kids: If I were you (as Josh Wright educated me sometime ago) I would teach them to start counting at zero! They will express gratitude for it forever :-) Now, you know why this is challenge number zero :-)