Android Security Architecture

tearfuloilMobile - Wireless

Dec 10, 2013 (3 years and 7 months ago)

80 views

Android Security Architecture

Security goals


Protect user data


Protect system resources (hardware, software)


Provide application isolation


Foundations

of

Android

Security




Application

Isolation

and

Permission Requirement


Mandatory application sandbox for all applications


Secure inter
-
process communication


System
-
built and user
-
defined permissions


Application signing

Android software stack


Each component assumes that the components below
are properly secured.


All code above the Linux Kernel is restricted by the
Application Sandbox


Linux

kernel

is

responsible sandboxing application


“mutually distrusting principals”


Default access to only its own data


The

app Sandbox

apps

can

talk

to other

apps

only
via


Intents (message) , IPC, and ContentProviders


To

escape sandbox,


permissions is needed


1. Security at the Linux kernel


A user
-
based permissions model


Process isolation: Each application has its sandbox
based on separation of processes: to protect user
resources from each another; each runs in its own Linux
process to secure Inter
-
Process communication (IPC)

Ex:


Prevents user A from reading user B's files


Ensures that user A does not access user B's CPU,
memory resources


Ensures that user A does not access user B's devices
(e.g. telephony, GPS, Bluetooth)


Application Sandbox



The Android system assigns a unique user ID (UID) to
each Android application and runs it as that user in a
separate process.


When launching a new
Activity
, the new process isn’t
going to run as the launcher but with its own identity with
the permission specified by the developer.


The developer of that application has ensured that it will
not do anything the phone’s user didn’t intend. Any
program can ask Activity Manager to launch almost any
other application, which runs with that application’s UID.


Ex. application A is not allowed to do something
malicious like to read application B's data or dial the
phone without permission.


All libraries, application runtime, and all applications run
within the Application Sandbox in the kernel.


Permissions and Encryption




Permissions



In Android, each application runs as its own
user. Unless the developer explicitly exposes
files to other applications, files created by one
application cannot be read or altered by another
application.


Password Protection


Android can require a user
-
supplied password
prior to providing access to a device. In addition
to preventing unauthorized use of the device,
this password protects the cryptographic key for
full file system encryption.

Encryption




Encryption



Android 3.0+ provides full filesystem encryption,
so all user data can be encrypted in the kernel



For a lost or stolen device, full filesystem
encryption on Android devices uses the device
password to protect the encryption key, so
modifying the bootloader or operating system is
not sufficient to access user data without the
user’s device password.

2. Android Application Security

(Application framework)


Almost all Android applications are written in the Java
and run in the Dalvik virtual machine. However,
applications can also be written in native code.


.java
-
> .class
-
> .jar
-
> .dex


Android application deployed in a single .apk file.


Android middleware is based on the Linux kernel. It
provides several native libraries and a Dalvik virtual
machine (DVM) instead of Java virtual machine (JVM)
for its applications’ runtime environment where
application isolation is enforced.


The Java written Android middleware provides
development APIs, the system service, all basic phone
device functionalities

Configurations of Android applications




The AndroidManifest.xml file is the configuration file of
Android application.


It specifies the components in the application and
external libraries it uses.


It tells the system what to do with activities, services,
broadcast receivers, and content providers in an
application.


It declares permissions it requests as well as
permissions that are defined to protect its own
components. The client must be granted such
permission in order to run the application.


Without user’s consent application will not be
installed



Android Security Basics
-

Android Manifest


Applications have no permission required by default


Each application can declare the requiRED permissions



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


Android Permission Model


Permissions are the core concepts in the Android
security to control the access from one application
component to another.


All permissions are set at installation time and can’t
change until the application is reinstalled.


Android’s permission only restricts components


from accessing resources


E.g. an application needs the READ_CONTACTS
permission to read the user’s address book


If a public component doesn’t explicitly declare any
access permission, Android permits any application to
access it.


All sensitive APIs listed below are intended for use by trusted
applications and protected through Permissions such as functions
for camera, bluetooth, telephony, SMS/MMS, network connections


All permissions are granted at install
-
time.


In order to be granted a permission, it should be requested in the
Android manifest file when specifying properties for an application,
system then evaluates it and makes a final decision on whether to
grant or deny.


After the application has been launched, permission checks are
enforced before the actual access take place.


If the user continues the installation, the system grants all requested
permissions. The user can not grant or deny partial permissions
afterwards.



More than 60 system built
-
in permissions defined in the form of
android.Manifest.permission.X, where X is the name of a particular
permission.


The system default permissions are described at
https://developer.android.com/reference/android/Manifest.permissio
n.html
.




Create app’s own permissions (called
dynamic
permissions

in Android) through permission declaration
in AndroidManifest.xml.


permission declaration <
permission>

is the place where
developers are able to define their own permissions for
protecting their application
-
specific APIs or components.


The name of permission needs to be globally unique and
descriptive so that other components are able to know
and request it by name.


<use
-
permission>

lets the developer to request a
permission so they get access to certain functionalities in
the system. It could either be a built
-
in permission or a
dynamic permission. All permissions should be
requested explicitly.


Once granted, the permissions are applied to the
application as long as it is installed. Permissions are
removed if an application is uninstalled, so a subsequent
re
-
installation will start over again permission request.


Users are able to view permissions and can also turn off
some functionality globally when they choose, such as
disabling GPS, Radio, or, SMS, Wi
-
Fi.

Built
-
in Permission


Default

Android

Permissions

Policy:

No

app

can

do

anything

to
adversely

Install/uninstall/modify

other

apps,
use

other

apps

private

components, access

network,
users

data

(contacts,

SMS,

email),




use

cost
sensitive

APIs

(phone

calls,

send

SMS, …)





Built
-
in

Android

Permissions




CALL_PHONE,

CAMERA,


INTERNET,

READ_CONTACTS,


READ_LOGS,

READ_SMS,

RECEIVE_SMS,

R SEND_SMS,
WRITE_SMS





Caller must have a certain permission


e.g., <uses
-
permission
android:name="android.permission.CALL_PHONE">


</uses
-
permission>


The protection level From weak to strong:

Normal


Normal permissions are the default setting If the
protection level is not specified, providing the weakest
protections.


They are often used to protect less security
-
critical
functionalities. the permission is assumed to be normal.
When a normal permission is requested, the system
grants it without asking users.


Dangerous


Permissions at this level might ask for accessing the
user privacy or certain hardware service. An example for
dangerous permissions is asking for accessing some
functionalities cost money.


When an application requests a dangerous permission,
the system shows the permission information in a screen
to users and users need to accept all permissions if they
want to install the application on their phones.


Granted during installation, requires user approval


Signature


Decided by the system without the users’
involvement. To be granted a signature
permission, the requesting application must be
signed by the same key as the application that
the permission protects.


Granted only if requesting app is signed by the
same

developer that defined the permission


Useful for restricting component access to those
apps under the control of the same developer

SignatureOrSystem


Granted if requesting app meets the Signature
requirement OR if app is installed in the system
application folder


3. Security for Inter
-
Process
Communication




In addition to any Linux
-
type process communication
mechanisms such as file system, local sockets, signals
Android provides new IPC mechanisms:

3.1 Binder


Remote procedure call( RPC) mechanism (Remote method
invocation) designed for in
-
process and cross
-
process
calls.
https://developer.android.com/reference/android/os/Bind
er.html
.

Secured by caller permission or identity check.


Cont.


AIDL (Android Interface Definition Language) is
an IDL language used to generate code that
enables two processes on an


Android
-
powered device to talk using inter
-
process communication (IPC).


Ex. an Activity needs to call methods on an
object in another process (for example, a
service), you would use AIDL to generate code
to marshall the parameters.


The AIDL IPC mechanism is interface
-
based,
similar to COM or CORBA, but lighter weight. It
uses a proxy class to pass values between the
components

3.2. Intents



An Intent is a simple notification message object that
represents an "intention" to do something.


It is serialized when it is sent. The message consists of
the data together with the action operation that will be
performed.


Intent filters are used to filter out unwanted intents so
that users are informed by interested ones only.


For example, if your application wants to display a web
page, it expresses its "Intent" to view the URL by
creating an Intent instance and handing it off to the
system. The system locates the Browser that knows how
to handle that Intent, and runs it; or to broadcast
interesting events (such as a notification) system
-
wide.




Cont.


Intent: notification from one process to another


directed intent: has one specific recipient



broadcast intent: can be received by anyone



intent filter: a list of intents an activity/service is


interested in

for example, a application wants to make a phone call:


Intent myCallIntent = new


Intent(Intent.Action_CALL);


myCallIntent.setData(Uri.parse(“tel:123456789”);


startActivity(myCallIntent);



Cont.


“Three of the core components of an application


activities, services, and broadcast receivers


are
activated through messages, called
intents
. Intent
messaging is a facility for late run
-
time binding between
components in the same or different applications.”


“The Android system finds the appropriate activity,
service, or set of broadcast receivers to respond to the
intent, instantiating them if necessary”.


Cont.


Broadcast intents are delivered only to broadcast
receivers, never to activities or services. An intent
passed to startActivity() is delivered only to an activity
never to a service or broadcast receiver,


Intent messages contain a recipient and data (optional)
which Link applications and form the foundation of the
message passing system


Used for intra
-

and inter
-
app communication and system
-
wide notifications (
system broadcast Intents
)


Are divided to
explicit
and
implicit
components


Explicit: specifies a definite application


Implicit: specifies a kind or categories


Intent action constant



ACTION_CALL to Activity: Initiate a phone call


ACTION_EDIT to Activity: Display data for the user to
edit


ACTION_MAIN to Activity: Start of a task


ACTION_BATTE RY_LOW to Broadcast receiver: A
warning on low battery

Intent in IPC


Activities, Services, and Broadcast Receivers can
send/receive 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 manifest


By default, components can only receive internal
Intents


Asynchronous comm.


Not secured on the carried data



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 filters intents of a desired type, while filtering
out unwanted intents


Activity with intent filter enabled is “exported” out


3.3 Security Risks in Android’s Inter
-
Application


Attacker can intercept the message If sender does not
correctly specify recipient,


can hijack activity, service, broadcast via intent to lead to
a malicious target


Attacker can inject code If Component does not restrict
from whom it can receive messages


Attacks


Only consider attacks on exported components


Consider non
-
exported components and exported
components with a Signature (or higher) permission
level to be private and not susceptible to the below
attacks


Type 1
-

Intents sent to the wrong application


Can leak data


Broadcast theft, activity and service hijacking


Type 2


Receiving external Intents


Data corruption, code injection


Malicious broadcast injection, malicious activity
launch, malicious service launch

Type 1


Broadcast Theft


Broadcasts (via implicit Intent) vulnerable to eavesdropping
and denial of service attacks


Eavesdropping


A public broadcast can be intercepted by attacker because a
loose intent filter leaves a hole and no confirmation checking












Denial of Service


Ordered broadcast vulnerable


Attacker resets its priority to highest level to alter the
broadcast receiving order which can cancer or inject
malicious code or data

Type 1


Activity and Service Highjacking


Malicious a/service is activated instead of
desired components such as by Phishing









Android will select a best matched one If
multiple activities have the same Intent
filter spec so that The attacker may return
malicious code or data to the user


Type 2


Malicious Injection

Activity


A malicious activities can be activated by Intents
(explicit or implicit) as results of injection


tamper data or Leak sensitive information

Broadcast


Broadcast receivers registers with a malicious
broadcast provider and take system action

to
make itself open to public


An system action string that only the system can
add may be injected



Some Recommendations


Use caution with implicit Intents and exporting
Components


Use explicit Intents to send private data


Use explicit Intents for internal communication


Returned results should be checked for authenticity


Avoid exporting Components


The same Component should not handle both internal
and external Intents

Android developers should securing user data and avoiding
the introduction of security vulnerabilities. Always assign
a least permission to a application

Cost
-
Sensitive APIs


A cost sensitive API is any function that might generate a
cost for the user or the network. The Android platform
has placed cost sensitive APIs in the list of protected
APIs controlled by the OS. The user will have to grant
explicit permission to third
-
party applications requesting
use of cost sensitive APIs for SIM Card Access, Device
Metadata, Sensitive Data via Input Devices or Personal
Information


These APIs include:


Telephony


SMS/MMS


Network/Data


In
-
App Billing


4. Application Signing



Code signing allows developers to identify the author of
the application and to update their application without
creating complicated interfaces and permissions.


Every application that is run on the Android must be
signed by the developer.


Applications that attempt to install without being signed
will rejected by either Google Play or the package
installer on the Android device
.


On Android, application signing is the first step to placing
an application in its Application Sandbox. The signed
application certificate defines which user id is associated
with which application; different applications run under
different user IDs.


Application signing ensures that one application cannot
access any other application except through well
-
defined
IPC.


When an application (APK file) is installed onto an
Android device, the Package Manager verifies that the
APK has been properly signed with the certificate
included in that APK.


If the certificate (or, more accurately, the public key in
the certificate) matches the key used to sign any other
APK on the device, the new APK has the option to
specify in the manifest that it will share a UID with the
other similarly
-
signed APKs.


Android requires every application to be signed. The
main purpose of application signing is to distinguish
applications from one to another.


Developers sign apps with their own private keys. The
private keys are supposed to stay secret and known only
to their owners.


After a signed application is installed on the phone, the
system is able to use its signature information to
distinguish it from other application.

Signature protection level


Signature shows app persistence:


Check: app is changed or updated with diff sig.


Signature shows the authorship and trust for application


All Android applications must be signed, but are
self
-
signed


Why self signing? Market ties identity to developer
account


No applications are trusted.



Android App Signature



What does signing determine?


Shared UID for shared keys


Self
-
updates

Google doest not have central control over the app’s
signature certificates


creates chain of trust between updates and among
applications


In signature schemes, the private key is used to sign
a app or message; anyone can check the signature
using the public key.

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.


SMS Vulnerabilities


SMS


Short Messaging System


Very commonly used protocol


Used to send "Text Messages"


GSM uses 2 signal bands, 1 for "control", the other for
"data".


SMS operates entirely on the "control" band.


High volume text messaging can disable the "control"
band, which also disables voice calls.


Can render entire city 911 services unresponsive.

Bluetooth Vulnerabilities


Bluetooth


Short range wireless communication protocol


Used in many personal electronic devices


Requires no authentication


An attack, if close enough, could take over
Bluetooth device.


Attack would have access to all data on the
Bluetooth enabled device, bluesnarfing

Information Misuse by Apps


Phone identifiers: phone number, IMEI (device identifier),
IMSI (subscriber identifier), and ICC
-
ID (SIM card serial
number).


Phone identifiers are frequently leaked through
plaintext requests.


Phone identifiers are used as device fingerprints.


Phone identifiers, specially the IMEI, are used to
track individual users.


Phone identifiers are sent to advertisement and
analytics servers.

Reference


Android Security,
CEG436: Mobile Computing



Prabhaker Mateti


Android Security Overview,
source.android. com/tech/security/


Nils, “Building Android Sandcastles in Android’s Sandbox,” Oct
2010, BlackHat


William Enck, Damien Octeau, Patrick McDaniel, and Swarat
Chaudhuri, “A Study of Android Application Security”, 20th USENIX
Security, Aug 2011


Android Security Overview


http://source.android.com/tech/security/index.html


“Analyzing Inter
-
Application Communication in Android” by Chin,
Felt, Greenwood, and Wagner (UC Berkeley)


http://www.comdroid.org/


Donald E Frederick,
Android’s Inter
-
Application Model and Security
Risks,
8/20/2012