Black Hat Independent security consultant Stefan Esser made waves earlier this year when a technique he developed for hacking iPhones was adopted by JailbreakMe and other mainstream jailbreaking services.
The Register caught up with the German researcher at the Black Hat security conference in Las Vegas just ahead of his scheduled talk titled Exploiting the iOS Kernel. Here are the highlights of the discussion, including details about an undocumented debugger that can only be accessed using a custom-built connector:
El Reg: In a nutshell, what’s your presentation about?
Esser: the idea is once you execute remote code you have the big problem that you still can’t do anything on the iPhone because of all of the protections. In order to disable these protections you have to get into the kernel and disable them. if you cannot do that, you cannot put up a rootkit. so you need kernel exploits for rootkits.
I’m explaining how to actually exploit the kernel and how to make use of different parts. I show what you go after in the kernel, where you disable these security features. Most of the people don’t know how to do kernel exploitations. This is a short course on how to do it.
You said earlier that one of the ways you go about exploiting the iOS kernel is making use of secret functionality. What is it?
It’s a kernel debugger. Its actually not used. Developers should not have access to it. Apple even gives no normal way for an iOS developer to access that. they have it in the Mac OS, so they just left it inside the iOS kernel. it helps an attacker to make the exploit more stable, to make it easier to write the exploit.
It’s an Apple-endorsed kernel debugger that people use to develop kernel drivers on Mac OS. on iOS, they’re not supposed to do that, but Apple just left it inside, maybe thinking that no one can use it because normally the kind of interfaces you need, like Ethernet and serial, are not exposed from the iPhone. By default there’s no way to speak with it on the iPhone.
So how do you access it, then?
When you look at the connecter of the iPhone, there are two pins that are like serial. There’s no public cable or something like that that will expose them, but you can build your own cable and then speak serial with the iPhone.
Does that mean an attacker has to have physical access to the iPhone he wants to exploit?
No. That’s only for development of the exploit. it makes development of the exploit easier. it makes it far easier to do the exploit.
What kind of information does the debugger give you that you otherwise wouldn’t have?
A debugger gives you complete control over the CPU at the moment of the crash, so you can do anything. you can read memory, write memory, read the registers, change the values of the registers. the development time will be far shorter, and it’s not fishing in the dark anymore. It’s like you have full light.
In a nutshell, how do you go about exploiting an iOS device?
When you have a kernel debugger, you start with having a bug in the kernel. Once you have a bug, the first thing you’d do is write some trigger code that will cause the crash, and either you analyze the crash dump or you take a kernel debugger and try to get the program to jump to your own code to execute.
I also show how, when you have a heap overflow, you manage to control the layout of the heap so that you can write an exploit that leverages the heap overflow. so that when you trigger the buffer overflow you can control what you’re actually overwriting and how to gain code execution from that.
How is it different doing that in iOS than in Unix, Linux, Windows, or OS X?
There are a lot of similarities, especially between iOS and Mac OS. during the talk I will highlight some of the differences that in some cases make it easier to exploit and in other cases make it harder to exploit in iOS. A lot of the techniques are known but were never applied to iOS before. It’s more proof that it’s possible and how real-world examples work.
How would you describe exploitation of the iOS kernel relative to other ones? is it harder?
The big difference is that iOS has code-signing, so you cannot just put some shell code in there or use the Windows way to have a short ROP [return-oriented programming] payload that makes some memory readable, writeable, and executable, and then just jump there. That’s not possible in iOS. In iOS, you have to do the whole kernel exploit in return-oriented programming, which makes it a lot harder to create an actual exploit.
So the security features of the iPhone make kernel exploitation a lot harder, but once you’re in the kernel, there are no mitigations inside the kernel to protect the kernel itself from being exploited. the kernel is just there to guard the userland, but the kernel itself has no mitigations inside.
If you were advising Apple, would you say, “Remove the debugger from iOS”?
There is actually no reason to keep it in there. I would advise them from a security point of view to remove it. And there are other features that are not really used and make exploit development easier. these are things Apple can remove that would make exploitation harder.
Like what?
There’s a function in iOS and Mac OS also that gives you some information about the state of the heap. With this information, the whole controlling-the-heap thing is easier. It’s still possible to do it without it, but the exploit can be made more robust, more stable, with having this feature.
What kind of communications have you had with Apple? have you been speaking with anyone in their security department about your work?
Not really. the only thing I spoke with them [about] was they asked me to apply for a job.
When did that happen? Are you interested?
Right after I released the first of the exploits for jailbreaking the iPhone, in April or so. At the moment I’m just evaluating other options. ®