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. Some were simple scripts, others were sophisticated software such Apache HTTP Server, tools included by default with the operating system, and a few custom applications. To generate the PDF we needed comex’s star_. It contains all the files to generate the malicious PDF, which requires posixninja’s xpwn tool.7 In that project, you will also find the kernel’s exploit. You will need a custom decrypted iPad’s firmware, or generate your own using xpwn (decryption keys are not always included).8 Using comex’s tools and instructions, we generated the following files:
• PDF: takes initial control of the system • freeze.tar.xz: package contains the files and apps (such as VNC) to be installed • install-3.dylib: dynamic library used during the exploitation • saffron-jailbreak.deb: package contains a series of binaries to bootstrap the installation process
To serve the exploit and apps to the iPad, we used the Apache HTTP Server, known as the Web Sharing component, included in Mac OS X. The web server had to serve content using SSL, so it was necessary to create an SSL certificate for it. We did that using the OpenSSL tool included by default in OS X. We used tcpdump (included by default in OS X) to verify that the exploit was requested successfully by the iPad. We configured the freeze.tar.xz payload to drop a file in /var/mobile/Media/post-jailbreak, which is executed by the star exploit (if it is present). In that file we included a ping command to our system to let us know when SSH was up. We used tcpdump to verify if the iPad was pinging our laptop. We needed BSD’s ipfw tool to set some firewall rules on the laptop to redirect the iPad traffic to our MITM tool, iSniff.
iSniff was written by hubert3 and was inspired by Moxie’s sslsniff tool.9 Hubert3’s tool sniffs the SSL traffic by sending fake certificates generated on the fly to the victim. We edited iSniff’s source code to be able to modify the data the victim was sending to the server and vice versa. (iSniff was designed to run on Debian GNU/Linux, so we modified it to work on OS X.)
6 The Making of the FOCUS 11 Apple iPad Hack Scenario We used the USB wireless interface on our MacBook to connect to the FOCUS Wi-Fi hotspot and the built-in Airport wireless interface to create a hotspot with an SSID name similar to the legitimate network’s name. By coming close to the real thing, our hotspot name might make the victim connect to our network. A simple trick is to take a regular SSID name and make another with a space in front of the name. That makes the imitation hotspot name go on the top of the networks list.
Attackers will normally leave the hotspot open (requiring no password). In this case, however, we added a password so that attendees of our session were not involuntarily hacked.
The Making of the FOCUS 11 Apple iPad Hack 7 Attack We connected the laptop to the Internet using the wireless dongle, started the web server, and shared the Internet connection through Airport to make the victims believe that we were a free Wi-Fi hotspot. We opened a couple of tabs in the Mac’s Terminal app. In the first one, we started tcpdump and had it listen on the shared network interface. On the second Terminal tab, we create a couple of firewall rules using ipfw. One rule was particularly helpful:
sudo ipfw add 1013 fwd 127.0.0.1,2000 tcp from any to any 443 recv en1
In this rule, 1013 is the rule number, 127.0.0.1,2000 indicates where the MITM proxy is listening, 443 indicates that we want to intercept connections through the standard port for SSL, and en1 is the network interface through which we are sharing the Internet connection. Next we started the MITM proxy server (iSniff). It’s configured to listen on port 2000. We watched our victim visit https://mail.google.com on the iPad.
The proxy intercepts the victim’s connection, generates a certificate for the domain name the victim is trying to reach (mail.google.com), sends the certificate to the victim to establish a “secure” connection with the device, and finally impersonates the victim to establish a connection to the final destination.
Because the vulnerable iOS version cannot verify the SSL certificate chain, it trusted the certificate we generated and did not raise any alarms nor return any errors. In this scenario, we saw all the traffic going in and out and we could also modify it.
8 The Making of the FOCUS 11 Apple iPad Hack The MITM tool modified the victim’s HTTP request and asked the server for a noncompressed page, making it easier for us to process and modify the returned web page to insert an iframe HTML element just before the HTML’s