Elusive Thoughts: 03/03/2013

Introduction

Hello everybody, it has been a while since I made a post, but this time is going to be a really long long post (that is why I am going to brake it in many parts). Lately my interest has significantly increased as far as the iOS platform is concerned. The iOS is becoming more and more popular among the financial business sector companies so it came for me the time to expand my knowledge on IPhone devices. Plus since the complete industrialization of hacking (mostly because of the Chinese government, unit something is doing a good job) nowadays knowledge in iOS platforms is critical (they pay good money for iHacking). This post is going to include only hardening information and explain what the security measures are to block exploits and prevent buffer overflows etc. The second post is going to include network attacks and the third post is going to include attacks in the data of an iDevice.

Note: iOS the most advanced OS for mobile devices ever created (just kidding, I love Apple).

This blog post is going to focus on how to perform a complete penetration test on an iOS application, no time is going to be wasted on how to pentest the server component since the threat land scape is almost identical to that of a Web Application or a Web Service, and since you read my blog (if you don't start doing it) you should know by now that I covered most types of attacks for Web Applications and Web Services so far.

The iOS history

Since the release of the original iPhone in 2007, Apple has engaged in a cat-and-mouse game with hackers to secure their suite of devices for what has grown to nearly 100 million end users. Over this time, many improvements have been made to the security of the iOS, and the stakes have been raised by their introduction into circles with far greater security requirements.

What iOS is

iOS is Apple's mobile operating system, which is derived from Mac OS X, with which it shares the Darwin foundation, and is therefore a Unix-like operating system. Being developed originally for the iPhone, it then has been used on the iPod Touch, iPad and Apple TV as well. So in this article the iOS term specifically refers to the mini-operation system that run on all the iDevices (iPhone, iPod, iPad and Apple TV. In this little apple operation system, there are four abstraction layers: the Core OS layer, the Core Services layer, the Media layer, and the Cocoa Touch layer, which in total will roughly use 500 megabytes of the devices storage.

Note: The Core OS layer is written in C, while the higher layers that runs all interesting applications is written in Objective-C. The higher layer is the most interesting as far as the attacks are concerned.

For security and commercial reasons and considerations, Apple does not permit the OS to run on third- party hardware and also has a limitation on the usage of iOS on these iDevices. Therefore iOS has been subject to a variety of different hacking methods focusing on attaching functionality not supported by Apple. This hacking procedure is called iOS Jailbreak.

The iOS security architecture

While Apple was designing iOS operating system decided to increase the security by using various "tricks", (obviously iOS is based on the same core technologies as OS X) to reduce the attack surface. The attack surface is the code that processes attacker supplied input (e.g. SMS messages, Safari Web Pages etc.). One of the many ways it did that was by not including various software packages in iOS (e.g. Java and Flash are unavailable). This automatically translates to iOS not processing Java and Flash input (Java and Flash have a history of security vulnerabilities). Another trick that Apple did to reduce the attack surface was to striped off part the functionality provided by the default software that comes installed with the iOS (e.g. Mobile Safari does not support some Adobe features). Also the iOS OS was also stripped off from many applications compared to OS X e.g. the /bin/sh software is not included in iOS, which translates that if you write an exploit for iOS you would have to implant your own shell to your exploit, which means that your exploit would have to increase its size etc.

More on iOS security

Some of the core security features referenced per layer are:

System architecture: The secure platform and hardware foundations of iPhone, iPad, and iPod touch.
Encryption and Data Protection: The architecture and design that protects the user’s data when the device is lost or stolen, or when an unauthorized person attempts to use or modify it.
Network security: Industry-standard networking protocols that provide secure authentication and encryption of data in transmission.
Device access: Methods that prevent unauthorized use of the device and enable it to be remotely wiped if lost or stolen.

Layered security mechanisms allow for the validation of activities across all layers of the device. From initial boot-up to iOS software installation and through to third-party apps, each step is analyzed and vetted to ensure that each activity is trusted and uses resources properly.

The following picture shows the security model of iOS, as described from above:

Note: Check out that the Apple root certificate installed in the iDevice ROM. Also that iDevices contain their own hardware crypto engines (impressive ee?). Once the system is running, this integrated security architecture depends on the integrity and trustworthiness of XNU (the iOS kernel). XNU enforces security features at run-time and is essential to being able to trust higher-level functions and apps.

More More on iOS security

Apple takes security very seriously and this is obvious from the security controls that are enforced during the execution of third party applications and iOS default pre-installed applications. The security controls explained here is required knowledge to understand how to pentest an iDevice and to later on set the threat landscape. The iOS OS basically enforces Mandatory Access Control (MAC) using the security controls explained below.

The security controls enforced are listed below:

Least Privilege Principle: System files and resources are also shielded from the user’s apps. The majority of iOS runs as the non-privileged user "mobile", as do all third-party apps. The entire OS partition is mounted read-only. Unnecessary tools, such as remote login services, aren’t included in the system software, and APIs do not allow apps to escalate their own privileges to modify other apps or iOS itself.

Access by third-party apps to user information and features such as iCloud is controlled using declared entitlements. Entitlements are key/value pairs that are signed in to an app and allow authentication beyond run-time factors like unix user ID. Since entitlements are digitally signed, they cannot be changed. Entitlements are used extensively by system apps and daemons to perform specific privileged operations that would otherwise require the process to run as root. This greatly reduces the potential for privilege escalation by a compromised system application or daemon.

Code Signing: To ensure that all apps come from a known and approved source and have not been tampered with, iOS requires that all executable code be signed using an Apple-issued certificate. Now given that individual developers need to test out their applications on iDevices and enterprises need to distribute apps just to their devices, there is a need to run apps without being signed by Apple. The method to allow this is called provisioning. An individual developer, a company, an enterprise or a university may sign up for one or more of the programs offered by Apple for this reason, in order to enable signing their code.

As part of the program, each developer generates a certificate request for a development and a distribution certificate from a set of private keys generated locally (e.g. by using openssl or a local certificate authority etc.). Apple then replies back with these two certificates. For more information see iOS developer program link.

Through the iOS developer portal then you can generate a provisioning profile. A provisioning profile is nothing more than a .plist file signed by Apple. The .plist file all is doing is list certificates, devices and entitlements (entitlement are configuration files describing what an app is allowed and not allowed to do). When this provisioning profile is installed (e,g, through the IPhone Configuration Utility or a third party Mobile Device Management software).

The developer provisioning profile can be used only for 100 devices (the devices listed have to be specific), while the enterprise provisioning does not have that limitation. Essentially provisioning adds accountability to all the apps that are allowed to be installed to an iDevice.

The following screenshot shows the IPhone Configuration Utility:

Note: This is obviously is not a signed profile, configured locally from my IPhone Configuration Utility.

The following picture show an enterprise configuration installed and how it shows through the iPhone configuration:

Note: See how the certificate show in the screenshot. This demonstrates the BOMGAR MDM software, that enforces a custom configuration profile.

Sand-boxing: All third-party apps are "sandboxed", so they are restricted from accessing files stored by other apps or from making changes to the device. This prevents apps from gathering or modifying information stored by other apps. Each app has a unique home directory for its files, which is randomly assigned when the app is installed. If a third-party app needs to access information other than its own, it does so only by using application programming interfaces (APIs) and services provided by iOS. The downside of this security model is that same rules apply for all apps (a third party app is not allowed to have more restrictive rules than another).

Address space layout randomization (ASLR): ASLR protects against the exploitation of memory corruption bugs. Built-in apps use ASLR to ensure that all memory regions are randomized upon launch. Additionally, system shared library locations are randomized at each device start-up. Xcode, the iOS development environment, automatically compiles third-party programs with ASLR support turned on.

NX Flag: Further protection is provided by iOS using ARM’s Execute Never (XN) feature, which marks memory pages as non-executable. Memory pages marked as both writable and executable can be used only by apps under tightly controlled conditions: The kernel checks for the presence of the Apple-only “dynamic-codesigning” entitlement. Even then, only a single mmap call can be made to request an executable and writable page, which is given a randomized address. Safari uses this functionality for its JavaScript JIT compiler.

Jailbreaking your iOS

Jailbreaking is a process that allows these iDevices users to gain the infamous root access to the command line of the iOS operating system, in order to remove usage and access limitations imposed by Apple. Once jailbroken, iPhone users are able to download extensions and themes that are unavailable through the App Store (via installers such as Cydia) and perform other tasks that are not possible on store-bought devices, including installing non-Apple operating systems such as Linux, running multi-task on old version of iDevices (the new Generation of store-bought devices includes this function). Through the authentication server developed by Aurik (a Ph.d student from UCSB) built up to sign old firmware of iOS, Cydia creator Jay Freeman estimates that over 10% of all iPhones are jailbroken.

Tools you can use for jailbreaking your iPhone are listed alphabetically below (found in theiphonewiki.com):

A
    •    Absinthe
B
    •    Blackra1n
C
    •    Corona
D
    •    Dual Boot Exploit
E
    •    Evasi0n
G
    •    Greenpois0n (jailbreak)
I
    •    IBrickr
    •    ILiberty+
    •    INdependence
J
    •    JailbreakMe
L
    •    Limera1n
M
    •    Mknod
P
    •    Pwnage
    •    PwnageTool
R
    •    Ramdisk Hack
    •    Redsn0w
    •    Redsn0w Lite
    •    Restore Mode
S
    •    Seas0nPass
    •    Sn0wbreeze
    •    Soft Upgrade
    •    Spirit
    •    Star
    •    Symlinks
Z
    •    ZiPhone

Note1: This tutorial was written on 09/March/2013 so an update by performing a research is also required.

Note2: The real question here is do you need to jailbreak your iDevice to pentest it? The answer is it depends, for example if the app you are testing has anti-jailbreaking countermeasures then maybe no, if the app you are testing has no anti-jailbreaking countermeasures then definitely yes. Jailbreak the the testing target iPhone is must when applicable.

Settings the threat landscape for iOS

What most iOS developers/security consultants do not understand is the threat landscape that is currently associated with the iOS platforms is not clearly defined in their minds, some of them do not even have a clue what is that it should be taken into consideration when performing a Security Assurance, Risk Assessment or Penetration Test to iOS related platform. An iDevice should be treated the thick client on steroids. The features provide from an iOS device are amazing and very rich.

A good source that can be used as a starting point for developing a threat model for iOS should be the OWASP Mobile Security Project found here. The Top 10 Mobile Risks, Release Candidate v1.0 covers pretty much all risks that are associated with an iOS device. The following picture summarizes all risks identified:

Note: Risk M2, M5 and M6 are mostly server side related and I am not going to focus on these issue a lot.

Risk M1, M4, M8, M7, M9 and M10 are the most interesting of all the issue and I am going to spend a lot of time analyzing these issues. But before we do that it would be wise to focus a little in the type of interaction an iDevice has with the server component. Given the nature of the iOS based devices, and their willingness to blindly accept new configuration, hijacking both cellular traffic and WiFi traffic can usually be performed much more easily than a similar attack to a desktop machine. It is so easy, in fact that, that a device's traffic can be hijacked without even compromising the device itself. There are a number of ways to intercept network traffic across local networks; dozens of articles have been written on the subject.

The following picture shows a typical Web Server iPhone interaction:

Note: This is a simple Web Server, iPhone interaction.

The following pictures shows a typical attack scenarios that can be implemented very easily by exploiting the iPhone configuration of blindly accepting any wireless access points.

The following pictures shows a typical Man In The Middle attack scenarios that can be implemented again very easily due to the nature of the mobile (which by the way are mobile).

Note: The types of attacks that can be performed using the methodology of a rouge access point or the Man In The Middle attack scenarios are going to be explained in the next post.

Epilogue

This article covered the threat land scape for iDevices, which is identical for all mobile devices (e.g. iPhone, iPad, iTouch, iPad mini, Android devices etc.). The next part is going to cover Internet/Wireless attacks and the third is going to cover iDevice data attacks (e.g. attacking unencrypted and encrypted attacks). There might be though a fourth part that sums up all attack patterns together.

See part 2

Reference:

Pages

09/03/2013

The Hackers Guide To Dismantling IPhone (Part 1)