White Paper The Making of the FOCUS 11 Apple iPad Hack By Gabriel Acevedo and Michael Price McAfee® Labs™ Table of Contents Motivation 3 Research 4 The iOS SSL implementation vulnerability 4 The “JailbreakMe” vulnerability 5 The Hack 5 Hardware 5 Software and tools 6 Scenario 7 Attack 8 Results 10 Conclusions 11 Acknowledgements 12 About the Authors 12 2 The Making of the FOCUS 11 Apple iPad Hack In October of last year, McAfee hosted its FOCUS 2011 conference. McAfee Labs offered customers several talks on malware and other threats as well as on myriad security topics. One of the most popular events was the Hacking Exposed keynote, which drew more than 2,000 people. Most of the attendees turned off their laptops, phones, Apple iPads, and other devices when McAfee CTO Stuart McClure announced that his team would perform live hacks at the session. We had seen a lot of buzz on Twitter and other social networks looking forward to the hack that everyone at the conference was talking about. Some skeptics claimed it would not be a live demo, but within moments of the start, people confirmed that the fake FOCUS Wi-Fi hotspot was indeed live. We aimed a TV camera at our soon-to-be-hacked demo iPad screen so that the attendees could follow along. While McClure loaded Gmail via a secure sockets layer (SSL) connection, we could see the HTTPS URI scheme and the lock icon on Safari. Under the hood, an exploit was loading and installing a secure shell (SSH) server. A few seconds later, the crowd applauded appreciatively as the iPad screen appeared on our VNC remote-control client. The iPad was compromised. We had root access through the Terminal and also graphical access through VNC that allowed us to see what McClure was doing and allowed us to interact with his device. A typical iPad user in this situation would have no clue that we had such powerful control of the system. The victim was not visiting a malicious website, but was simply checking email via a secured connection. How was this hack possible? In this report we’ll answer that question, as well as explain our research, the problems we faced, and the tools we authored. (We explain the techniques we used in this report only to provide education and awareness of the facts and security principles involved with these techniques. McAfee does not use and does not endorse using these techniques to violate applicable law or the boundaries of ethical behavior.) Motivation In July 2011, a vulnerability in a basic constraint-validation error in iOS SSL certificates validation chain was disclosed by TrustWave’s SpiderLabs.1 Their researchers found it was possible to generate a bogus certificate using another certificate that, although valid, was not meant to be used to generate certificates for other websites. SpiderLabs, however, didn’t provide many details. How complicated was it to reproduce the vulnerability? What uses could attackers make of this vulnerability other than to sniff data meant to be private? It’s been some time now since the vulnerabilities used by jailbreakme.com (collectively known as JailbreakMe, or JBME) were disclosed. So far, the only public use we have seen for them is at jailbreakme. com. Jailbreaking an Apple device is desirable for many people. However, what some people may not realize is that the JBME technique exploits vulnerabilities to gain control of the device and, as with any other vulnerabilities, these weaknesses could be used for malicious purposes. What would happen if we were to combine those two vulnerabilities? Is it possible to use them in a sophisticated, silent, and effective attack? Note that the SSL vulnerability was not necessary to perform the hack, but we wanted to prove that even when the victim thinks it is safe, it is still possible to compromise the device. So our idea was to exploit the system while the victim was visiting a bank website, checking email, or making a payment online—all through an SSL connection. Both of these vulnerabilities have been fixed in recent versions of Apple’s iOS. However, a lot of users have not upgraded for various reasons—from simple ignorance to the fact that they want to jailbreak their devices and install applications not available in the Apple App Store. How many of these users are still vulnerable? We’ve just posed a lot of questions. In the following sections we shall answer them. The Making of the FOCUS 11 Apple iPad Hack 3 Research The iOS SSL implementation vulnerability In July 2011 Paul Kehrer and Gregor Kopf disclosed an input-validation-error vulnerability (CVE-2011- 0228) in Apple iOS. The mobile operating system failed to validate the X.509 certificates chain, making it possible for an attacker to capture or modify data protected by SSL/TLS and perform “man in the middle” (MITM) attacks. The vulnerability affected iOS Versions 4.3.4 and earlier for GSM network devices, and Versions 4.2.9 and earlier for CDMA network devices. The researchers notified Apple, which released security updates HT4824 and HT4825 for CDMA devices.2,3 Later, during DEFCON 19, Kehrer revealed more details, including that iOS ignored the X.509 v3 basic constraints extension.4 Certificates issued for root and intermediate entities must include the basic constraints extension with the CA field set to TRUE.5 For example: X509v3 extensions: 1.3.6.1.4.1.311.20.2: ...C.A X509v3 Key Usage: Digital Signature, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE However, for user certificates the CA parameter should be set to FALSE. For example: X509v3 extensions: X509v3 Basic Constraints: CA:FALSE The flaw in these versions of iOS allows an attacker to use a legitimate non-CA certificate (CA:FALSE) to sign subsequent certificates for any domain and make the devices accept them without any warning, just like a regular X.509 certificate signed by a valid entity. For example, the following certificate chain will work on iOS Version 4.3.4, but not in patched versions (such as Version 4.3.5): Root Certificate Intermediate Certificate (CA:TRUE) End User Certificate (CA:FALSE) Some Arbitrary Domain Certificate—Trusted The basic constraints extension also has an optional parameter: pathlen. This parameter indicates the maximum number of certificates that can appear below this one in the chain. So, considering the example above, if the Intermediate Certificate has the pathlen parameter set to zero, the iOS device will not trust the Some Arbitrary Domain Certificate generated by the End User Certificate. The following certificate chain will not work even on iOS 4.3.4. Root Certificate Intermediate Certificate (CA:TRUE,pathlen:0) End User Certificate (CA:FALSE) Some Arbitrary Domain Certificate—Not trusted 4 The Making of the FOCUS 11 Apple iPad Hack We came to this conclusion while trying to reproduce this vulnerability. The original advisory said that iOS fails to recognize all the basic constraints, but we concluded that the vulnerable versions would ignore only the CA value. Therefore, to generate a bogus X.509 certificate to exploit the CVE-2011-0228 vulnerability, the certificate in the chain immediately preceding the certificate that generates the bogus certificate should not include the pathlen parameter—or it should contain a large enough pathlen value. The “JailbreakMe” vulnerability JBME is a website that contains a collection of jailbreaks for different versions of iOS. The breaks were designed by comex and take advantage of flaws in Safari and the kernel. The first version was released in 2007 and worked for iPhone and Apple iPod Touch firmware 1.1.1. A second version was released in August 2010 for iOS 4.0.1, and the latest version was released in July 2011. It works for iOS 4.3.3. Apple fixed the vulnerabilities used by JBME in iOS Version 4.3.4. The July 2011 version of JBME—also known as Saffron—exploits a vulnerability (CVE-2011-0226) in Mobile Safari’s FreeType parser component, using a specially crafted PDF file. The routine in the PDF will construct and load a return-oriented programming payload into the stack and exploit a kernel vulnerability in the IOMobileFrameBuffer IOKit interface (CVE-2011-0227). The routine will then use another payload to modify some kernel functions to disable the code-signing enforcement and gain root privileges. Once the exploitation is complete, an attacker could install unsigned applications such as Cydia and all the apps provided through that system.6 Thousands of people use JBME to jailbreak their devices, to access applications not available on the Apple App Store or to modify settings restricted to regular users. But what people sometimes don’t realize is that their devices are being exploited to allow the jailbreak to succeed. The Hack Hardware We didn’t need much: we used an Apple MacBook Air laptop and a wireless dongle. We used the dongle to roam and find different points from which to launch our demo attack. The MacBook Air is very handy for conferences, cafés, or airport lounges. A Mac is required to rebuild the malicious PDF. For the rest, it shouldn’t matter what laptop or desktop computer you use, but the operating system should be a Unix-like system such as Mac OS X, Linux, or FreeBSD. These make it easier to forward traffic using a kernel firewall like ipfw or iptables. You will also need some tools that come installed by default on such operating systems. The Making of the FOCUS 11 Apple iPad Hack 5 Software and tools We used a couple of handy applications to perform the hack.