Lecture 9:

Introduction to Android Security

Sandeep K. Shukla
Indian Institute of Technology
Kanpur
 Acknowledgements
Maciej Olewiski
Web Resources
 Lecture 8: Internet Security
Total Modules on Web Client Security
Module 8.1: Major Web server Threats: Command
and SQL Injection Attacks
Module 8.2: CSRF Cross-Site Request Forgery
Module 8.3: XSS Cross-Site Scripting
Module 8.4: Defenses and Protections against XSS
Module 8.5: Finding Vulnerabilities
Module 8.6: Secure Development
Module 9.1: Basics of Android
Why Study Android
Security?
Market Share Growth Trend
Versions of Android
Numerous Vulnerabilities discovered
on a daily basis
 Android Nougat (7.0) Security

Enhancements
File-based encryption. Encrypting at the file level, instead of encrypting the entire
storage area as a single unit, better isolates and protects individual users and profiles
(such as personal and work) on a device.
Direct Boot. Enabled by file-based encryption, Direct Boot allows certain apps such
as alarm clock and accessibility features to run when device is powered on but not
unlocked.
Verified Boot. Verified Boot is now strictly enforced to prevent compromised devices
from booting; it supports error correction to improve reliability against non-malicious
data corruption.
Library load-order randomization and improved ASLR. Increased randomness
makes some code-reuse attacks less reliable.
Kernel hardening. Added additional memory protection for newer kernels by
marking portions of kernel memory as read-only, restricting kernel access to user
space addresses and further reducing the existing attack surface.
APK signature scheme v2. Introduced a whole-file signature scheme that improves
verification speed and strengthens integrity guarantees.
Trusted CA store. To make it easier for apps to control access to their secure
network traffic, user-installed certificate authorities and those installed through
Device Admin APIs are no longer trusted by default for apps targeting API Level 24+.
 Android Marshmellow (6.0) Security Enhancements
Runtime Permissions. Applications request permissions at runtime instead of being
granted at App install time. Users can toggle permissions on and off for both M and
pre-M applications.
Verified Boot. A set of cryptographic checks of system software are conducted prior
to execution to ensure the phone is healthy from the boot loader all the way up to the
operating system.
Hardware-Isolated Security. New Hardware Abstraction Layer (HAL) used by
Fingerprint API, Lockscreen, Device Encryption, and Client Certificates to protect keys
against kernel compromise and/or local physical attacks
Fingerprints. Devices can now be unlocked with just a touch. Developers can also
take advantage of new APIs to use fingerprints to lock and unlock encryption keys.
SD Card Adoption. Removable media can beadoptedto a device and expand
available storage for app local data, photos, videos, etc., but still be protected by
block-level encryption.
Clear Text Traffic. Developers can use a new StrictMode to make sure their
application doesn't use cleartext.
System Hardening. Hardening of the system via policies enforced by SELinux. This
offers better isolation between users, IOCTL filtering, reduce threat of exposed
services, further tightening of SELinux domains, and extremely limited /proc access.
Android Architecture
 Linux Substrate
At the bottom of the layers is Linux with many
patches. -- more recently SElinux
This provides a level of abstraction between the
device hardware
It contains all the essential hardware drivers like
camera, keypad, display etc.
Also, the kernel handles networking and a vast array
of device drivers, which is useful in interfacing to
peripheral hardware.
 Libraries Layer
On top of Linux kernel there is a set of
libraries including
open-source Web browser engine WebKit
well known library libc
SQLite database which is a useful repository for
storage and sharing of application data
libraries to play and record audio and video,
SSL libraries responsible for Internet security
etc.
 Android Libraries
Java-based libraries that are specific to
Android development
Examples
the application framework
Libraries to facilitate user interface building
Libraries for graphics drawing
Libraries for database access.
 Examples of Android Libraries
android.app
Provides access to the application model
android.content
Facilitates content access, publishing and messaging between applications and
application components.
android.database
Used to access data published by content providers and includes SQLite database
management classes.
android.opengl
A Java interface to the OpenGL ES 3D graphics rendering API.
android.os
Provides applications with access to standard operating system services including
messages, system services and inter-process communication.
 Example android libraries (2)
android.text
Used to render and manipulate text on a device display.
android.view
The fundamental building blocks of application user interfaces.
android.widget
A rich collection of pre-built user interface components such as
buttons, labels, list views, layout managers, radio buttons etc.
android.webkit
A set of classes intended to allow web-browsing capabilities to be
built into applications.
 Android Runtime
a key component is Dalvik Virtual Machine
Java Virtual Machine specially designed and optimized for
Android
The Dalvik VM makes use of Linux core features like
memory management and multi-threading
The Dalvik VM enables every Android application to run in
its own process, with its own instance of the Dalvik virtual
machine.
The Android runtime also provides a set of core libraries
enables Android application developers to write Android applications
using standard Java programming language.
 Android Application Framework

The Application Framework layer provides many higher-level

services to applications in the form of Java classes.
Application developers are allowed to make use of these services in their
applications.
Example services
Activity Manager Controls all aspects of the application lifecycle and
activity stack.
Content Providers Allows applications to publish and share data with
other applications.
Resource Manager Provides access to non-code embedded resources
such as strings, color settings and user interface layouts.
Notifications Manager Allows applications to display alerts and
notifications to the user.
View System An extensible set of views used to create application user
interfaces.
 Android Applications
Android Applications are composed of various
application components such as
Activities
They dictate the UI and handle the user interaction to the smart
phone screen.
Services
They handle background processing associated with an application.
Broadcast Receivers
They handle communication between Android OS and applications.
Content Providers
They handle data and database management issues.
 Activities
An activity represents a single screen with a user
interface,
Activity performs actions on the screen.
For example, an email application might have one
activity that shows a list of new emails, another activity
to compose an email, and another activity for reading
emails.
If an application has more than one activity, then one of
them should be marked as the activity that is presented
when the application is launched.
An activity is implemented as a subclass
ofActivityclass as follows
 Services
A service is a component that runs in the
background to perform long-running operations.
For example, a service might play music in the
background while the user is in a different application,
it might fetch data over the network without blocking
user interaction with an activity.
A service is implemented as a subclass
ofServiceclass as follows
public class MyService extends Service { }
 Broadcast Receivers
Broadcast Receivers respond to broadcast messages from other
applications or from the system.
For example, applications can also initiate broadcasts to let other
applications know that some data has been downloaded to the device
and is available for them to use, so this is broadcast receiver who will
intercept this communication and will initiate appropriate action.
A broadcast receiver is implemented as a subclass
ofBroadcastReceiver class and each message is broadcast as
anIntentobject.
public class MyReceiver extends BroadcastReceiver {
public void onReceive(context,intent){}
}
 Content Provider
A content provider component supplies data from one
application to others on request.
Such requests are handled by the methods of
theContentResolverclass.
The data may be stored in the file system, the database or somewhere
else entirely.
A content provider is implemented as a subclass
ofContentProviderclass and must implement a standard
set of APIs that enable other applications to perform
transactions.
public class MyContentProvider extends ContentProvider { public void
onCreate(){} }
 Additional Components of Applications
Other components are used in the construction of previously
mentioned entities, their logic, and wiring between them.
Fragments
Represents a portion of user interface in an Activity.
Views
UI elements that are drawn on-screen including buttons, lists forms etc.
Layouts
View hierarchies that control screen format and appearance of the views.
Intents
Messages wiring components together.
Resources
External elements, such as strings, constants and drawable pictures.
Manifest
Configuration file for the application.
 Android Platform Security Architecture
Android seeks to be the most secure and usable operating
system for mobile platforms by re-purposing traditional
operating system security controls to:
Protect application and user data
Protect system resources (including the network)
Provide application isolation from the system, other applications, and
from the user
To achieve these objectives, Android provides these key
security features:
Robust security at the OS level through the Linux kernel
Mandatory application sandbox for all applications
Secure interprocess communication
Application signing
Application-defined and user-granted permissions
 Kernel Security
Whether that code is the result of included application behavior or
an exploitation of an application vulnerability, the system is
designed
to prevent the rogue application from harming other applications, the
Android system, or the device itself.
Even native code is constrained by the Application Sandbox.
As the base for a mobile computing environment, the Linux kernel
provides Android with several key security features, including:
A user-based permissions model
Process isolation
Extensible mechanism for secure IPC
The ability to remove unnecessary and potentially insecure parts of the
kernel
 Kernel Security

Androids Linux Kernel:

Prevents user A from reading user B's files
Ensures that user A does not exhaust user B's
memory
Ensures that user A does not exhaust user B's
CPU resources
Ensures that user A does not exhaust user B's
devices (e.g. telephony, GPS, Bluetooth)
 Application Sandbox
Linux user-based protection as a means of identifying and isolating
application resources (separation of processes and file permissions) :
assigns a unique user ID (UID) to each Android application and runs it as
that user in a separate process.
different from other operating systems (including the traditional Linux
configuration), where multiple applications run with the same user
permissions.
enforces security between applications and the system at the process
level through standard Linux facilities, such as user and group IDs that
are assigned to applications
By default, applications cannot interact with each other and applications
have limited access to the operating system.
to break out of the Application Sandbox in a properly configured device, one must
compromise the security of the Linux kernel.
 Security Enhanced Linux (4.3 onwards)
Android uses SELinux to enforce mandatory access control (MAC) over
all processes, even processes running with root/superuser privileges
(a.k.a. Linux capabilities).
SELinux enhances Android security by confining privileged processes
and automating security policy creation.
With SELinux, Android can
better protect and confine system services
control access to application data and system logs
reduce the effects of malicious software, and
protect users from potential flaws in code on mobile devices.
Android includes SELinux in enforcing mode and a corresponding
security policy that works by default
In enforcing mode, illegitimate actions are prevented and all attempted
violations are logged by the kernel
Domains, permissive, enforced SELinux
SELinux can operate in one of two global modes:
permissive mode
permission denials are logged but not enforced
enforcing mode
in which denials are both logged and enforced.
SELinux also supports a per-domain permissive mode
specific domains (processes) can be made permissive while placing
the rest of the system in global enforcing mode.
FromAndroid 5.0 release, Android moved to full enforcement of
SELinux.
Everything is in enforcing mode since the 5.0 release
No processes other thaninitshould run in theinitdomain
Any generic denial (for a block_device, socket_device, default_service,
etc.) indicates that device needs a special domain
 Verified Boot
Android 6.0 and later supports verified boot and
device-mapper-verity.
Verified boot guarantees the integrity of the
device software starting from a hardware root of
trust up to the system partition.
During boot, each stage cryptographically verifies
the integrity and authenticity of the next stage
before executing it.
Android 7.0 and later supports strictly enforced
verified boot, which means compromised devices
cannot boot.
 Rooting of Devices
By default, on Android only the kernel and a small subset of the core
applications run with root permissions.
Android does not prevent a user or application with root permissions from
modifying the operating system, kernel, or any other application.
On many Android devices users have the ability to unlock the
bootloader in order to allow installation of an alternate operating
system.
These alternate operating systems may allow an owner to gain root access
for purposes of debugging applications and system components
To protect any existing user data from compromise the bootloader
unlock mechanism requires that the bootloader erase any existing
user data as part of the unlock step.
Root access gained via exploiting a kernel bug or security hole can bypass
this protection.
 Android Applications
The main Android application building blocks are:
AndroidManifest.xml:
Thisfile is the control file that tells the system what to do with all the top-
level components (specifically activities, services, broadcast receivers, and
content providers described below) in an application.
This also specifies which permissions are required.
Activities:
the code for a single, user-focused task.
It usually includes displaying a UI to the user, but it does not have to
Services:
a body of code that runs in the background.
It can run in its own process, or in the context of another application's
process.
Other components "bind" to a Service and invoke methods on it via RPC
Broadcast Receiver:
an object that is instantiated when an IPC mechanism known as anIntentis
issued by the operating system or another application.
 The Android Permission Model: Accessing Protected
APIs
By default, an Android application can only access a limited
range of system resources.
The system manages Android application access to resources
that, if used incorrectly or maliciously, could adversely impact
the user experience, the network, or data on the device.
Some capabilities are restricted by an intentional lack of APIs to the
sensitive functionality (e.g. there is no Android API for directly
manipulating the SIM card).
In some instances, separation of roles provides a security measure,
as with the per-application isolation of storage.
In some cases, the sensitive APIs are intended for use by trusted
applications and protected through a security mechanism known as
Permissions.
Details on creating and using application specific permissions are
described at
https://developer.android.com/guide/topics/security/security.html.
 IPC: Interprocess Communication in
Android
Processes can communicate using any of the
traditional UNIX-type mechanisms
filesystem, local sockets, or signals
However, the Linux permissions still apply.
Android also provides new IPC mechanisms:
Binder: A lightweight capability-based remote procedure
call mechanism designed for high performance when
performing in-process and cross-process calls.
Binder is implemented using a custom Linux driver.
 Final Words
Mobile devices are becoming more and more popular
In the same time, they store more and more sensitive, personal data
They are very attractive as an attack target\
Conflicting requirements: environment flexibility, convenient usage
and strict security

Android is designed to face those problems and it does it

All applications are sandboxed
Very strict security solutions on lower architecture layers
Rich, flexible and distributed environment of higher levels
Security requirements are met because of two basic mechanisms
Explicit data sharing
Permissions