Monday, October 13, 2014

Attacking Wi-Fi Clients: Introduction

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



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

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

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

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

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

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

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


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

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

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

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

or
$ sudo tshark -i mon0 ...


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

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

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

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

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

Wednesday, September 24, 2014

Bypassing iOS Lock Screens: A Comprehensive Arsenal of Vulns

UPDATED: Up to iOS 8.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!!