Android Security (and lack of it)

Bruno Crispo and Yury Zhauniarovich

crispo@disi.unitn.it

University of Trento

INTRODUCTION

2

Smart-Phones

B. Crispo 3

SMARTPHONES: Plenty of Sensors

B. Crispo 4

MEMS Microelectromechanical systems

• Temperature

• Humidity

• Noise - MIC

• soon NFC

Smart-phone Usage

B. Crispo 5

WHY ANDROID?

6

Mobile Operating Systems

7

Smart-Phones Platforms

B. Crispo - 12th April 2011 8

Worldwide Share of worldwide 2010-2011 Q2 smartphone sales to end users by operating system, according to Gartner.

US Source: Nielsen (January 2012)

Why do we choose Android?

• The most selling mobile OS in the USA

• Occupies the first place among OS installed on new devices

• Open source system

• Third-party applications can be easily developed

• Ability to test third-party applications without publishing them

in the Android market

9

History of Android

10

• Android Inc. company was founded in Palo Alto (USA) in October 2003 by Andy Rubin et al.

• In August 2005 Android Inc. is acquired by Google

• On the 5th of November 2007 a consortium of several companies announces the creation of Open Handset Alliance, the main purpose of which is the development of open standards for mobile devices

• At the same day OHA unveiled its first product Android OS

1.5 Cupcake

1.6 Donut

2.0, 2.1 Eclair

2.2 Froyo

2.3.x Gingerbread

3.x.x Honeycomb

4.0.x Ice Cream Sandwich

Android Code Quality

• The Android kernel has approximately half the defects that would be expected for average software of the same size.

• The Android-specific code that differs from the Linux kernel had about twice the defect density of the core Linux kernel components.

• The Android kernel has better than industry average defect density (one defect for every 1,000 lines of code).

• Accountability for Android software integrity is fragmented.

Souce: Coverity, www.coverity.com

WHAT IS ANDROID?

12

What is Android?

Android is a set of programs for mobile devices that includes operating system, middleware and core applications

13

Linux Kernel

Linux features:

• Hardware abstraction layer

• Memory management

• Process management

• Security module

• Networking

• etc

Android enhancements:

• Ashmem

• Power management

• Binder IPC

• Logger

• etc

14

Android Native Libraries

Features:

• Libraries are written in C++

Used for:

• Windows management

• 2D and 3D graphics

• Media codecs

• Font rendering

• SSL

• The core of datastorage

• The core of web browser

• Bionic libc

15

Android Runtime

Dalvik VM:

• Virtual machine for Android to run applications

• Provides application portability

• Supports multiple instances

• CPU and memory optimized to run on mobile devices

Core Libraries:

• Data structures

• Utilities

• File access

• Network access

• Graphics

• etc

16

Application Framework

Core platform services:

• Essential services to the Android platform:

– Activity manager

– Package manager

– Window manager

– Content providers

Hardware services:

• Provide access to lower-level hardware API:

– Telephony Service

– Location Service

– Bluetooth Service

– WiFi Service

– USB Service

– Sensor Service

17

Applications

Core platform applications:

• Email application

• SMS application

• Contacts

• Phone

• Browser

• etc

Third-party applications:

• Applications that are produced by third-party developers

• No support for application developed for other platforms

18

APPLICATIONS

19

Application Fundamentals

• Android applications are written using Java-language

• Android is a multiuser system because it is built on the Linux Kernel, but the users of the OS are applications

• Each process has its own virtual machine (VM), so an application's code runs in isolation from other applications.

20

Application Components

B. Crispo - 21

Activities provide a user interface, Services execute background processing, Content providers are data storage facilities, and Broadcast receivers act as mailboxes for messages from other applications.

Android Applications --- Example

Example of location-sensitive social networking application for mobile phones in which users can discover their friends’ locations.

Android Applications --- Example

Take FriendTracker application for example,

FriendTracker (Service) polls an external service to discover friends’ locations

FriendProvider (Content provider) maintains the most recent geographic coordinates for friends

FriendTrackerControl (Activity) defines a user interface for starting and stopping the tracking functionality

BootReceiver (Broadcast receiver) gets a notification from the system once it boots (the application uses this to automatically start the FriendTracker service).

Android Applications--- Component Interaction

• Intent - is the primary mechanism for component interaction, which is simply a message object containing a destination component address and data

• Action - the process of inter-components communication

Android Applications--- Component Interaction (cont.)

Example: Interaction between components in applications

and with components in system applications. Interactions

occur primarily at the component level.

Android Applications--- Component Interaction (cont.)

Each component type supports interaction specific to its type. For example, Service components support start , stop, and bind actions, so the FriendTrackerControl (Activity) can start and stop the FriendTracker (Service) that runs in the background.

Security Enforcement

• Android protect application at system level and at the Inter-component communication (ICC) level.

• Each application runs as a unique user

identity, which lets Android limit the potential damage of programming flaws.

Security Enforcement (cont.)

Application isolation (kernel level)

ICC Reference Monitor provides MAC (middleware level)

Security Enforcement (cont.)

• Core idea of Android security enforcement - labels assignment to applications and components

• A reference monitor provides mandatory access control (MAC) enforcement of how applications access components.

• Access to each component is restricted by assigning it an access permission label; applications are assigned collections of permission labels.

• When a component initiates ICC, the reference monitor looks at the permission labels assigned to its containing application and— if the target component’s access permission label is in that collection— allows ICC establishment to proceed.

Android Permission Model

• Permission Protection Levels – Normal – Dangerous – Signature – Signature or System

B. Crispo - 25 Oct. 2010 30

Manifest

Permission Labels L1,…….

A: ….

Application 2

Permission Labels

…….

C: L2

Application 1

B: L1

Security Enforcement

• Assigning permission labels to an application specifies its protection domain. Assigning permissions to the components in an application specifies an access policy to protect its resources.

• Android’s policy enforcement is mandatory, all

permission labels are set at install time and can’t change until the application is reinstalled.

• Android’s permission label model only restricts access to components and doesn’t currently provide information flow guarantees.

Security Refinements --- Public vs. Private Components

• Applications often contain components that another application should never access. For example, component related to password storing. The solution is to define private component.

• This significantly reduces the attack surface for many applications.

Security Refinements --- Implicitly Open Components

• At development time, if the decision of access permission is unclear, the developer can permit the functionality by not assigning an access permission to it.

• If a public component doesn’t explicitly have an access permission listed in its manifest definition, Android permits any application to access it.

Security Refinements --- Broadcast Intent Permissions

• Sending the unprotected intent is a privacy risk.

• Android API for broadcasting intents optionally allows the developer to specify a permission label to restrict access to the intent object.

Security Refinements --- Content Provider Permissions

• If the developer want his application to be the only one to update the contents but for other applications to be able to read them.

• Android allows such a security policy assigning read or write permissions.

Application Distribution

36

All applications are distributed using .apk file format. This file is an archive of files: • AndroidManifest.xml • classes.dex • resources.arsc • .so files

APK File AndroidManifest.xml

classes.dex resources.arsc

.so

Permissions

Developer:

• During the development declares in the AndroidManifest.xml, which permissions are required for his application to operate properly

Example: android.permission.SEND_SMS

Owner of the phone:

• During installation is acquainted with these required permissions and decides either to grant these permissions to the application or not to grant and, thus, prohibit the installation of the application

37

Application Installation

38

3 . apk

ADB

2 . apk

Android Market

1 . apk

Package Installer

Linux Kernel

user : app _ 1 home : data / data / app _ 1

user : app _ 2 home : data / data / app _ 2

user : app _ 3 home : data / data / app _ 3

Application 2 Application 3 Application 1

Application Environment

39

Zygote

Dalvik VM Dalvik VM Dalvik VM

Application 1 Application 2

DalvikVM Sandbox Application 3

DalvikVM Sandbox DalvikVM Sandbox

Application 1 Application 2 Application 3

Application Secure Environment

Thus, by default:

• each application has access only to its own components

• applications have no access to the components of the system

• access to the components of the system and to the components of other application is gained if the application has required permissions.

40

ANDROID MANIFEST FILE

43

Android Manifest

• Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory.

• Before the Android system can start an application component, the system must know that the component exists by reading the application's AndroidManifest.xml file.

• It describes the components of the application‚ the activities, services, broadcast receivers, and content providers that the application is composed of. It names the classes that implement each of the components and publishes their capabilities .These declarations let the Android system know what the components are and under what conditions they can be launched.

44

Android Manifest

45

<manifest>

xmlns:android

• Defines the Android namespace. This attribute should always be set to "http://schemas.android.com/apk/res/android".

package

• A full Java package name for the application. The name should be unique.

• The package name serves as a unique identifier for the application. It's also the default name for the application process.

46

<manifest>

android:sharedUserId

• The name of a Linux user ID that will be shared with other applications. By default, Android assigns each application its own unique user ID.

• Signatures of the applications have to be the same.

• Application with the same user ID can access each other's data and run in the same process.

android:versionName

• The version number shown to users. This attribute can be set as a raw string or as a reference to a string resource. The string has no other purpose than to be displayed to users.

47

<permission>

• Declares a security permission that can be used to limit access to specific components or features of this or other applications.

48

<permission>

android:description

• A user-readable description of the permission, longer and more informative than the label. It may be displayed to explain the permission to the user — for example, when the user is asked whether to grant the permission to another application.

android:label

• A name for the permission.

49

<permission>

android:name

• The name of the permission. This is the name that will be used in code to refer to the permission — for example, in a <uses-permission> element and the permission attributes of application components.

• The name must be unique

android:permissionGroup

• Assigns this permission to a group. The value of this attribute is the name of the group, which must be declared with the <permission-group> element in this or another application.

50

<permission>

android:protectionLevel

• Characterizes the potential risk implied in the permission and indicates the procedure the system should follow when determining whether or not to grant the permission to an application requesting it.

• Values: “normal”, “dangerous”, “signature”, “signatureOrSystem”

51

<uses-permission>

Requests a permission that the application must be granted in order for it to operate correctly. Permissions are granted by the user when the application is installed, not while it's running.

android:name

• The name of the permission. It can be a permission defined by the application with the <permission> element, a permission defined by another application, or one of the standard system permissions, such as "android.permission.CAMERA" or "android.permission.READ_CONTACTS". As these examples show, a permission name typically includes the package name as a prefix.

52

<uses-configuration>

Indicates what hardware and software features the application requires. For example, an application might specify that it requires a physical keyboard or a particular navigation device, like a trackball. The specification is used to avoid installing the application on devices where it will not work.

53

<uses-configuration>

android:reqFiveWayNav

• Whether or not the application requires a five-way navigation control — "true" if it does, and "false" if not. A five-way control is one that can move the selection up, down, right, or left, and also provides a way of invoking the current selection. It could be a D-pad (directional pad), trackball, or other device

android:reqHardKeyboard

• Whether or not the application requires a hardware keyboard — "true" if it does, and "false" if not.

54

<uses-configuration>

android:reqKeyboardType

• The type of keyboard the application requires, if any at all. This attribute does not distinguish between hardware and software keyboards.

• Values: “undefined“, “nokeys“, “qwerty“, “twelvekey“

android:reqNavigation

• The navigation device required by the application, if any.

• Values: “undefined“, “nonav”, “dpad”, “trackball“, “wheel”

55

<uses-configuration>

android:reqTouchScreen

• The type of touch screen the application requires, if any at all.

• Values: “undefined“, “notouch“, “stylus“, “finger”

56

<uses-feature>

Declares a single hardware or software feature that is used by the application. The purpose of a <uses-feature> declaration is to inform any external entity of the set of hardware and software features on which your application depends.

Example:

• android.hardware.camera - hardware

• android.software.sip - software

android:name

• Specifies a single hardware or software feature used by the application, as a predefined string.

57

<uses-feature>

android:required

• Boolean value that indicates whether the application requires the feature specified in android:name

• When you declare "android:required="true" for a feature, you are specifying that the application cannot function, or is not designed to function, when the specified feature is not present on the device.

• When you declare "android:required="false" for a feature, it means that the application prefers to use the feature if present on the device, but that it is designed to function without the specified feature, if necessary.

• The default value for android:required if not declared is "true".

58

<uses-sdk>

Lets you express an application's compatibility with one or more versions of the Android platform, by means of an API Level integer. The API Level expressed by an application will be compared to the API Level of a given Android system, which may vary among different Android devices.

Despite its name, this element is used to specify the API Level, not the version number of the SDK (software development kit) or Android platform. The API Level is always a single integer. You cannot derive the API Level from its associated Android version number

59

<uses-sdk>

android:minSdkVersion

• An integer designating the minimum API Level required for the application to run. The Android system will prevent the user from installing the application if the system's API Level is lower than the value specified in this attribute. You should always declare this attribute.

android:targetSdkVersion

• An integer designating the API Level that the application is targetting. With this attribute set, the application says that it is able to run on older versions (down to minSdkVersion), but was explicitly tested to work with the version specified here.

60

<uses-sdk>

android:maxSdkVersion

• An integer designating the maximum API Level on which the application is designed to run.

• Now this parameter is only used to filter the applications in the Android Market

61

<application>

The declaration of the application. This element contains subelements that declare each of the application's components and has attributes that can affect all the components. Many of these attributes (such as icon, label, permission, process, taskAffinity, and allowTaskReparenting) set default values for corresponding attributes of the component elements. Others (such as debuggable, enabled, description, and allowClearUserData) set values for the application as a whole and cannot be overridden by the components.

62

<application>

android:debuggable

• Whether or not the application can be debugged, even when running on a device in user mode — "true" if it can be, and "false" if not. The default value is "false".

android:description

• User-readable text about the application, longer and more descriptive than the application label.

• The value must be set as a reference to a string resource. 63

<application>

android:icon

• An icon for the application as whole, and the default icon for each of the application's components: for <activity>, <activity-alias>, <service>, <receiver>, and <provider> elements.

• This attribute must be set as a reference to a drawable resource containing the image.

• There is no default icon.

64

<application>

android:label

• A user-readable label for the application as a whole, and a default label for each of the application's components. See the individual label attributes for <activity>, <activity-alias>, <service>, <receiver>, and <provider> elements.

android:permission

• The name of a permission that clients must have in order to interact with the application. This attribute is a convenient way to set a permission that applies to all of the application's components. It can be overwritten by setting the permission attributes of individual components.

65

References

1. www.android.com

2. http://developer.android.com/

3. http://www.vogella.de/articles/Android/article.html

4. http://blog.javia.org/android-package-name/

5. http://mobiforge.com/developing/story/getting-started-with-android-development

6. http://mobiforge.com/designing/story/understanding-user-interface-android-part-1-layouts

7. http://mobiforge.com/designing/story/understanding-user-interface-android-part-2-views

8. http://www.javapassion.com/portal/images/pdf_files/android/android_intent.pdf

9. http://mylifewithandroid.blogspot.com/2007/12/playing-with-intents.html

10. http://www.vogella.de/articles/AndroidIntent/article.html

11. William Enck, Damien Octeau, Patrick McDaniel, Swarat Chaudhuri, A Study of Android Application Security, USENIX 2011

66

ANDROID SECURITY EXTENSIONS

67

Security and Privacy Issues

• Malware, (in the first half of 2011, malware contaminated app grew from 80 to 400 (Android Marketplace). – Update Attack: clean apps that as grow in popularity are updated

with malware

• Too coarse-grained permissions • Privilege Escalation

Extending Existing Security: Why?

• “All or nothing” model

Weather App…

with an attitude

Uses (necessary) Permissions:

• Location

• Internet

But also (the unnecessary):

• Call History

• SMS

• Contacts

only to the server

only with 50 miles precision

NO SCOPE

Extending Existing Security: Why?

• Confused deputy attack: leverage the vulnerability of a benign application

• Colluding attacks: more applications collaborate to get an objectionable set of permissions

Privilege Escalation Attacks

YAASE: Yet Another Android Security Extension

A Policy-based System for

• Permission filtering

• Fine-grained Data Filtering and Shadowing

• Prevent Privilege Escalation Attack (IFC)

• No modifications to Android API or existing Apps

• (Remotely) reconfigurable

• Dynamic

YAASE Main Features

App

DVM

TaintDroid

Settings Provider

Socket/OSFileSystem

Policy Provider

Action Library

Labelling Store

PEP

Location Provider

Account Provider

PEP

Lib

Bin

bd

er

PDP

Internet Logs

Camera

Storage

JFL

User Settings Interface

Content Provider

App Installer

YAASE Architecture

PolicyName:

Requester can do operation on Resource

[have to perform action]

handle dataLabelExpression

YAASE Policy Language

OrganizerApp:

OrganizerApp can do getContacts on Contacts have to perform FilterOut(“Pr”, returnData);

handle “Pub” and “Contact”

Policy 1 for OrganizerApp

App

DVM

TaintDroid

Settings Provider

Socket/OSFileSystem

Policy Provider

Action Library

Labelling Store

PEP

Location Provider

Account Provider

PEP

Lib

Bin

bd

er

PDP

Internet Logs

Camera

Storage

JFL

User Settings Interface

Content Provider

App Installer

YAASE Architecture

• Modello completamente dinamico

CRêPE: Context-based Access Control

• Supporto di contesti

• Politiche associate ai contesti

• Rilevazione automatica e dinamica di contesti attivi/disattivi

• Gestione dinamica dei contesti e delle politiche anche da remoto e anche da terze parti (autorizzate)

CRêPE: Context-related Policy Enforcement

• Context-related policies possibly with a system scope

• Specified by

– Users

– Trusted Third Party (i.e. Developer, Government, Employer, Device manufacturer, Network Operator, etc.)

• Dynamically specified and enforced

77 B. Crispo - ISC 2010 – 25 Oct. 2010

CRêPE Definitions

• Context: defined by condition(s) on attributes. A context is active if the condition is verified

• Policy: How the phone acts in the context. Set of rules

• Rule: <resource, effect> – Allowed/Denied

– Start/Stop

• Resource – Phone functionalities (e.g. Bluetooth, Camera, WiFi, etc.)

– Applications, components

B. Crispo - ISC 2010 – 25 Oct. 2010 78

CRêPE Policy Conflicts Resolution

• Conflicting rules on the same context

• Labels and MAC to regulate policy/rule priority

• Labels relations: L1 > L2 > L3 – L1 = Government

– L2 = Trusted Party, Government

– L3 = User, Trusted Party, Government

• Conservative approach: – Denied > Allowed

– Deny as default

B. Crispo - ISC 2010 – 25 Oct. 2010 79

CRêPE Architecture

B. Crispo - ISC 2010 – 25 Oct. 2010 80

An

dro

id M

idd

lew

are

Linux Kernel

Applications

Android ICC Reference Monitor

CRêPE

App Z

CRePE Permission

Checker

Policy Provider

Policy Manager

Context Detector

Action Executor

Trusted Party Interface

Admin Interface

Native Permission

Checker

OrganizerApp:

OrganizerApp can do send

on Internet have to perform sendOnlyTo(myBackUpServerUrl);

handle “Pub” and “Contact”

Policy 2 for OrganizerApp

• MOSES: Supporting Operation Modes on Smartphones , Giovanni Russello, Mauro Conti, Bruno Crispo and Earlence Fernandes in The Seventeenth ACM Symposium on Access Control Models and Technologies. (ACM SACMAT 2012) to appear.

• "CRePE: Context-Related Policy Enforcement for Android" -, M. Conti, V. T. N. Nguyen, B. Crispo 13th International Security Conference: ISC 2010, Lecture Notes in Computer Science 6531 Springer 2011, ISBN 978-3-642-18177-1, pp. 331-345

• “Mind how you answer me!: transparently authenticating the user of a smartphone when answering or placing a call.” Mauro Conti, Irina Zachia-Zlatea, Bruno Crispo ASIACCS 2011: 249-259

• “YAASE: Yet Another Android Security Extension”, Giovanni Russello, Bruno Crispo, Earlence Fernandes, Yuri Zhauniarovich SocialCom/PASSAT 2011: 1033-1040

• Extending the Java Virtual Machine to Enforce Fine-Grained Security Policies in Mobile Devices , Iulia Ion, Boris Dragovic, Bruno Crispo:. ACSAC 2007: 233-242

References