What you need to know about iOS jailbreaks

Six different types of iOS jailbreak, and how to avoid jailbroken devices becoming an entry-point for hackers into your app.

What is a jailbreak?

On iOS, Apple does not allow users to run code that is not signed by Apple. Not everyone is a fan of these restrictions, so people started looking for bugs in Apple’s software that can be exploited to circumvent them.

iOS secure boot chain

By having a secure boot chain, Apple makes sure that only allowed code is running on the device. This boot chain looks like this:

When an iOS device boots up, it will first run code that is contained in hardware and can therefore not be changed. This code is called Boot ROM. The Boot ROM verifies and runs the Low Level Bootloader, LLB. LLB then verifies and runs iBoot.

iBoot verifies and runs the iOS kernel. From that point on apps can be run. If all this software is implemented without any bugs, there should be no way of running code that Apple does not want you to run.

However, no software is bug-free. If there is a bug in any of the components of the chain that allows code execution, bypassing of its verification or which component it loads, then unsigned code can be run.

The most valuable bugs that can be found are bugs in the Boot ROM. This is because the code of the Boot ROM is located in hardware. Apple is not able to patch this bug, meaning that a device with a vulnerable Boot ROM will always be jailbreakable.

In the early days of iOS jailbreaks, Boot ROM exploits were quite popular because of this. But since Apple noticed the risk of these bugs, they have increased security a lot and there haven’t been any publicly known bugs on devices released later than the iPhone 4.

Bugs in LLB and iBoot are powerful because they not only allow running of unsigned code, but they also allow more access to things that the kernel does not have access to, e.g. decryption keys for LLB and iBoot, as well data stored in the iOS keychain.

As far as we know, there are no publicly known bugs for LLB or iBoot. But there are some people that have private exploits, which supply the jailbreak community with decryption keys for iOS firmware. As opposed to Boot ROM bugs, these vulnerabilities can be patched by Apple. And because they are very valuable, they would usually not be wasted on a jailbreak.

All recent jailbreaks rely on exploits for bugs in the iOS kernel. These bugs are pretty common but can also be patched by Apple quickly, once they are public.

Bugs in the software that runs before the iOS kernel allow running a modified kernel binary that has code signing enforcement enabled. However, bugs in the iOS kernel do not allow this. Because of that, the kernel needs to be modified while it is running and this has to be done after each boot.

Apart from running unsigned code, users have realized that it is also desirable to have the ability to get full control of the OS in order to modify every aspect of it. This requires the possibility to run code as the root user and to escape the sandbox that the kernel enforces on processes. This is achieved by applying further patches to the running kernel.

A few years ago, Apple modified the kernel to disallow mounting of the root partition read-write. This prevents jailbreaks from making any modifications to the root filesystem, which limits a lot of the functionalities that a jailbreak usually would provide. Enabling read-write access to the root partition, therefore, requires further kernel patches.

Another popular thing to do for users running jailbroken devices, is to inject code into the userland processes of iOS. This is done in order to modify the behaviour of running processes to achieve things like modifying the UI. This is usually achieved by using a hooking framework called Cydia Substrate. In order for these hooking frameworks to work, they need additional kernel patches.

Types of jailbreaks

1. Tethered

Tethered jailbreaks require the iOS device to be connected to a computer while it is booting. If it is booted without a computer connected, it will not boot up. These kinds of jailbreaks are usually based on exploits of the Boot ROM, LLB or iBoot. While these jailbreaks are hard for Apple to patch, they are quite inconvenient to its users.

2. Untethered

Untethered jailbreaks do not need the iOS device to be connected to a computer during bootup, making them very user-friendly. Usually, the device is jailbroken once by connecting it to a computer that then exploits a vulnerability to patch the kernel.

However, kernel patches will be lost during a reboot of the device. Because of that, the jailbreak needs to exploit another vulnerability to achieve persistence. In other words it needs to have a way to run code during boot that will exploit the kernel again and apply patches to it. Vulnerabilities that allow achievement of persistence have been hard to find recently, so there have not been any untethered jailbreaks in the last few years.

3. Semi-tethered

Semi-tethered and are also based on Boot ROM, LLB or iBoot exploits. But the difference is that the device can be booted without a computer. However, in that case, the device will not be jailbroken.

4. Semi-untethered

Semi-untethered jailbreaks are like untethered jailbreaks but they require the user to assist with getting the code to run. In most cases, a user just installs an app that has to launch after every reboot. The app will then jailbreak the device until it is rebooted.

The problem with this approach is that in order for these kinds of jailbreak apps to be installed and run on the device, they need to be signed. This is not a problem for people with an enterprise certificate, but it is a problem for normal users.

Apple offers free development certificates to users, but they expire fast. In the past, certificates expired after 3 months, making the effort of re-signing and installing the jailbreak app not too much of a problem. But then Apple changed the validity period to 7 days, which becomes annoying to users.

In order to work around this problem, another way to achieve initial code execution can be used. One way to do this is to exploit a bug in Safari. That way, the user just needs to go to a webpage after every reboot. The webpage exploits a bug in Safari to get initial code execution and then to trigger the kernel bug to patch the kernel.

5. KPPless

As mentioned before, jailbreaks nowadays depend on patches to the running kernel. So Apple developed technologies meant to protect against patches of the kernel’s executable code and read-only data. These technologies are called Kernel Patch Protection (KPP) and are only available on 64-bit hardware.

Pre iPhone 7 devices used a technology that Apple internally calls Watchtower, which is software that runs inside the ARM TrustZone and periodically verifies the kernel’s code and read-only data in memory. Bypasses for this kind of protection have been developed by jailbreak developers.

From iPhone 7 and on, a new hardware-based protection called KTRR has been used by Apple and is much harder to bypass. Because of that, the most recent jailbreaks try to be KPPless. This means that they manage to provide jailbreak functionality without patching the code or read-only data of the kernel, e.g. by patching writable structures in memory, like the process credentials.

However, these jailbreaks currently seem to be causing problems for hooking frameworks like Cydia Substrate, which assume to have some kernel patches in place. The developer of Cydia Substrate is currently trying to figure out if he can restore the functionality of Cydia Substrate provided a KPPless jailbreak. But until then, Cydia Substrate does not work on KPPless jailbreaks.

6. Semi-jailbreak

Semi-jailbreaks are a new class of jailbreaks and are limited in what they can do. They are usually app-based, meaning that a user has to install and run an app. This app will then get root access and escape the sandbox.

It will not patch the kernel in any way and will therefore not be able to supply the functionality a normal jailbreak would. However, since it has root access and escapes the sandbox, it is able to write to some folders (most notably the /var folder). Therefore it is able to modify some aspects of the system, most of them being user interface related.

Existing Jailbreaks for iOS >= 8

How Promon SHIELD™ detects jailbreaks

Since a jailbroken device is much more at risk of being compromised, it is important to know about it. Even if the vendor of an application chooses to allow execution on jailbroken devices, detecting whether the device is jailbroken or not is essential for further security measures in order to determine the threats that an application is exposed to.

Jailbreak detection can be performed in different ways. Standard approaches simply test for the existence of files in the file-system that are associated with a jailbroken device. Several jailbreak hider tools are available on iOS and show how easy it is to bypass these detection tools.

Promon SHIELD™ implements these standard detection mechanisms. It also performs detection on multiple levels, ranging these well-known approaches to cutting-edge low-level mechanisms that are targeted more towards detecting the essence of a jailbreak.