Exploit writer spills beans on secret iPhone function

iOS debugger of no use to anyone ... except hackers


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. ®


Other stories you might like

  • Apple gets lawsuit over Meltdown and Spectre dismissed
    Judge finds security is not a central feature of iDevices

    A California District Court judge has dismissed a proposed class action complaint against Apple for allegedly selling iPhones and iPads containing Arm-based chips with known flaws.

    The lawsuit was initially filed on January 8, 2018, six days after The Register revealed the Intel CPU architecture vulnerabilities that would later come to be known as Meltdown and Spectre and would affect Arm and AMD chips, among others, to varying degrees.

    Amended in June, 2018 the complaint [PDF] charges that the Arm-based Apple processors in Cupertino's devices at the time suffered from a design defect that exposed sensitive data and that customers "paid more for their iDevices than they were worth because Apple knowingly omitted the defect."

    Continue reading
  • Workers win vote to form first-ever US Apple Store union
    Results set to be ratified by labor board by end of the week

    Workers at an Apple Store in Towson, Maryland have voted to form a union, making them the first of the iGiant's retail staff to do so in the United States.

    Out of 110 eligible voters, 65 employees voted in support of unionization versus 33 who voted against it. The organizing committee, known as the Coalition of Organized Retail Employees (CORE), has now filed to certify the results with America's National Labor Relations Board. Members joining this first-ever US Apple Store union will be represented by the International Association of Machinists and Aerospace Workers (IAM).

    "I applaud the courage displayed by CORE members at the Apple store in Towson for achieving this historic victory," IAM's international president Robert Martinez Jr said in a statement on Saturday. "They made a huge sacrifice for thousands of Apple employees across the nation who had all eyes on this election."

    Continue reading
  • Microsoft fixes under-attack Windows zero-day Follina
    Plus: Intel, AMD react to Hertzbleed data-leaking holes in CPUs

    Patch Tuesday Microsoft claims to have finally fixed the Follina zero-day flaw in Windows as part of its June Patch Tuesday batch, which included security updates to address 55 vulnerabilities.

    Follina, eventually acknowledged by Redmond in a security advisory last month, is the most significant of the bunch as it has already been exploited in the wild.

    Criminals and snoops can abuse the remote code execution (RCE) bug, tracked as CVE-2022-30190, by crafting a file, such as a Word document, so that when opened it calls out to the Microsoft Windows Support Diagnostic Tool, which is then exploited to run malicious code, such spyware and ransomware. Disabling macros in, say, Word won't stop this from happening.

    Continue reading

Biting the hand that feeds IT © 1998–2022