iOS has become a household platform for years, and only increasing in popularity with the release of new Apple products.  Despite this reputation however, Apple’s infamous ‘closed system’ has ensured few security details have been released to the public.

In this series of articles, we’ll cover the in-depth process of iOS app security and penetration testing, from DLL injection and memory tampering to attacks on the server infrastructure.  This article will begin with an introduction to iOS security and high level architecture.

iOS Implements a Secure Boot Chain during booting of iOS, outlined in the diagram below.

The Boot ROM is a Read-only Memory which contains the Apple Root CA, which verifies and decrypts the Low Level Bootloader (LLB) using the Key within the Apple Root CA.

The LLB boots the 2^nd stage bootloader, called the iBoot, after verifying whether the LLB has been signed by Apple. This boots the iOS Kernel, where again it confirms whether the code has been signed by Apple. Only after this signing verification does the main OS boot.

After this boot process has been completed, the iOS Kernel loads up the System Services along with the Core iOS Components and finally, Apple and 3^rd party apps.  At the end of the process, the kernel verifies for the last time whether all of the applications have been signed by Apple. Piece by piece, the chain of authentication is transferred from the Boot ROM up to the kernel itself.

ASLR (Address Space Layout Randomization) is a form of memory security designed to randomize memory locations, preventing successful exploits from taking control of the system.

ASLR ensures the Address Space Offset (the section of the Main Memory allocated to the program) is randomized during program load, requiring attackers to find multiple memory disclosure vulnerabilities to enable a single memory modification exploit.

If an iOS app is compiled with Position Independent Executable (PIE) support, it will be supported by the full host of native iOS ASLR features including randomization of the Offset locations for:

• Executable
• Data
• Heap
• Stack
• Libraries
• Linker

To use a real-world example, suppose a hacker creates simple ‘malware’ for the iPhone dialing/calling function, constantly monitoring the memory location which stores the current number being dialed. As soon as the user enters a valid phone number, it is substituted for another number through direct memory modification.  As a result, the user unknowingly ends up dialing an attacker-controlled phone number.

This attack is only possible if ASLR was not implemented on iOS – since the calling app has been compiled with PIE support, the memory location which stores the current phone number will be randomized every time the app is launched.

This is an important aspect of iOS Application Security since ASLR often makes it extremely difficult to directly tamper with an applications memory – a key piece of iOS app testing.

Code signing is the process of authenticating compiled code by signing the source code with the developer’s certificate, proving to users it came from the claimed source. The same concepts are integrated into the App Store, ensuring users can only install software which has been verified by Apple.

Code Signing ensures only legitimate, signed apps can run on iOS devices and therefore every allowed app has had a basic security review by Apple’s own internal team.  By checking for malicious APIs and similar app behaviors, Apple can ensure the quality of the code on the App Store – and be extension, on iOS.

Another way Apple maintains device security is running iOS applications and services with limited privileges. By removing root access for all non-system processes and preventing access to the file system, Apple can also prevent system files from being modified in any way.

Despite all the previous protections outlined, iOS devices can be hacked to install a modified OS and other software not in the iOS App Store.  This process is known as Jailbreaking. Jailbreaking is the exploitation of iOS privilege-escalation vulnerabilities to install additional software and make similarly disallowed changes.

While used by hobbyists and hackers for opening up these closed devices, jailbreaking also includes a certain amount of security risk.  A jailbroken device opens up a device to new attack vectors, including brute forcing SSH (a newly-default service) and downloading malware-laden apps.

While adding risk, jailbreaking an iOS device also enables certain security bypasses which can be useful in security auditing of mobile apps.

For example, since jailbroken devices allow unrestricted access to a device’s file-system, a hacker can bypass password protection by making changes to application files and force a crash, resulting in a runtime error and rebooting the device in safe mode.

A critical component to unlocked Apple devices, Cydia can be described as the ‘Jailbroken App Store’, allowing access to a host of software and tweaks otherwise prohibited on the hardware.  A popular addition is its sister app, Cydia Substrate, which allows for easy access to functions and operates on a layer above the primary OS.  These two apps are critical in adding and tweaking additional functionality we’ll need to modify the underlying OS and app environment.

Similar to other operating systems, iOS utilizes Dynamic Libraries sharing common code which can be used by multiple applications, improving both performance and application size in the process.   From a security perspective this is useful as well – modifying Dynamic Libraries is one of the easiest ways of modifying a behavior on iOS.

Substrate Plugins are pieces of code which modify how an app functions using these custom Dynamic Libraries – very similar to how DLL Injection works on Windows.

Cydia Substrate consists of two primary components – MobileHooker and MobileLoader.

MobileHooker is used to override System functions using the APIs MSHookMessageEx and MSHookFunction, for Objective-C and C/C++ functions respectively. However, the latter works at the assembly level, and makes the program execution jump to the replacement function.

MobileLoader loads itself into the running application using the “DYLD_INSERT_LIBRARIES” environment variable and then proceeds to open all the custom Dynamic Libraries present in the directory “/Library/MobileSubstrate/DynamicLibraries/”.

For another example of this, let’s look at the Messaging application which shows the image of the contact next to their conversations – and modifying the contact image. This modification requires the attacker to replace the associated library with one of their own – a “.dylib” file which would work within Cydia Substrate

These dylibs can contain alternate plist (Property List) files or may even override the loaded resources, which modify the behavior as desired. Moving from a harmless example, there can also be a dylib override for the In-Application Purchase controller within an app, authenticating all purchases and allowing unrestricted access to paid upgrades.

In Part 1 of the iOS App Security article, we have discussed the basic design of iOS security, code signing in the App Store, Jailbreaking, and its many uses.

In Part 2 of the series we will use function overrides to modify iOS app behavior, remove ASLR to modify memory values, and attack the app functions themselves.