v1.

MODULE 2

eLearnSecurity © 2014
2
2. Mobile OS Architecture & Security Models

HOME PARENT REFERENCES VIDEO

 3
2. Introduction
To completely understand how to breach mobile
device security, we must first know the mobile
platform features we will dealing with. In this
section, we are going to study in-depth the OS
architectures and the security models implemented
on both Android and iOS.

Android iOS

HOME PARENT REFERENCES VIDEO

4
2.1. Android

HOME PARENT REFERENCES VIDEO

5
2.1. Android

HOME PARENT REFERENCES VIDEO

 6
2.1. Android

Android is a software stack for mobile devices that

includes an Operating System, middleware and key
applications. It relies on Linux version 2.6 and 3.x
(starting from Android 4.0) for core system services
such as security, memory management, process
management, network stack, and driver models.
The kernel also acts as an abstraction layer
between the hardware and the rest of the software
stack.

HOME PARENT REFERENCES VIDEO

7
2.1.1. Android Architecture

HOME PARENT REFERENCES VIDEO

 8
2.1.1. Android Architecture
The following diagram shows the four main
components of the Android architecture:

HOME PARENT REFERENCES VIDEO

 9
2.1.1. Android Architecture

Android is based on the Linux kernel. This is the

first layer that interacts with device hardware. It
provides the fundamental software needed to
boot, manage power and memory, device drivers,
processes, applications, networking and security.

HOME PARENT REFERENCES VIDEO

 10
2.1.1. Android Architecture

After the kernel is a set of C/C++ libraries exposed

to the developers via the Java API. These libraries
act as a transaction layer between the kernel and
the application framework, providing some of the
common services available for apps and other
programs.
HOME PARENT REFERENCES VIDEO
 11
2.1.1. Android Architecture

Some of the core libraries are:

• Surface Manager: Graphics on the device screen
• WebKit: Web rendering engine
• SQLite: Database engine for data storage
• SSL: Secure Socket Layer
• Other libraries that handle fonts, media, display

HOME PARENT REFERENCES VIDEO

 12
2.1.1. Android Architecture

This layer is also shared with the runtime

component. It consists of a custom Java Virtual
Machine named Dalvik Virtual Machine (DVM) that
will interact with and run applications. Here, there
is also a set of core libraries that provide most of
the functionality available in the core Java libraries.
HOME PARENT REFERENCES VIDEO
13
2.1.1. Android Architecture
What is a virtual machine?

A virtual machine is an abstract computing

machine in which a guest Operating System
or program can be installed and run on the
same computer at the same time without
interfering with another. A virtual machine
executes applications and software as if
they are running on a physical machine.

HOME PARENT REFERENCES VIDEO

 14
2.1.1. Android Architecture

The Dalvik Virtual Machine is a mobile-optimized

virtual machine specifically designed to create an
efficient and secure mobile application
environment.

HOME PARENT REFERENCES VIDEO

 15
2.1.1. Android Architecture

Each application runs in its own instance of Dalvik

VM and user ID. By this method, many VMs can run
at once on the Android device, separating process
memory and files by means of the Linux kernel.

HOME PARENT REFERENCES VIDEO

 16
2.1.1. Android Architecture

Applications that run in a Dalvik VM have a special

format called Dalvik Executable (.dex).
A .dex file is made by taking the resulting byte code
compiled with the Java Development Kit, and
optimizing it for efficient storage and execution in
the Dalvik VM.

HOME PARENT REFERENCES VIDEO

 17
2.1.1. Android Architecture

In the next layer is the code compiled for and

running on the Dalvik VM that provides services to
multiple apps. The Application Framework is the
primary layer that third-party developers interact
with.
It provides abstract access to key resources that
applications will need.
HOME PARENT REFERENCES VIDEO
 18
2.1.1. Android Architecture

The top layer is the Applications layer. Here is

where all the applications like email clients,
contacts, calendar, browser, maps, custom apps,
etc., live. In other words, the user interacts with
this layer while the applications are executed in this
space using API libraries and in the Dalvik VM.

HOME PARENT REFERENCES VIDEO

19
2.1.2. Android Security Model

HOME PARENT REFERENCES VIDEO

 20
2.1.2. Android Security Model

The Android platform implements security through

different controls and mechanisms. As we have
already noted, Android runs on the top of the Linux
kernel.
The existence of the Linux kernel base ensures that
security features are built into the device at the
Operating System level.

HOME PARENT REFERENCES VIDEO

 21
2.1.2.1. Privilege Separation and Sandboxing

Linux systems focus their security on the concept of

users and groups. Indeed, each time a new user is
created, it is assigned a User ID (UID). In addition,
each user can be added to groups, and each group
has its own Group ID (GID).
Each resource can also be given three types of
permissions: owner, group, and the rest of the
world. Each of these is a unique permission set.

HOME PARENT REFERENCES VIDEO

 22
2.1.2.1. Privilege Separation and Sandboxing

The Android kernel implements a similar separation

model when it comes to executing applications. It
assigns a unique User ID (UID) and Group ID (GUI)
to each application and runs the app as that user in
a separate process, thanks to the Dalvik VM.
This differs slightly from other OSs wherein
multiple applications run with the same user
permissions.

HOME PARENT REFERENCES VIDEO

 23
2.1.2.1. Privilege Separation and Sandboxing
The following screenshot shows a list of processes
running on an Android device and their UIDs:

HOME PARENT REFERENCES VIDEO

 24
2.1.2.1. Privilege Separation and Sandboxing

As you can see, each application runs with its own

UID. This model ensures that applications and
processes have no permissions to access other
applications, processes or Operating System data.
Then, if application A tries to access data from
application B, the operating system denies access
since A does not have the appropriate user
privileges (a different UID).

HOME PARENT REFERENCES VIDEO

 25
2.1.2.1. Privilege Separation and Sandboxing

This is known as sandboxing. The idea behind the

sandbox is simple: when two or more processes
run in their own sandboxes, they can communicate
with each other only if they explicitly request and
are granted permission to access each other.

HOME PARENT REFERENCES VIDEO

 26
2.1.2.1. Privilege Separation and Sandboxing

Also, note that since the sandbox is implemented in

the kernel, this security feature is extended to all
software above the first layer (Linux Kernel)
including system libraries, Android runtime,
application framework and applications.

HOME PARENT REFERENCES VIDEO

 27
2.1.2.2. File system isolation

Each time an application is installed on the device,

a new User ID and a new directory is created for
that specific application.
All data stored in internal storage by that
application (files, databases, etc.) is assigned the
same UID.

HOME PARENT REFERENCES VIDEO

 28
2.1.2.2. File system isolation

If you do not know how to read Linux file

permissions, here is a quick guide:

els@els: /home/$ ls -l
drwxr-xr-x 3 els elsgroup 60 2005-09-20 21:37 dir
-rw-r----- 1 els elsgroup 8187 2005-09-19 13:35 file1
-rwxr-xr-x 1 els elsgroup 10348 2005-07-17 20:31 file2

Number of Group the Date and time of

links file belongs last modification
to

Filetype and Owner File size File name

permissions of the
file
VIDEO
HOME PARENT REFERENCES
 29
2.1.2.2. File system isolation

The first column is organized into four separate

groups:

d rwx r-x r-x

Consist of one
character and Read, write and Read, write and Read, write and
shows the file execution execution execution
type: permission for permission for permission for
d = directory the file owner the group of others
l = link user the file (everyone else)
- = file

HOME PARENT REFERENCES VIDEO

 30
2.1.2.2. File system isolation
By default on Android, only the associated UID (and
root UID) have full privileges on these resources,
unless the developer explicitly exposes files to
other applications.

HOME PARENT REFERENCES VIDEO

 31
2.1.2.2. File system isolation
For example, running a terminal emulator app on a
physical device, we are able to browse the
emulator application folder since we (the app) are
the owner, but we cannot browse the /data/data
directory, where all the application folders are
stored.
Terminal application directory

data/data folder

HOME PARENT REFERENCES VIDEO

 32
2.1.2.3. Storage and Database isolation
When we consider external storage like SD cards,
things are different. Indeed, as we can see in the
following snapshot, data is accessible to anyone:

HOME PARENT REFERENCES VIDEO

 33
2.1.2.3. Storage and Database isolation

This happens because the format for these SD

cards is VFAT, an old standard that does not
support the access control mechanism
implemented in Linux.
So, data stored on the SD card is both accessible
and writeable by any installed application, which
may be abused to escalate privileges to another
application by crafting files that exploit
vulnerabilities in special cases.

HOME PARENT REFERENCES VIDEO

 34
2.1.2.3. Storage and Database isolation

There are a few other ways for Android apps to

store data on the device:

• SharedPreferences
• Databases

HOME PARENT REFERENCES VIDEO

 35
2.1.2.3. Storage and Database isolation
SharedPreferences allow apps to store and retrieve
persistent key-value pairs. Persistent means that
they will persist across the device sessions. They
can be accessed using the SharedPreferences
object and are stored as an XML file in the folder
/data/data/your_app/shared_prefs.

HOME PARENT REFERENCES VIDEO

 36
2.1.2.3. Storage and Database isolation

ndroid also provides full support for SQLite

databases. Database files reside in the directory
data/data/your_app/databases and, much like
SharedPreferences,
by default they can
be accessed only
by the UID of the
related app.

HOME PARENT REFERENCES VIDEO

 37
2.1.2.4. Application signing

The Application Signing process ensures integrity

and authenticity by verifying that the APK (Android
Application Package File) has been signed with the
certificate included in the APK. This helps to avoid
the application being tampered with and also
assists in ensuring that the file comes from the
author that it claims to come from.

HOME PARENT REFERENCES VIDEO

 38
2.1.2.4. Application signing

All applications must be signed, otherwise they

cannot be installed on the device. The signing
process is used to identify the application author
and it allows the developer to update or edit his
applications. Also, applications signed with the
same key can share the same UID and Application
Sandbox.

HOME PARENT REFERENCES VIDEO

 39
2.1.2.4. Application signing

As we have already noted, different applications

run under different UIDs and the certificate defines
which UID is associated with which application.
When an application is installed, the Packet
Manager (layer 3) verifies that the application is
signed; if the certificate matches the key used to
sign another existing application, both can share
the same UID, process, memory and data storage.

HOME PARENT REFERENCES VIDEO

 40
2.1.2.4. Application signing

Summarizing the process, when an application is

released in the Play Store, it must be signed with
the developer key.
If a malicious user gets the application and edits it,
they must re-sign the application. Since their
private key is different from the original developer
key, this signing will result in a different app.

HOME PARENT REFERENCES VIDEO

 41
2.1.2.5. Permission model

By default, when an Android application is

installed, it can access only a limited set of
resources. This helps to ensure that malicious
applications do note perform operations such as
sending texts, using the camera, using a network
connection or accessing sensitive data like contacts,
GPS location and so on.

HOME PARENT REFERENCES VIDEO

 42
2.1.2.5. Permission model

These sensitive APIs are intended to be used only

by trusted applications via a security mechanism
called Permission. They are accessible only to the
Operating System and if an application wants to
use them, the permission must be defined in the
file AndroidManifest.xml.
Through this manifest permission, Android keeps
track of what the user allows the application to do.

HOME PARENT REFERENCES VIDEO

 43
2.1.2.5. Permission model

Each application must have its own

AndroidManifest.xml file. This allows the
application to request permission to use system
resources. In the next screenshot, we can see that
the application asks permission for three protected
components:
• INTERNET
• CAMERA
• MANAGE_ACCOUNTS

HOME PARENT REFERENCES VIDEO

44
2.1.2.5. Permission model

HOME PARENT REFERENCES VIDEO

 45
2.1.2.5. Permission model
With this approach, installation of an application
causes the system to display a dialog that indicates
the permissions requested
and then lets the user
decide whether or
not to trust the app.

HOME PARENT REFERENCES VIDEO

 46
2.1.2.5. Permission model
Each permission has different protection levels that
indicate the procedure the system follows when the
permission is requested.
dangerous signature signatureOrSystem
normal

• A lower-risk • A higher-risk • A permission that the • A permission that the

permission that gives permission that would system grants only if system grants only to
requesting give a requesting the requesting applications that are
applications access to application access to application is signed in the Android system
isolated application- private user data or with the same image or that are
level features, with control over the certificate as the signed with the same
minimal risk to other device that can application that certificate as the
applications or the negatively impact the requested the application that
user. The system user. The system may permission. declared the
automatically grants not automatically permission.
this permission grant it to the
without asking for the requesting
user's explicit application.
approval.

HOME PARENT REFERENCES VIDEO

 47
2.1.2.6. Memory management security enhancement
In addition to the previous security models, Android
continues to implement many features that make common
security issues harder to exploit:
Android 1.5 Android 2.3 Android 4.0 Android 4.1

• ProPolice to prevent • Format string • Address Space Layout • PIE (Position

stack buffer overruns vulnerability Randomization (ASLR) Independent
• safe_iop to reduce protections to randomize key Executable) support
integer overflows • Hardware-based No locations in memory • Read-only relocations
• Extensions to eXecute (NX) to / immediate binding (-
OpenBSD dlmalloc to prevent code Wl,-z,relro -Wl,-z,now)
prevent double free() execution on the stack • dmesg_restrict
vulnerabilities and to and heap enabled (avoid leaking
prevent chunk • Linux kernel addresses)
consolidation attacks. mmap_min_addr to • kptr_restrict enabled
• OpenBSD calloc to mitigate null pointer (avoids leaking kernel
prevent integer dereference privilege addresses)
overflows during escalation
memory allocation

HOME PARENT REFERENCES VIDEO

 48
2.1.2.7. Components
Android apps are comprised of one or more
components:

Content Broadcast
Activity Services
Providers Receivers

Some components are critical from a security point

of view, because they can allow other apps to
access data, communicate and execute operations
on other apps.

HOME PARENT REFERENCES VIDEO

 49
2.1.2.7. Components

An Activity is a component that provides a screen

and lets the user interact with it. They allow
applications to call each other, invoking
functionality from each other and allowing for
replacement or improvement of individual system
pieces whenever the user likes.

HOME PARENT REFERENCES VIDEO

 50
2.1.2.7. Components
In other words, activities are windows wherein the
user interface is defined.

HOME PARENT REFERENCES

VIDEO
 51
2.1.2.7. Components

Since Android does not allow a common storage

area, Content Providers are the standard way to
efficiently share data between processes
(applications) securely.
In other words, content providers allow
applications to gain access to the internally-stored
data of a different application.

HOME PARENT REFERENCES VIDEO

 52
2.1.2.7. Components

In order to share data with other applications,

content providers use one or more tables which are
very similar to tables used in relational databases.
Each row is an instance (a piece) of data while each
column represents all data of the specific type.
_ID Name Last_Name email
1 Mary Smith [email protected]
2 Frank Otavalli [email protected]
3 Mario Rossi [email protected]

HOME PARENT REFERENCES VIDEO

 53
2.1.2.7. Components
A few practical examples of well-known content
providers are:
• Calendar provider
• Contacts provider

HOME PARENT REFERENCES VIDEO

 54
2.1.2.7. Components

A Broadcast Receiver is a component that listens

for asynchronous requests initiated by an Intent (a
message). An app can register for a system or
application event and get notified when this event
happens.

NOTE: Intents are covered later.

HOME PARENT REFERENCES VIDEO

 55
2.1.2.7. Components

Services are background processes provided by

Android. These components can run when an app
is not visible to the user and typically carry out
computations or update data sources for the
application.

HOME PARENT REFERENCES VIDEO

 56
2.1.2.7. Components

Without having the correct

permissions, calling these
components will raise
a SecurityException:

HOME PARENT REFERENCES VIDEO

 57
2.1.2.7. Components

Intents are Android mechanisms for asynchronous

IPC (inter-process communication). They allow one
application to send messages directly to a specific
component (or broadcast them) to control tasks or
transport data.
Components like activities, broadcast receivers and
services are activated via intents.

HOME PARENT REFERENCES VIDEO

 58
2.1.2.7. Components

An intent contains a significant amount of

information. Some of it is necessary for the receiver
to take an action, while others are parsed by the
OS.
For example, the Operating System needs to know
the category of the component that should handle
the intent and also needs instructions on how to
launch the activity.

HOME PARENT REFERENCES VIDEO

 59
2.1.2.7. Components

The structure of an intent can be summarized as

follows:
• Action: The action that has to be performed.
• Data: The URI of the data on which to operate.
• Type: The specific MIME type of the data.
• Category: Additional information about the
action to take and the component that should
handle the intent.

HOME PARENT REFERENCES VIDEO

 60
2.1.2.7. Components

• Component: Explicit name of the component

that should handle the intent.
• Extras: Additional information to be sent to the
component that handles the intent.
• Flags: Flags that tell the system how to launch
an Activity and how to treat it after the launch.

HOME PARENT REFERENCES VIDEO

 61
2.1.2.7. Components

An example of an intent that is sent when we click

the application icon from the launcher is:
Category. LAUNCHER
Start an activity
means, “appear as a
top-level application
Action name to be performed. MAIN means
in the Launcher”
to start as the initial activity.

Flags of various sorts Component name that should handle the intent.
The HelloWorld application.

HOME PARENT REFERENCES VIDEO

 62
2.1.2.8. Google Bouncer

During the last few years, the amount of mobile

malware and malicious applications in the Android
market has grown exponentially.
Many applications found in the market have had as
their primary purpose, “to infect user’s devices and
gain access to sensitive information.“

HOME PARENT REFERENCES VIDEO

 63
2.1.2.8. Google Bouncer

To handle the lack of security mechanisms in the

application approval process, in 2011, Google
introduced a new layer in Android security:
Bouncer.
Google Bouncer is a service developed by Google
which automatically scans the Android Market,
looking for potentially malicious applications.

HOME PARENT REFERENCES VIDEO

 64
2.1.2.8. Google Bouncer

While the Bouncer service runs in the background

without requiring developers to go through an
approval process, it performs analysis against:
• new applications.
• applications that already exist in the Market.
• developer accounts.

HOME PARENT REFERENCES VIDEO

 65
2.1.2.8. Google Bouncer

This means that there is no restriction at all on the

application upload process. So, until Bouncer finds
suspicious behavior, the application will be
available in the Market.

HOME PARENT REFERENCES VIDEO

 66
2.1.2.8. Google Bouncer

Every time an application is uploaded to the

market, bouncer runs it in a simulated environment
and verifies that the application does not have
malicious behavior.
During its tests, Bouncer looks for known malware
and compares the application against previously
analyzed applications to detect possible hidden or
malicious behavior.

HOME PARENT REFERENCES VIDEO

 67
2.1.2.8. Google Bouncer

While Bouncer seems to have reduced the number

of potentially malicious applications in the Market,
two security researchers (Charlie Miller and Jon
Oberheide) recently demonstrated how Bouncer
can be bypassed.

HOME PARENT REFERENCES VIDEO

68
2.1.3. Rooting the device

HOME PARENT REFERENCES VIDEO

 69
2.1.3. Rooting the device

Rooting is the process of an Android user gaining

higher privileges (root) on the device. Doing this
will allow the user to perform many more
operations on the device.
Rooting allows access and editing of system files,
folders and settings, deleting or editing carrier- and
manufacturer-apps, increasing performance,
installing custom software (e.g. ROMs) and more.

HOME PARENT REFERENCES VIDEO

 70
2.1.3. Rooting the device

The main purpose of rooting is to bypass the

system and manufacturer limitations to perform
operations that otherwise we could not:
• Installing different Android versions
• Installing custom ROMs and software
• Wi-Fi tethering
• Overclocking and battery improvement
• Removing pre-installed apps

HOME PARENT REFERENCES VIDEO

 71
2.1.3. Rooting the device

From the Penetration Tester point of view,

obtaining root privileges on the device is a goal,
because with root privileges we are be able to do
anything we want on the device; we will gain
complete and unrestricted access to memory and
storage. The security models and the isolation
mechanisms on file, folders and other data do not
exist when apps run with root privileges.

HOME PARENT REFERENCES VIDEO

72
2.1.3. Rooting the device

HOME PARENT REFERENCES VIDEO

 73
2.1.3. Rooting the device

Rooting an Android device could be as simple as

one click; it depends on the device you are trying to
root. The most common tools in use are:
• OneClickRoot
• SuperOneClick
• z4Root
• GingerBreak
• UnlockRoot

HOME PARENT REFERENCES VIDEO

74
2.2. iOS

HOME PARENT REFERENCES VIDEO

75
2.2. iOS

HOME PARENT REFERENCES VIDEO

 76
2.2. iOS

iOS is the Operating System developed specifically

for iPhone but now used in most other Apple
devices like the iPad, iPod Touch and Apple TV. It is
based on the Mac OS X kernel (they share the use
of Objective-C and many APIs) and contains several
layers used to run applications.

HOME PARENT REFERENCES VIDEO

77
2.2.1. iOS Architecture

HOME PARENT REFERENCES VIDEO

 78
2.2.1. iOS Architecture
At the highest layer level, iOS acts as intermediary
between apps and hardware, while at the lower
levels are the fundamental services and
technologies.

HOME PARENT REFERENCES VIDEO

 79
2.2.1. iOS Architecture
Core OS
Accelerate Core Bluetooth External Accessory
Framework Framework Framework

Generic Security Security Framework

System
Services Framework

The lowest layer is the Core OS, which is the

foundation of the Operating System. This is the
layer that resides right above the hardware and
provides services like networking, memory
management, file system management, drivers,
crypto library and low-level UNIX interfaces.
HOME PARENT REFERENCES VIDEO
 80
2.2.1. iOS Architecture
Core Services
Core Mobile Core Core
Core Data
Services
Location Accounts Networking
Core Telephony
Framework
Store Kit SQLite

The Core Services layer provides abstraction from

the Core OS layer and contains the fundamental
system services that all applications use.

VIDEO
HOME PARENT REFERENCES
 81
2.2.1. iOS Architecture
Media
Assets Library Core Audio Core Graphics
Media
Core Text OpenGL Player
Framework

The Media layer provides multimedia services and

contains all graphics, audio, and video technologies
applications need.

HOME PARENT REFERENCES VIDEO

 82
2.2.1. iOS Architecture
Cocoa Touch
UIKit Address Book Message UI
Push
Alerts Notification Event Kit UI
Services

The Cocoa Touch layer is the key framework for

programming iOS applications. It contains
technologies that provide the infrastructure
needed to implement the visual interface for
applications.

HOME PARENT REFERENCES VIDEO

83
2.2.2. iOS security models

HOME PARENT REFERENCES VIDEO

 84
2.2.2. iOS security models

Apple has incorporated many security models to

protect users (and their data) against attacks.

HOME PARENT REFERENCES VIDEO

 85
2.2.2.1. Privilege separation

iOS separates processes using the traditional UNIX

file permission mechanism: owner, user and group.
While applications that the user can access (third
party apps, web browser, etc.) run as mobile user,
critical system processes run as privileged user
root. This mechanism limits exploit damage
because these apps are restricted at the system
level by the user privileges.

HOME PARENT REFERENCES VIDEO

 86
2.2.2.2. Sandbox

The privilege separation is further enforced by

sandboxing: further than the UNIX permission
system goes, the sandbox allows better and more
comprehensive control over the actions that
processes and applications can perform. Even if
two applications run as the same user (mobile),
they are not, by default, allowed to browse, access
or modify each other’s data.

HOME PARENT REFERENCES VIDEO

 87
2.2.2.2. Sandbox

Each application is installed in its own directory

(private/var/mobile/Applications/ID) which acts as
the app home, and is identified with a random ID.
Once installed, applications have limited read
access to some system areas and functions (such as
SMS, phone call, etc.), and have no rights in
directories that belong to other applications.

HOME PARENT REFERENCES VIDEO

 88
2.2.2.2. Sandbox

If an application wants to
access protected areas,
permission for this specific
functionality is granted
through a pop-up to
the user.

HOME PARENT REFERENCES VIDEO

 89
2.2.2.3. Code signing

As part of its application security model, Apple has

incorporated application signing to manage the
binary code allowed to run on a device. Indeed, all
binaries and libraries must be signed by Apple (or
with a trusted certificate issued by Apple) before
they can be executed. Note that the application
signature is validated each time the app is
executed.

HOME PARENT REFERENCES VIDEO

 90
2.2.2.3. Code signing

Since only Apple can sign applications, the signing

plays a very important role in filtering out malicious
apps. Indeed Apple will not sign applications that
dynamically change behavior.
This avoids malicious apps attempting to download
new code at runtime, or attempting to install and
execute arbitrary code.
If you want to know more about code signing,
please read the official documentation here.

HOME PARENT REFERENCES VIDEO

 91
2.2.2.4. Keychain and Encryption

A Keychain is an encrypted container that holds

passwords, cryptographic keys, certificates and text
strings for multiple applications and services. In
iOS, each application always has access only to its
own keychain items. As you can imagine, this is one
of the most targeted components in iOS systems.

HOME PARENT REFERENCES VIDEO

 92
2.2.2.4. Keychain and Encryption

By default, iOS provides a four digit PIN to prevent

unauthorized access (instead of a login password
like OS X), but this code is too weak to be used as a
master key for encryption. For this reason, a unique
key (per device) called the UID-key is generated
and stored in a location that is inaccessible to
applications. Only the onboard cryptographic
accelerator can use this key.

HOME PARENT REFERENCES VIDEO

 93
2.2.2.4. Keychain and Encryption
The UID is used as a master key to
derive other device keys used for
files, keychain items, and more.
Also, the user’s passcode (PIN)
is also encrypted using this UID key
when the device is unlocked. This
ensures that data encrypted with
the passcode key can be accessed
only if the passcode is provided
(when the user unlocks the phone).
HOME PARENT REFERENCES VIDEO
 94
2.2.2.4. Keychain and Encryption

Basically, on iOS, we have the following situation:

Embedded Master Key User Passcode

Derived Keys Passcode Key

Device data that must be Data (such as mail, attachments,

decrypted without screenshots and specific 3rd-party
the user’s passcode files) that can be decrypted only if
the user unlocks the phone with a
passcode.

HOME PARENT REFERENCES VIDEO

 95
2.2.2.5. DEP/ASLR

As we have already noted, the code-signing

mechanism implemented by Apple prevents
applications from executing, loading and
downloading unsigned code at runtime or using
self-modifying code. This ensures much stronger
protection than DEP (Data Execution Prevention), a
mechanism used to prevent portions of data from
being executed.

HOME PARENT REFERENCES VIDEO

 96
2.2.2.5. DEP/ASLR

Typically, DEP may be bypassed using ROP (Return-

Oriented Programming) to create sections of
memory that are writable or executable. Once
these sections are created, attackers can write and
execute their payload.
Since Apple code-signing ensures that nothing can
be executed unless it has originated from signed
code, this kind of attack is not possible.

HOME PARENT REFERENCES VIDEO

 97
2.2.2.5. DEP/ASLR

The only way to bypass the Apple code signing

mechanism is by creating the entire payload using
ROP, which, as you can imagine, is very difficult.

HOME PARENT REFERENCES VIDEO

 98
2.2.2.5. DEP/ASLR

To enhance iOS security, making ROP exploits even

harder, Apple introduced ASLR (Address Space
Layout Randomization) in iOS 4.3. With this new
security mechanism, the location of binary, stack,
library and memory addresses are randomized,
making the exploitation of memory corruption
vulnerabilities much more difficult (the attacker
does not know where code segments to use for
ROP will be located!)

HOME PARENT REFERENCES VIDEO

 99
2.2.2.5. DEP/ASLR

Thanks to otool (we will see later where to

download it and how to use it), we can verify
whether an application has full ASLR protection. In
the following screenshot, we can see that the
application LogMeIn has the PIE (Position
Independent Executable) flag applied.

HOME PARENT REFERENCES VIDEO

 100
2.2.2.5. DEP/ASLR
As we can see in the following screenshots,
memory addresses change every time we restart
the app (or the device).

HOME PARENT REFERENCES VIDEO

 101
2.2.2.6. Reduced OS

In addition to the previous security mechanisms,

Apple also stripped out some of the functionality
offered by iOS. For example, an attacker can no
longer execute the shell, because there is no shell.
Also, many vulnerable applications, such as Java
and Flash, are unavailable. This reduces potential
system vulnerabilities and makes the exploitation
process on iOS devices more difficult.

HOME PARENT REFERENCES VIDEO

 102
2.2.2.7. Security iOS Overview

If you want to dig more deeply into iOS Security

models and mechanisms, the following document
will be very useful:
https://developer.apple.com/library/ios/document
ation/security/conceptual/security_overview/Secur
ity_Overview.pdf

HOME PARENT REFERENCES VIDEO

103
2.2.3. Jailbreaking the device

HOME PARENT REFERENCES VIDEO

 104
2.2.3. Jailbreaking the device

Jailbreaking is the process of removing Operating

System limitations imposed by the manufacturer.
As you remember, only signed applications can be
installed on the device. The main reason why one
would jailbreak a device is to remove this
limitation. This allows any code to run on the
device and files to be read and written anywhere.

HOME PARENT REFERENCES VIDEO

 105
2.2.3. Jailbreaking the device

Jailbreaking a device for Penetration Testing

purposes will allow us to perform better inspection
of the device, but it is worth noting that jailbroken
devices are open to a handful of additional security
risks and issues: malware, a weak sandbox, SSH
authentication with the default password, etc.

HOME PARENT REFERENCES VIDEO

 106
2.2.3. Jailbreaking the device

There are many benefits that a Penetration Tester

can get by jailbreaking a device. It allows the use of
tools to monitor the device, debug applications,
remotely access the device or install unsigned
applications. By jailbreaking a device, we will be
able to display active processes, capture network
traffic, change privileges on files and folders, access
memory locations and much more.

HOME PARENT REFERENCES VIDEO

 107
2.2.3. Jailbreaking the device

Here is a short list of common jailbreaking tools

available online:
• redsn0w
• Sn0wbreeze
• evasi0n
• JailbreakMe
• Absinthe
• PwnageTool

HOME PARENT REFERENCES VIDEO

 108
2.2.3. Jailbreaking the device
IMPORTANT

Apple does not support jailbreaking. Jailbreaking a

device violates the iOS end-user software license
agreement. Also note that, depending on your
country, jailbreaking a device may be illegal.
If you want to know more, please read the
following apple warning.

HOME PARENT REFERENCES VIDEO

 109
2. Mobile OS Architecture & Security Models

Now that we have an overview of the architectures

and security mechanisms implemented by the two
most important mobile Operating Systems, we can
move on and start configuring our environment to
work with them.

HOME PARENT REFERENCES VIDEO

 110
2. Mobile OS Architecture & Security Models

In the following modules, we will take a look at

how to configure our machine in order to install
both Android and iOS SDKs as well as the tools
needed to perform security tests against the
devices and their applications.

HOME PARENT REFERENCES VIDEO

111
References

Components Activity

Content Providers Broadcast Receivers

Services Intents

Google Bouncer iOS Security Overview

Bypass
HOME PARENT REFERENCES VIDEO
112
References

iOS Sandbox iOS Jailbreaking

iOS Code Signing

HOME PARENT REFERENCES VIDEO