Android Security

Understanding Android Understanding Android SecuritySecurity

Suminda Gunawardhana

I. IntroductionII. Android ArchitectureIII. Android SecurityIV. Android ApplicationsV. Security EnforcementVI. Security RefinementsVII. Lessons in Defining PolicyVIII. Google Newly release Security FeatureIX. Development process Best practices X. Hybrid Mobile App’ Data store security

OutlineOutline

IntroductionIntroduction• Android is a Linux-based open-source operating

system by Google for mobile devices such assmart phones and tablets.

• Android owns 84.6% share of global smart phone market by Q2, 2014 after being launched in 2007.

• Developers can develop free or paid apps for Android using Android SDK.

• Developers can use public APIs, without having any knowledge of Android internals, to make use of device features and services provided by Android.

IntroductionIntroduction• Android has employed various

mechanisms like application sandboxing, application signing, permission model, etc. to enhance the security in Android.

• Android protects system features (accessed using APIs) by assigning them permissions.

Android ArchitectureAndroid Architecture

Android ArchitectureAndroid Architecture Activity

Activity is a screen or window (UI) which is displayed to the user for interaction purpose. Only one activity has a focus at a time. An application can have many activities used to implement different functionalities (UIs). One activity may start another activity and wait for that activity to finish to get back the result.

Android ArchitectureAndroid Architecture Service• Service is equivalent to background process which is

invisible to the user. • Other components can bind to the service and get

the result back using remote procedure call

(RPC) mechanism.

Android ArchitectureAndroid Architecture Content Provider• Content Providers can perform sql-like operations,

e.g. SELECT, UPDATE, DELETE, INSERT on the underlying sqlite databases.

• Content Provider can define two permissions labels to protect read and write access separately.

Android ArchitectureAndroid Architecture Broadcast Receiver• A Broadcast Receiver component is an

asynchronous event mailbox for Intent messages ‘broadcasted’ to an action string .• Application developers can add broadcast

receiver in their applications to receive events occurring at system-level. • Applications can also create broadcast

receivers at runtime (that do not appear in manifest file), called as dynamic Broadcast Receiver.

Android SecurityAndroid Security

Application Sandboxing• Every application gets a unique user identifier (UID)

at the time of installation. • Linux kernel is responsible for enforcing access

control on the resources of the system. • Hence, one application cannot access other

application’s files unless they are marked as world-wide readable.

• Also, every application is run into separate VMs. It implies that the vulnerability found in one applicationwill not affect remaining applications.


Application Signing• Android requires every application to be

signed, not necessarily from third party certificate authority. • Application developers can sign their own

applications. ◦ This allows Android to build trust

relationships among applications from same developer.


Application Signing• If two applications are signed using same

certificate and they ask for same shared UID, then either of the application can use permissions granted to other application.


Permission Model• The permissions model is based on

permissions, which are constructs that various APIs require calling apps to have before they will provide certain services.• Applications must declare (in their manifest)

which permissions they request/require. When an application is installed, the Android system will present this list to the user and the user must decide to allow the installation or not.


Permission Model• This is an all-or-nothing decision; the user can

install the app or not, but cannot choose to install it with reduced permissions.• This imparts a significant responsibility to

both the developer (to accurately specify required permissions) and the user

(to understand the risk involved and make an informed decision).


Permission Model• The Android permissions model was designed

with two fundamental goals.• 1.Inform the User – By listing all “sensitive”

operations that an application could perform, the user is more aware of the risks involved in installing the application.

This assumes that the user will actually read the permission dialog and make a rationale yes/no install decision based on that information, which may or may not be true.


Permission Model2.Mitigate Exploits – By limiting application access

to sensitive APIs, the ability of an attacker to cause damage if an application is successfully exploited is somewhat mitigated.

• Most system permissions are all-or-nothing, by design. For example, an app gets unlimited Internet access or none at all.


Specifying Required Permissions.• Making use of a system API that requires a

permission simply requires you to specify that permission in your application’s manifest (AndroidManifest.xml).• For example, if you application needs access

to the Internet, specify the INTERNET permission.


Specifying Required Permissions.<manifest xmlns:android=“http://schemas.android.com/apk/res/android”

package=“com.example.testapps.test1”>…<uses-permission

android:name=“android.permission.INTERNET” />…</manifest>


Permission Levels• Normal – These permissions cannot impart real harm

to the user (e.g. change the wallpaper) and, while apps need to request them, they are automatically granted.

• Dangerous – These can impart real harm (e.g. call numbers, open Internet connections, etc) and apps need to request them with user confirmation.

• Signature – These are automatically granted to a requesting app if that app is signed by the same certificate (so, developed by the same entity) as that which declared/created the permission. This level is designed to allow apps that are part of a suite, or otherwise related, to share data.


Permission Levels Signature/System – Same as Signature, except that

the system image gets the permissions automatically as well. This is designed for use by device manufacturers only.


Custom Permissions• Custom permissions can be used by developers to

restrict access to various services/components.• Any application that interacts with another application’s

component would need to possess the required permission for the call to succeed.

• First, a permission must be declared/created in an application’s manifest.


Custom Permissions<permission

android:name=“com.example.perm.READ_INCOMING_MSG”

android:label=“Read incoming messages from the EX service.”

android:description=“Allows the app to access any messages received by

the EX service. Any app granted this permission will be able to read all

messages processed by the ex1 application.”android.protectionLevel=“dangerous”

android:permissionGroup=“android.permission-group.PERSONAL_INFO”

/>


Enforcing Permissions Programmatically • Applications can check to see if calling apps have permissions

programmatically.

int canProcess = checkCallingPermission( “com.example.perm.READ_INCOMING_MSG”);

If(canProcess != PERMISSION_GRANTED) throw new SecurityException();

• This will ensure that the calling process (via IPC) has the necessary permission. There are other forms of this call that can check to see if a specific PID/UID combination has a certain permission or if a specific package has that permission.

Android Applications --- ExampleAndroid Applications --- Example

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

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 Android Applications --- Example Application(cont.)Application(cont.)

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 Android Applications--- Component InteractionInteraction• 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 Android Applications--- Component Interaction (cont.)Interaction (cont.)

Example: Interaction between components in applications and with components in system applications. Interactions occur primarily at the component level.

Android Applications--- Component Android Applications--- Component Interaction (cont.)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 EnforcementSecurity EnforcementAndroid protect application at system level and

at the Inter-component communication (ICC) level.

Each application runs as a unique useridentity, which lets Android limit the potential damage of programming flaws.

Security Enforcement (cont.)Security Enforcement (cont.)

Example: Protection. Security enforcement in Android occurs in two places: each application executes as its own user identity, allowing the underlying Linux system to provide system-level isolation; and the Android middleware contains a reference monitor that mediates the establishment of inter-component communication (ICC).

Security Enforcement (cont.)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.

Security Enforcement (cont.)Security Enforcement (cont.)

Example: Access permission logic. The Android middleware implements a reference monitor providing mandatory access control (MAC) enforcement about how applications access components. The basic enforcement model is the same for all component types. 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 1.

Security Enforcement - ConclusionSecurity Enforcement - ConclusionAssigning permission labels to an application

specifies its protection domain. Assigning permissions to the components in an applicationspecifies 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. Security Refinements --- Public vs. Private ComponentsPrivate ComponentsApplications 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 Security Refinements --- Implicitly Open ComponentsOpen ComponentsAt 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 Security Refinements --- Broadcast Intent PermissionsIntent PermissionsSending 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 Security Refinements --- Content Provider PermissionsProvider PermissionsIf 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.

Security Refinements --- Protected Security Refinements --- Protected APIsAPIsNot all system resources(for example,

network) are accessed through components—instead, Android provides direct API access.

Android protects these sensitive APIs with additional permission label checks: an application must declare a correspondingpermission label in its manifest file to use them.

Security Refinements --- PermissionSecurity Refinements --- PermissionProtection LevelsProtection LevelsThe permission protection levels provide a

means of controlling how developers assign permission labels.

Signature permissions ensure that only the framework developer can use the specific functionality (only Google applications can directly interface the telephony API, forexample).

Security Refinements --- Pending Security Refinements --- Pending IntentsIntentsPending intent - a developer defines an intent

object to perform an action. However, instead of performing the action, the developer passes the intent to a special method that creates a PendingIntent object corresponding to the desired action.

The PendingIntent object is simply a reference pointer that can pass to another application.

Pending intents allow applications included with the framework to integrate better with third-party applications.

Lessons in Defining PolicyLessons in Defining Policy

Android security policy begins with a relatively easy-to-understand MAC enforcement model, but the number and subtlety of refinements make it difficult to discover an application’s policy.

The label itself is merely a text string, but its assignment to an application provides access to potentially limitless resources.

Google Newly release Security Google Newly release Security FeatureFeatureAndroid sandbox reinforced with

SELinux◦ Android 4.3 now includes SELinux, a

mandatory access control (MAC) system in the Linux kernel to augment the Unique Identification Number (UID) based application sandbox. ◦ This makes almost all apps with the Android

sandbox much more secure

Google Newly release Security Google Newly release Security FeatureFeature◦ Some users are wary of SELinux, since the

NSA had a large hand in creating it . Since SELinux, just like all of Linux, is open source. After all, the code is right in plain sight for anyone to look for security holes.

Google Newly release Security Google Newly release Security FeatureFeatureKeyChain enhancements◦ If you're still worried about the NSA

snooping on your messages you'll be happy to see Google's new KeyChain API provides a method that enables applications to confirm that system-wide keys are bound to a hardware root of trust. ◦ This means that carrier and OEM developers

can add private keys that cannot be copied off the device, even if it's otherwise completely compromised.

Google Newly release Security Google Newly release Security FeatureFeature◦ This won't stop the NSA -- or most major

Internet companies -- from using big data, metadata, and traffic analysis to keep an eye on you, but it will eventually help to keep the contents of your messages and apps secure.

Google Newly release Security Google Newly release Security FeatureFeatureAndroid Keystore Provider◦ At the same time, Android 4.3 also

introduces a key store provider and APIs that allow applications to create exclusive-use keys. ◦ What that means is that apps can create or

store private keys that no other app can see or use.

Google Newly release Security Google Newly release Security FeatureFeatureRestrict Setuid from Android Apps◦ Your device's /system partition is now

mounted "nosuid" for Zygote-spawned processes. ◦ This helps prevent Android applications from

executing setuid programs. ◦ In turn, this reduces root attack surface and

likelihood of potential security vulnerabilities. ◦ In English, this means malicious apps will have

a much harder time trying to take over your device's super user/root privileges.

Google Newly release Security Google Newly release Security FeatureFeature◦ Restricted Profile

Play video

Google Newly release Security Google Newly release Security FeatureFeatureWi-Fi support for WPA2-Enterprise

networks◦ New application programming interfaces

(API)s can now be used configure the Wi-Fi credentials needed for connections to access points using WPA2 enterprise with Extensible Authentication Protocol (EAP) and Encapsulated EAP (Phase 2). ◦ With this, developers will be able to create

apps that can join business Access Points (APs) that use EAP and Phase 2 authentication methods.

Development process Best Development process Best practices practices Source code security review

Source code review can detect a broad range of security issues, including those identified in this document. Android strongly encourages both manual and automated source code review.• Android Lint should be run on all

application code using the Android SDK.

Development process Best Development process Best practices practices Automated testing

Automated testing can detect a broad range of security issues, including many of those identified in this document.

1) CTS is regularly updated with security tests; the most recent version of CTS must be run to verify compatibility.

2) CTS should be run regularly throughout the development process to detect problems early and reduce time to correction.

3) OEMs should automate security testing of any interfaces including testing with malformed inputs (fuzz testing).

Development process Best Development process Best practices practices Signing system images

The signature of the system image is critical for determining the integrity of the device. Specifically

1) Devices must not be signed with a key that is publicly known..

2) Keys used to sign devices should be managed in a manner consistent with industry standard practices for handling sensitive keys, including a hardware security module (HSM) that provides limited, auditable access.

Development process Best Development process Best practices practices Signing applications (APKs) Application signatures play an important role in device

security. They are used for permissions checks as well as

software updates. When selecting a key to use for signing applications, it is important to consider whether an application will be available only on a single device or common across multiple devices.

1) Applications must not be signed with a key that is publicly known.

2) Applications should not be signed with the platform key.

Development process Best Development process Best practices practices Signing applications (APKs) 3). Keys used to sign applications should be managed in

a manner consistent with industry standard practices for handling sensitive keys, including an HSM that provides limited, auditable access

4). Applications with the same package name should not be signed with different keys.

Development process Best Development process Best practices practices Apps publishing Google Play provides OEMs with the ability to update

applications without performing a complete system update.

This can expedite response to security issues and delivery of new features.

This also provides a way to make sure that your application has a unique package name.

Development process Best Development process Best practices practices Incident response External parties must have the ability to contact OEMs

about device-specific security issues. We strongly recommend the creation of a publicly accessible email address for managing security incidents.

1) Create a [email protected] or similar address and publicize it.

2) If you become aware of a security issue affecting Android OS or Android devices from multiple OEMs, you should contact the Android Security Team at [email protected].

Hybrid application HTML5 Local Hybrid application HTML5 Local store/index DB Security.store/index DB Security.

Android Developer Preview.Android Developer Preview.

Play video

Policy Enforcement Framework for Policy Enforcement Framework for college studentscollege students If the tablet is being used for conducting quizzes or

exams in schools, only the quiz or exam related apps should get open.

Any request to start any of the remaining apps should be blocked.

During school-time, students can open a limited set of apps.

List of allowed apps would be defined by schools (teachers). For example, students should not be able to open social networking apps (like Facebook, Twitter) or gaming apps (like Angry Birds, Temple Run) during school-time (say, 9:00am to 3:30pm).

QuestionQuestionThe Android permissions model was

designed with two fundamental goals What are the those Two Fundamental

goals ?

My Words My Words The next generation of open operating

systems won’t be on desktops or mainframes but on the small mobile devices we carry every day.

The openness of these new environments will lead to new applications and markets and will enable greater integration

Thank You

Android Security

Software

Transcript of Android Security