With tens of thousands camped in line today waiting for the Apple iPhone 5, hackers have already had their hands on the core iOS 6 operating system for some time. Two Dutch hackers managed to successfully beat Apple’s sturdy protections in place, and this week at the EUSecWest conference in Amsterdam presented the first successful hack of a patched iPhone 4S with an exploit that will also work against the new device.
Joost Pol and Daan Keuper grabbed plenty of attention—and $30,000—for their efforts in winning the mobile Pwn2Own contest. The two researchers from Certified Secure, a Dutch security company, used a vulnerability in WebKit, the Web browser engine underneath Apple’s Safari browser. After three weeks’ worth of work, the duo had a working exploit that enabled them to steal data from the phone. Threatpost talked with Pol and Keuper about how they managed to crack the iPhone.
Threatpost: What motivated you to go after iPhone 4S (and iOS 6)?
Pol and Keuper: We believe that the iPhone has the best security features (ASLR, DEP, sandboxing, code-signing, etc.) and was thus the most interesting target for us. The release of IOS6 made it extra interesting since a newer WebKit version would be used, eliminating some older vulnerabilities/exploit-paths.
Threatpost: Describe the severity of the WebKit vulnerability you discovered and how you found it.
Pol and Keuper: We found the vulnerability by auditing the WebKit code. The vulnerability is quite severe as it allows (with some trickery) for arbitrary code execution (within the Safari sandbox) as demonstrated at the Pwn2Own. This gives us (for example) direct access to the user’s personal photos, address-book and browsing history.
Threatpost: How would you describe the security of WebKit?
Pol and Keuper: Suboptimal. At this point, it’s a bit difficult to go into details about our
vulnerability and generic WebKit security (with all the competition rules and everything). But i think the point that we were able to find and exploit a vulnerability within three weeks makes the ‘suboptimal’ point quite strong.
Threatpost: Once you had the vulnerability, you had to chain a few things together to get a working exploit. Can you describe what that was, and why you had to do it that way?
Pol and Keuper: It’s rare for a vulnerability to lead ‘directly’ to code-execution. In most exploits you will have to do some “extra work” to get code execution. In our case, we also had to work around the code signing feature of iOS (which does not allow any code to be run, unless it’s signed by Apple).
Threatpost: How did you get around Apple’s code-signing? Was this difficult?
Pol and Keuper: Normally iOS only allows pages to either by marked executable or writable, but never both. Pages also need to be signed before they will be loaded into memory. This is a very strict rule and works very well. With the introduction of iOS 4.3 Apple changed this policy however.
Since iOS 4.3 Apple decided that in order to improve the performance of the Mobile Safari browser they needed a Just In Time (JIT) compiler. Mobile Safari is now able to map a RWX page. This exception is only made for Mobile Safari (which has a special entitlement). In our exploit, we find the location of this JIT page and overwrite it with our own shellcode, to which we then jump.
If there was no JIT page, we could have used ROP [return-oriented programming] to get the exact same result (code execution), but building a ROP payload is much more cumbersome.
These are both known techniques and have been used before.
Threatpost: How does the exploit work once someone is lured to use the phone to surf to a malicious site?
Pol and Keuper: The exploit will run in the background and will silently copy the private data of the user (including address book, camera photos and browser history) from the phone to a server that is controlled by the attacker.
Threatpost: Why were you not able to get at the email and SMS messages on the iPhone?
Pol and Keuper: The Safari sandbox (in which our code is running) does not allow access to the SMS and email database.
Threatpost: Is the vulnerability exactly the same in iOS 6, and does the exploit work the same way in iOS 6?
Pol and Keuper: The vulnerability is the same in iOS 6. The generic idea of the exploit is the same, but some different intermediate steps are required on iOS 6.
Threatpost: Is it true you destroyed the exploit? If so, why?
Pol and Keuper: Yes. We have no need for it anymore. As part of the competition we only need to send a vulnerability description and some simple POC (proof of concept) code to the ZDI [TippingPoint’s Zero Day Initiative program].
Threatpost: Have you shared the details with Apple? What was that interaction like?
Pol and Keuper: As part of the competition rules, the vulnerability will be disclosed to Apple by ZDI.
