Android Security - Kennesaw State Universityksuweb.kennesaw.edu/.../Slides/12AndroidSecurity.pdf · Configurations of Android applications • The AndroidManifest.xmlfile is the configuration

Android Security

Security Philosophy

• Humans have difficulty understanding risk

• Safer to assume that– Most developers do not understand security– Most users do not understand security

• Security philosophy cornerstones– Need to prevent security breaches from occurring– Need to minimize the impact of a security breach– Need to detect vulnerabilities and security breaches– Need to react to vulnerabilities and security breaches swiftly

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 (IPC)• System-built and user-defined permissions • Application signing

Android Software Stack

Android software stack

• Each component assumes all supporting components below are properly secured.

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

• Linux kernel is responsible for app sandboxing

• 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 ContentProvider and ContentResolver

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

• The developer of that application has ensured that it will not do anything the phone’s user didn’t intend

• Application A is not allowed to do something malicious like 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 filesystem encryption.

Encryption

• Encryption

Android 3.0+ provides full filesystem encryption, so all user data can be encrypted in the kernel The encryption key is protected by using a key derived from the user password, preventing unauthorized access to stored data without the user device password.

• 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 SecurityApplication framework

• Almost all Android applications are written in the Java and run in the Dalvik virtual machine. Android application deployed in .apk a single file.

• Android middleware is base 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 isolations is enforced.

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

Configurations of Android applications

• The AndroidManifest.xml file is the configuration file of the 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 Permission Model

• Applications have no permissions by default– Permissions list: Manifest.permission

• Applications declare the permissions they require– Android system prompts the user for consent at the time the

application is installed

– in AndroidManifest.xml, add one or more <uses-permission>tags• e.g., <uses-permission android:name=

"android.permission.RECEIVE_SMS" />

– granting permissions in the code

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 install time and can’t change until the application is reinstalled.

• Android’s permission only restricts components to access 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.

Component A’s ability to access components B and C is determined by comparing the access permission labels on B and C to the collection of labels assigned to application where A is in.

3. Secure coding in Android’s Inter-Application

• If Sender does not correctly specify recipient

– Attacker can intercept the message

• If Component does not restrict from whom it can receive messages

– Attacker can inject code

A B

C

IPC - Intents

• Link applications and form the foundation of the message passing system

• Are messages containing a recipient and data (optional)

• Used for intra- and inter-app communication and system-wide notifications (system broadcast Intents)

• Are divided into explicit and implicit– Explicit: specifies a definite application

– Implicit: specifies a kind or categories

• Are delivered to components

IPC - Components

• Activities– Started with intents– Can return data– All UI is defined in an activity

• Services– Started with intents– Background; no UI– Other components bind to

• Allows binder to invoke service’s methods (must be declared in the interface)

• Broadcast receivers (3 types)– Work on intents, which may be sent to multiple apps– Background; no UI– Normal – sent to all registered receivers at once– Ordered – sent to receivers in order; any app can halt progression of message; apps can set

their own priority level– Sticky – remain accessible after initial delivery; available to be re-broadcast to future (new)

receivers

• Content providers– Databases addressable by an URI– Used for internal (app’s own) data needs– Can be used to share data between apps

IPC - Components

• 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

IPC – Exporting Components

• Public components can receive Intents from other apps• Is public (exported) if either:

– EXPORTED flag is set– At least one Intent filter

• Intent can contain– Component name, an action, data, a category, extra data

• Intent filter constrains incoming Intents by– Action: a general operation to be performed– Data: specifies the type of data– Category: additional information about the action

• No rule against multiple applications specifying the same Intent filter

• Intent filters ARE NOT a security mechanism

IPC - Permissions

• Caller must have a certain permission

• Core system API does

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

• Can specify a protection level

IPC – Protection Levels

• Normal– Granted automatically

• Dangerous– Granted during installation. If user does not accept, installation fails.

• Signature– 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 meet the Signature requirement OR if installed in the

system application folder– Market apps cannot install into the system app folder– Device manufacturers or end-users can manually install into the

system app folder

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 hijacking, 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– Risk when app sends public broadcast– Can listen to all public broadcasts by creating a

“wide” intent filter– No user feedback to sender that broadcast has been

read

• Denial of Service– Ordered broadcast vulnerable– Attacker sets priority to highest level– Can cancel broadcast– Can inject malicious code or data

• After all broadcast receivers receive the data, it is sent back to the initial sender

Alice

Eve

Carol

Bob

Alice

Eve

Carol

Bob

Eavesdropping

Denial of Service

Type 1 – Activity Highjacking

• Malicious Activity launched in place of desired Activity– Either used as an irritation or phishing

• If multiple Activities have the same Intent filter, then user is notified to select the correct Activity.

• If highjacking is successful, a False Response attack may then happen– The attacker may return malicious code

or data to the user

Activity/Service Highjacking

Alice Bob

Eve

Alice Bob

Eve

False Response

Type 1 – Service Highjacking

• Malicious Service bound to in place ofdesired Service– Can steal data, lie about tasks

• If multiple Services have the same Intent filter, Android selects one at random!

• If highjacking is successful, a False Response attack may then happen– The attacker may return malicious code

or data to the user

Activity/Service Highjacking

Alice Bob

Eve

Alice Bob

Eve

False Response

Type 2 – Malicious Broadcast Injection

• Blindly trusts an incoming Broadcast

• Broadcast receivers most vulnerable when register to receive system actions, which makes the component public– Can be explicitly called

– Will fall for malicious broadcast if Service doesn’t check the Intent’s action• It should contain an action string that only

the system can add

Intent Spoofing

Alice Eve

Type 2 – Malicious Activity Launch

• Exported Activities can be launched by Intents (explicit or implicit)

• Launching an Activity can cause three types of attacks– Affect state, modify data– Trick the user into thinking they are

changing settings in Malicious Activity, but are really changing settings in the victim Activity

– Leak information by returning a result to the malicious code

Intent Spoofing

Alice Eve

Type 3 – Malicious Service Launch

• Exported Services can be started and bound to

• A malicious Service launch is similar to a malicious Activity lanuch

• Since Services relay on input data, there a greater chance to put the Service at risk

Intent Spoofing

Alice Eve

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• Intent filters are not security measures

Android developers should securing user data and avoiding the introduction of security vulnerabilities. Always assign a least permision 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(Multimedia Message Service )• 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.

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

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

Android App Signature• All Android applications must be signed, but are usually self-signed• Why self signing?

– Market ties identity to developer account– CAs have had major problems with fidelity in the past– No applications are trusted. No "magic key"

• What does signing determine?– Shared UID for shared keys– Self-updates– proves no relationship with Google does 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.

• 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 shows the authorship and trust for application

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

Signature

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 (Global System for Mobile Communication) 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

– Practice known as bluesnarfing