Count the protections on iOS

0x00 Foreword
There have been an increasing number of protections with increasing complexity on iOS as Apple carries on its years of R&D in the iOS system. This looks unfriendly to developers new to iOS security, making them not sure where to begin. Therefore, to help everybody understand the security mechanisms on iOS in a more systematic way, we make a summary of iOS security mechanisms, focusing on three aspects: CodeSign, SandBox and Exploit Mitigation. We hope this article can be of some help for your learning and research. Note: The content below is based on the latest iOS 9.3.4.
 
0x01 CodeSign
The iOS system implements a very strict signature protection mechanism to protect the copyright of developers and prevent pirated applications. To develop an iOS app, you must first register a developer account and apply for a relevant certificate from Apple. Otherwise, your app can only run on the simulator, neither debuggable on a real device nor launchable in App Store. Apart from the traditional signature mechanism, Apple also activates the Team ID protection measure to enhance the security of the iOS system.
 
(1). Traditional signature mechanism - digital certificate
The signature mechanism refers to the digital certificate mechanism in the iOS system. The digital certificate is a method for validating digital content. It first applies the digest algorithm on the content (for example MD5 or SHA1) to generate a hash value of a fixed length (you can understand it as an abstract of the original content). Then this abstract is encrypted using the private key to get the digital signature of the original content. The receiver receives the original content and the digital signature together. It first generates the abstract of the original content with the same digest algorithm, and then decrypts the digital signature using the public key to get Abstract 2. The receiver then compares Abstract 1 and Abstract 2. If they are identical, the original content is validated as valid. The digital certificate we obtain from the Apple MC (Member Center) is the legal certificate signed by Apple CA. Before an iOS device runs an app, it first needs to verify the validity of the CA signature, then it verifies whether the app is truly published by the developer through the public key in the certificate, without any manipulation of the app during the process. In theory, to crack or bypass this signature mechanism, you need to obtain the Apple private key, or find a loophole in the signature validation process.
 
(2). Implementation of signature validation
iOS will always validate the signature of the to-be-run code first. The signature validation mechanism is run in the kernel. You'd have to jailbreak your system to disable this validation. The kernel stipulates in vm_fault_enter that signature validation is required in a vast majority of situations for pages with execute bits. If the page signature is invalid, the process will be set with a kill flag. The signature validation involves two situations: if the binary is the platform binary, the system will directly validate whether the binary hash value exists in the trustcache. If the binary is a third-party app, it will first check the corresponding hash value of the execute page in the kernel, and the correctness of the signature of the page hash value is validated by the user-state process amfid.
 
(3). Team ID
Team ID was first proposed in iOS 8 and further enhanced in iOS 9. The emergence of Team ID mainly aims to prevent attackers from loading their own dynamic libraries into the executable of others. Common examples include: during the jailbreaking process, they load dynamic libraries into the system processes to get the ability to execute any code out of the sandbox; malicious apps load their dynamic libraries into the app running environment of others through sandbox escapes to steal accounts, passwords and other valuable information. So the specific validation logic of Team ID is designed based on this principle. Except some special cases, the system process can only load dynamic libraries of the system. According to their own Team IDs, third-party apps decide the dylib to be loaded with the same Team ID.
 
0x02 SandBox
Many systems have the sandbox mechanism, but few of them have as complicated a sandbox mechanism as iOS does. iOS implements the sandbox mechanism for the entire system in the UID/GID permission, MAC and entitlement dimensions:
 
(1) UID/GID permission
In general, iOS will divide the process permissions into root and mobile permissions. Some special modules (such as base band) will have their own user groups. It is worth noting that all third-party apps are run with mobile permission.
 
(2) iOS Mandatory Access Control  
The MAC mechanism of iOS is implemented on the basis of TrustedBSD Mac Framework. Permission hook checks (mac_** call) are inserted at the kernel’s specific interfaces and locations. When a call is triggered, the system first checks whether the current process meets the MAC policy of the call.
The MAC policy of the process is mainly implemented through the sandbox profile. Sandbox profile is preset by Apple for every system process or app, for example, which files are readable or writable, and which system calls are available.
In general, Apple will allocate different sandbox profiles for different system processes, which not only meets business demands, but also observes the minimal permission principle.
Third-party apps are uniformly granted with the Container sandbox profile which contains thousands of restrictions for content. The limitation is so strict that only a few syscalls can be accessed in a third-party app. Some very common calls in Android system, such as fork, exec system calls for creating sub-processes are invalid in third-party apps. The sandbox escape we often mention aims to jump out of the Container sandbox profile.
 
(3) Entitlement
Entitlement emerges to solve the permission check issue which fails to be addressed by the two dimensions above.
Imagine such a scenario:
Process A is a service, and Process B is a client. The two communicate through IPC.
Process A provides service interfaces of a1 and a2, and only wants a1 to be accessed by B.
Because the check happens in the user state, the TrustedBSD Mac Framework cannot be used directly and a simpler query method is required at the same time. So we need to add the permission check in the a2 interface code. The entitlement-based verification framework was proposed in this very backdrop. The business process only needs to pay attention to the entitlement content, and the entitlement correctness is ensured by the signature. For example, if you want to access the “com.apple.mobile.installd” service that provides an interface for deleting apps, you must own the corresponding “com.apple.private.mobileinstall.allowedSPI” entitlement. While the lockdownd service is used to interact with iTunes to install, upgrade and remove apps, so this service needs to own the “com.apple.private.mobileinstall.allowedSPI” entitlement to be capable of communicating with installd services and perform the app removal operations:
 
0x03 Exploit mitigation
Apart from common stack canaries, ASLR and DEP, iOS also owns many advanced or unique exploit mitigation technologies:
 
(1) Stack canaries
A stack canary is a known random value placed between the buffer and control data. When the buffer overflow occurs, the canary value is usually damaged first. So when the canary data verification fails, it means buffer overflow happens, and the protection mechanism can be triggered to terminal the app.
 
(2) ASLR/KASLR (Address Space Layout Randomization/Kernel Address Space Layout Randomization)
When a user-state process starts, the base address of the executable file is generated at random to increase the difficulty for the attackers to predict the destination address and prevent them from launching attacks to the code directly. What’s more, after each restart of the mobile phone, the kernel mach-o base address is also random.
 
(3) DEP (Data Execution Prevention)
DEP aims to prevent executing code on data pages. In general, the system does not execute code from heaps and stacks by default. DEP will check the code running from these locations, and throw exceptions upon execution. In mprotect-corresponding kernel implementations, the system does not allow the page to be granted with both the execute and write permissions at the same time. When the page permission changes, or a new page is mapped to the memory through mmap, vm_fault_enter will check whether there are execute bits on this page. If yes, it will validate the signature of this page.
 
(4).Heap Free Element Protection
In iOS, if the free element released in a zone is modified, when the memory manager allocates memory to this free element again, a random panic will occur. The specific logic is: after the element is released, the kernel will generate some content to fill the element according to the created token at the restart. In this approach, on the one hand, the user state won’t be able to perceive what the filled content is, and on the other hand, when the kernel allocates the memory, it can know whether this element has been modified or not according to the token. If the element has been modified, a panic is triggered.
 
(5).Random Heap Element Address
When the iOS system is releasing memory blocks, it will randomize the sequence of released blocks in the free queue. This security measure mainly aims to prevent attackers from predicting the layout of corresponding elements in the kernel according to the call sequence of the heap spray interface.
 
(6).Kernel Patch Protection
ARMv8-A architecture defines four exceptional layers, namely from EL0 to EL3. In them, a bigger number indicates a higher privilege:
EL0: Unprivileged mode
EL1: OS kernel mode
EL2: Hypervisor mode
EL3: TrustZone monitor mode
 
KPP is run in EL3 of the Application Process. It aims to guarantee that: read-only pages cannot be modified, page tables cannot be modified and execute pages cannot be modified.
 
0x04 Summary
Although iOS is equipped with a number of security and mitigation measures, it does not mean the iOS system is unbreakable. Sometimes a tiny error may lead to a butterfly effect, and eventually cause the security system to crash. Through our research in the latest iOS 9.3.4, our team still finds some security issues in the iOS system which may even render the system as being controlled by a malicious party. The following video shows how to obtain the highest permission on the latest iOS 9.3.4 and install cydia:
 

Nice