Download intents

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 interprocess 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 systemwide 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 InterApplication
• 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 selfsigned
• 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