Mobile Security

1

Mobile Security

NSF Workshop on Mobile SecurityJune 27, 2014

2

Pillars of Mobile Operating System (OS) Security

• Traditional Access Control– Seek to protect devices using techniques such as passwords and idle-time

screen locking.• Encryption

– conceal data on the device to address device loss or theft.• Application Provenance

– Stamp each application with identity of its author and made it tamper resistant (e.g., digital signature). A consumer/user can decide to use or not to use the application based on the identity of the author.

• Application Security – limits applications ability to access sensitive data or systems on a device.– Permissions-based access control: grants set of permissions to each

application

3

Traditional Access ControlApple iOS• iOS provides traditional access control security options which include

password configuration options such as strength of passcode, maximum number of failed login attempts, password expiration, and password update frequency.

Android• Android provides password configuration options, which are similar

with iOS.

4

Effectiveness of Traditional Access Control

Apple’s iOS• The access control feature of the iOS provides a reasonable level of

security for the devices data in the event of loss or theft.• The iOS is comparable to traditional windows-based desktops in this

scenario.Android• The password policy system is sufficient to protect devices against

novice attacks.

5

Encryption

Apple iOS• The iOS uses a hardware accelerated AES-256 encryption to encrypt all

data stored in the flash memory of the device.• The iOS protects specific additional data items, such as email using an

additional layer of encryption.• Within 10 seconds of the device locking, the decryption keys for files

in device are discarded.

Android• Earlier versions of android contain no encryption capability. A simple

jailbreak of an android phone, or theft of device’s SD card can lead to significant loss of data.

• Android 3.0+ provides full file system encryption using device password to protect the encryption key.

6

Application ProvenanceApple iOS• Developers register with Apple company and pay annual license fees before releasing

applications (apps) to users of iPhone, iPod, or iPad. • Developers are required to “digitally sign” each app with an apple-issued digital

certificate before its release. This signing process prevents tampering of published apps and ties developers’ identity with assurance of their apps.

• If an app is found malicious, the app is removed from the app store, but no automated mechanism has been implemented to remove the app from devices.

Android• Android OS only installs and runs apps that have been properly signed with a digital

certificate. • Developers do not need not apply a digital certificate from Google and they can use

self-generated certificates.• Malware can be distributed by authors using anonymous digital certificate, and

Google has no way to track back to the author.• However, Google requires a $25 fee paid by credit card in order to put an app on

Android market, which allows Google to associate the payee with the digital certificate, reducing changes of distribution of malicious apps. It assumes that they use their own credit card.

7

Effectiveness Application ProvenanceApple iOS• Apple’s approach is effective as

– The developer must register and pay to obtain a signing certificate from apple, which makes it easy to trace and identify if any

malicious activities are performed.– Every application is tested before submission to the app store.– Apple’s code signing model prevents tampering with published

apps.Android• Since no single authority evaluates or verifies all Android apps,

attackers are more likely to release attacks without worrying of being caught.

8

Application (App) SecurityApple iOS• iOS operating system isolates each app from other apps on the system. • The apps are not allowed to modify or view each other’s data, or even

know existence of other apps. They cannot access the OS kernel, nor install privileged driver’s or obtain root level administrator access to the device.

• The apps are also isolated from the phone’s SMS, emails and email attachments.

Android• Like iOS, Android employs a strong isolation system. It not only isolates

apps from each other but also prevents apps from accessing or modifying the OS kernel, ensuring the app doesn’t get admin control over a device.

9

Effectiveness of Application (App) Security

Apple iOS• The iOS denies access under all circumstances to many of the device’s

sensitive subsystems. • This increases the security of iOS based devices since it relieves the

user from security decision-making process. • But it potentially limits the utility of certain classes of iOS apps.

Android• The Android permission system relies on the user to make all policy

decisions and decide whether an apps requested combination of permission is safe or not.

10

Examples of Isolation in Bring Your Own Devices (BYOD)

Blackberry Balance • Allows organizations to create isolation between personal and work

environments on a device. • Keeps personal applications, files and network separate from the work

environment.• When Balance is enabled, workspace is automatically encrypted,

leaving personal environment unencrypted.

Windows Phone 8 - Unified Extensible Firmware Interface • It is used for secure boot so that devices do not load rooted or

unauthorized system images.• The data between apps are shared in the cloud and not on the device.

11

Security Strength

Android Architecture

Process Isolation

App security Permission-

based access control

Application provenance

Inter-process communication

Android Security Design

Security goals• Protect user data • Protect system resources (hardware, software)

Foundations of Android Security 1. Process and application Isolation by Linux Kernel2. System-built and user-defined permissions 3. Secure inter-process communication 4. Application provenance

1. Process Security from Linux Kernel

• Each component assumes that the components below are properly secured.

• Linux kernel is responsible sandboxing application – Mutually distrusting principals– Default access to only its own data

• Process isolation– All code above the Linux Kernel is restricted by the

Application Sandbox– Each application is sandboxed to run on its own

process• All libraries and applications run within their own

sandboxes.

Android process isolation

• The process isolation prevents process A from accessing process B’s CPU, memory resources, and devices such as telephony, GPS, and bluetooth.

• The apps can only talk to other apps through Intents (message) , Inter-process Communication, or ContentProviders (data storage).

• To escape the sandbox, permissions are needed.

2. Android Application Security(Application framework)

• Almost all Android applications are written in the Java and run in the Dalvik virtual machine.

.java -> .class -> .jar -> .dex Android application deployed in a single .apk file.• Permissions are the core concepts in the Android security to

control the access from one application component to another. • The AndroidManifest.xml file is the configuration file of

Android application.– It instructs system what to do with activities, services,

broadcast receivers, and content providers in an application.

– It declares permissions.– Without user’s consent, an application will not be installed.

AndroidManifest.xml• Each application can declare the required permissions• If a public component doesn’t explicitly declare any access permission,

Android permits any application to access it.

<?xml version="1.0" encoding="utf-8"?><manifest . . . > <application . . . > <activity android:name="com.example.project.myActivity" <intent-filter>

<action android:name="android.intent.action.MAIN" />

<category android:name="android.intent.category.LAUNCHER" /> </intent-filter> . . .

</activity> <activity> ….. </activity>

<uses-permission android:name="android.permission.SEND_SMS" /> <uses-permission android:name="android.permission.INTERNET" /> . . .

</application></manifest>

3. Security for Inter-Process Communication

• Core components of an application — activities, services, and broadcast receivers — can send/receive messages, called intents.

• Intents (explicit & implicit) can– Start Activities– Start, stop, and bind Services– Broadcast information to Broadcast Receivers

• To receive Intents, component must be declared in the AndroidManifest.xml

Intents• Intent: notification from one process to another

– Implicit: can be received by anyoneIntent intent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.example.com")); startActivity(intent);

– Explicit: has one specific recipient and indicate exactly which activity class

Intent intent = new Intent(this, ActivityABC.class); i.putExtra("Value", "This value for ActivityABC"); startActivity(intent);

Intent Filters• To inform the system which implicit intents they can

handle, activities, services, and broadcast receivers can have one or more intent filters.

• Each filter describes a capability of the component, a set of intents that the component is willing to receive.

• It selects intents of a desired type, while filtering out unwanted intents

Security Risks in Android’s Inter-Process Communication

• Type 1: If the sender does not correctly specify recipient (can send to anyone), attackers can intercept messages and lead to attacks such as Broadcast theft, activity and service hijacking.

• Type 2: If a component does not restrict from whom it can receive messages (can receive from anyone), attacker can inject code. The attack can result in data corruption, code injection, malicious broadcast injection, malicious activity launch, malicious service launch.

Recommendations for Inter-Process Communication

• Use caution with implicit Intents• Use explicit Intents to send private data• Returned results should be checked for authenticity• Always assign a least permission to a application• Users have to grant explicit permission to third-party

applications requesting use of cost sensitive APIs including Telephony, messaging, networking, in-app billing, etc.

4. Application Provenance

• Android requires every application to be signed with its developer’s private key.

• It is self-signed. Why self signing? Market ties identity to developer account.

• Therefore, no application is trusted. • After a signed application is installed on the phone,

the system is able to use its signature information to distinguish it from other application.

Cont.

• All .apk files must be signed with a certificate– identifies the author of the application. – does not need to be signed by a certificate authority

• Allows the system to grant or deny applications – access to signature-level permissions– request to be given the same Linux identity as another

application.• If the public key matches the key used to sign any other

APK, the new APK may request to share a UID with the other APK.

Security threat #1 Trojan Horse Example (1)

• Vicky, a top-level manager• A file Market on the new products release• John, subordinate of Vicky• A file called “Stolen” • An application with two hidden operations

– Read operation on file Market– Write operation on file Stolen

25


26

Trojan Code


27

Trojan Code

28

Hands-on Lab #3

• Hide Trojan Horse in tic-tac-toe Game • Permissions

– READ_CONTACTS– WRITE_CONTACTS– RECEIVE_BOOT_COMPLETED (The attack begins

when the phone starts. )• Attack actions

– Read contacts from a phone– Delete all contact information

29

Security threat #2: Mobile Malware (1)

Malicious logic Mobile Trojan

5554

5556

30



Victim 5554 infected by Mobile Trojan 5554 sends a short MSG to 5556

31



Nothing happened at Victim 5554Receiver of Victim replies to 5554

32


Mobile Malware Defense • use a "ContentObserver" to listen to any actions on the internal database of Android.

Malicious logic

33

Hands-on Lab #4

• Start two emulators– 5554:Test– 5556:Test2

• Infect 5554:Test • Send message to 5556:Test2 through victim

5554:Test

Security threat #3: Injection

• Injection attacks trick an application into including unintended commands in the data send to an interpreter.

• Interpreters– Interpret strings as commands.– Ex: SQL, shell (cmd.exe, bash), LDAP, XPath

• Key Idea– Input data from the application is executed as

code by the interpreter.

Security threat #3: SQL Injection1. App sends form to user.2. Attacker submits form with SQL

exploit data.3. Application builds string with

exploit data.4. Application sends SQL query to

DB.5. DB executes query, including

exploit, sends data back to application.

6. Application returns data to user.

Web Server

Attacker

DB Server

Firewall

User

Pass ‘ or 1=1--

Form

Security threat #3: SQL Injection Example (1)

Unauthorized Access Attempt:password = ’ or 1=1 --

SQL statement becomes:select count(*) from users where username = ‘user’

and password = ‘’ or 1=1 --Checks if password is empty OR 1=1, which is always

true, permitting access.

Security threat #3: SQL Injection Example (2)

User ID: ` OR ``=`` --Password: abc

Because anything after the -- will be ignored, the injection will work even without any specific injection into the password predicate.

SQL Injection Countermeasures: Prepared Queries (1)

• bound parameters, which are supported by essentially all database programming interfaces.

• In this technique, an SQL statement string is created with placeholders - a question mark for each parameter - and it’s compiled ("prepared", in SQL parlance) into an internal form. Later, this prepared query is "executed" with a list of parameters.

Example in Perl: $sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;"); $sth->execute($email);

$email is the data obtained from the user's form, and it is passed as positional parameter #1 (the first question mark), and at no point do the contents of this variable have anything to do with SQL statement parsing. Quotes, semicolons, backslashes, SQL comment notation - none of this has any impact, because it's "just data". There simply is nothing to subvert, so the application is be largely immune to SQL injection attacks.

SQL Injection Countermeasures: Prepared Queries (2)

• bound parameters in JavaInsecure versionStatement s = connection.createStatement(); ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = " + formField); // *boom*

Secure versionPreparedStatement ps = connection.prepareStatement( "SELECT email FROM member WHERE name = ?"); ps.setString(1, formField); ResultSet rs = ps.executeQuery();

There also may be some performance benefits if this prepared query is reused multiple times (it only has to be parsed once), but this is minor compared to the enormous security benefits. This is probably the single most important step one can take to secure a web application.

40

Hands-on #5

• Inject SQLite Database of Android• Attacks:

– 1’ or ‘1’=‘1– 1’ or username not null

• CountermeasuresString m_argv[] = {m_id};cursor=db.rawQuery("SELECT * FROM usertable WHERE _id= ? ",m_argv );