Mobile Security NSF Workshop on Mobile Security - PowerPoint Presentation

Slide1

Mobile Security

NSF Workshop on Mobile SecurityJune 27, 2014

1Slide2

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

2Slide3

Traditional Access Control

Apple

iOS

i

OS 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.

3Slide4

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.4Slide5

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. 5Slide6

Application Provenance

Apple

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.

AndroidAndroid 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.

6Slide7

Effectiveness Application Provenance

Apple

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.7Slide8

Application (App) Security

Apple

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. 8Slide9

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.9Slide10

Examples of Isolation in Bring Your Own Devices (BYOD)

Blackberry Balance

A

llows 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.

10Slide11

11

Security StrengthSlide12

Android Architecture

Process Isolation

App security

Permission-based access control

Application provenance

Inter-process communicationSlide13

Android Security

Design

Security goals

Protect user data

Protect system resources (hardware, software) Foundations  of  Android  Security    Process and application Isolation by Linux KernelSystem-built and user-defined permissions Secure inter-process communication Application provenance Slide14

1.

Process Security from Linux Kernel

Each component assumes that the components below are properly secured.

Linux  kernel  is  responsible sandboxing application

Mutually distrusting principalsDefault access to only its own dataProcess isolationAll code above the Linux Kernel is restricted by the Application SandboxEach application is sandboxed to run on its own processAll libraries and applications run within their own sandboxes. Slide15

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. Slide16

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.Slide17

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> Slide18

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) canStart ActivitiesStart, stop, and bind ServicesBroadcast information to Broadcast ReceiversTo receive Intents, component must be declared in the AndroidManifest.xmlSlide19

Intents

Intent: notification from one process to another

Implicit: can be received by anyone

Intent

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); Slide20

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 intentsSlide21

Security

Risks in Android’s Inter-Process Communication

Type 1:

I

f 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.Slide22

Recommendations for Inter-Process Communication

Use caution with implicit

Intents

Use explicit Intents to send private data

Returned results should be checked for authenticityAlways assign a least permission to a applicationUsers have to grant explicit permission to third-party applications requesting use of cost sensitive APIs including Telephony, messaging, networking, in-app billing, etc. Slide23

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.Slide24

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 authorityAllows the system to grant or deny applications access to signature-level permissionsrequest 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. Slide25

Security threat #1

Trojan Horse Example (1)

Vicky

, a top-level manager

A file Market on the new products releaseJohn, subordinate of VickyA file called “Stolen”

An application

with two hidden operationsRead operation on file MarketWrite operation on file Stolen

25Slide26

Security threat #1

Trojan Horse Example (2)

26

Trojan CodeSlide27

Security threat #

1 Trojan Horse Example (3)

27

Trojan CodeSlide28

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 actionsRead contacts from a phoneDelete all contact information28Slide29

29

Security

threat #2: Mobile Malware (1)

Malicious logic

Mobile Trojan

5554

5556Slide30

30

Security

threat #2: Mobile Malware (2)

Malicious logic

Mobile Trojan

Victim 5554 infected by Mobile Trojan

5554 sends a short MSG to 5556Slide31

31

Security

threat #2: Mobile Malware (3)

Malicious logic

Mobile Trojan

Nothing happened at Victim 5554

Receiver of Victim replies to 5554Slide32

32

Security

threat #2: Mobile Malware (4)

Mobile Malware Defense

use a "ContentObserver" to listen to any actions on the internal database of Android.

Malicious logicSlide33

Hands-on Lab #4

Start two emulators5554:Test

5556:Test2

Infect

5554:Test Send message to 5556:Test2 through victim 5554:Test33Slide34

Security threat

#3: Injection

Injection attacks trick an application into

including unintended commands in the data send to an interpreter

.InterpretersInterpret strings as commands.Ex: SQL, shell (cmd.exe, bash), LDAP, XPathKey IdeaInput data from the application is executed as code by the interpreter.Slide35

Security threat

#3: SQL Injection

App sends form to user.

Attacker submits form with SQL exploit data.

Application builds string with exploit data.Application sends SQL query to DB.DB executes query, including exploit, sends data back to application.Application returns data to user.

Web Server

Attacker

DB Server

Firewall

User

Pass

‘ or 1=1--

FormSlide36

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.Slide37

Security threat #

3: SQL Injection Example (2)

User ID:

` OR ``=`` --

Password: abcBecause anything after the -- will be ignored, the injection will work even without any specific injection into the password predicate. Slide38

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. Slide39

SQL Injection Countermeasures: Prepared Queries (2)

bound parameters in Java

Insecure version

Statement s =

connection.createStatement

();

ResultSet

rs = s.executeQuery("SELECT email FROM member WHERE name = " + formField); // *boom*

Secure version

PreparedStatement

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. Slide40

Hands-on #5

Inject SQLite Database of AndroidAttacks:1’ or ‘1’=‘1

1’ or username not null

Countermeasures

String m_argv[] = {m_id};cursor=db.rawQuery("SELECT * FROM

usertable

WHERE _id=

? ",m_argv );40