mobile sec 1b Flashcards
Intents
t is a messaging object an app uses to request an
action from another app component.
– To start an activity
– To start a service
– Or to deliver a broadcast (any app will be able to receive it)
Two types of intents:
– Explicit intents
– Implicit intents:
Explicit intents:
specify the component to start by name (the fully-qualified class name).
– Implicit intents:
: do not name a specific component, but
declare a general action to perform, which allows a
component from another app to handle it.
Intent Filters
• To advertise which implicit intents an app can
receive, declare one or more intent filters for each
component of the app.
– This is declared in the Manifest file for the app.
• Each intent filter specifies the type of intents it
accepts based on the intent’s action, data, and
category.
• The system will deliver an implicit intent to an app
component only if the intent can pass through one of
its intent filters.
Intent resolution
Searches all apps for an intent filter that matches A’s intent. When a match
is found, system passes the Intent to the found target (app B).
Android Security: Kernel Security
: inherits features of Linux security.
App sandboxing via users and groups permissions of Linux
– Each app is assigned a unique user ID (UID) at the Linux level.
– Each app is run as a process with effective UID of the user for the app.
– Process isolation features in Linux apply to app, e.g., an app cannot
read/write another process (app) memory or files.
Android Security: Kernel Security::: File system:
– File system permissions from Linux: ensures an app cannot access files
owned by other apps.
– System partition (containing OS libraries, application runtime,
framework and applications) is set to read-only.
• SELinux enforcement (since Android 5.0)
ensures further app
isolation in addition to user-group isolation.
Android Security: Kernel Security “Rooting” of device:
“Rooting” of device:
– By default only the kernel and a small subset of applications run with root
permissions.
– User accessible apps do not have root permission by default.
– Granting root permission to user apps only possible by modifying the OS.
– Bootloader of most Android devices are locked to prevent modification of
OS. But some Android devices allows users to unlock it.
Android Security: Kernel Security Device Administration:
Since Android 2.2., Android OS includes a set of API for remote
administration.
– It can allow, e.g., an administrator to remotely wipe a device.
Android apps run in a sandbox and by default __________
t have limited
access to system resources.
The Android OS manages accesses to
manages accesses to critical resources such as:
– camera functions, location data (GPS), Bluetooth, telephony,
SMS/MMS, network/data connections.
The Android OS Requests to critical resources can be done through:
– Launching of activities of other apps (e.g., web browser, phone
app, etc).
– Using system provided API’s.
– Sending (explicit/implicit) Intent objects
– Binding to services provided by other apps/components.
• Access to critical resources are guarded by permissions
Android Permissions
Specify types of resources or services: internet, SMS, phone calls, read contacts, location (GPS), IMEI number, etc. • Each app asks for permissions it requires at install time.
Android Permissions
• Two types of permissions
normal permissions and dangerous permissions.
Android Permissions Normal permissions:
– permissions to access data or resources outside the app’s sandbox, where
there is very little risk to the user’s privacy or the operation of other apps
– Examples: accessing internet (INTERNET), setting time zone (SET_TIME_ZONE),
information about wifi networks (ACCESS_WIFI_STATE).
• Android Permissions Dangerous permissions:
– Permissions to access data or resources that involve the user’s private
information, or could potentially affect the user’s stored data or the operation
of other apps.
– Examples: read contact data (READ_CONTACTS), access GPS data
(ACCESS_FINE_LOCATION)
• An app can also define its own custom permissions, and sets their
protection level (i.e., normal or dangerous).
Android Permissions
• Dangerous Permissions - say more
permissions which could potentially affect the user's privacy or the device's operation. The user must explicitly agree to grant those permissions: – accessing the camera, – contacts, – location, – microphone, sensors, SMS, and storage.
Permission Groups
A permission can belong to a permission group.
• A permission group collects permissions related to
certain data/resource access, e.g,
– Permission group CONTACTS consists of READ_CONTACTS,
WRITE_CONTACTS and GET_ACCOUNT.
• Permission group is relevant only when enforcing
permission granting/denial of a dangerous permission.
• All dangerous permissions belong to permission
groups.
when is a permission group relevant
only when enforcing
permission granting/denial of a dangerous permission
• A permission group collects
s permissions related to
certain data/resource access
Granting Permissions
• An app specifies the permissions it needs in its
manifest file.
• Permission requests:
– At installation time:
• for normal permissions, automatically granted without user
interaction.
• For dangerous permissions, user confirmation is required.
– At runtime (before Android 6.0): no approval required
from user, for all kinds of permissions.
– At runtime (Android 6.0 onwards): dangerous
permissions require explicit approval from user.
An app specifies the permissions it needs in its
manifest file
• Permission requests:– At installation time:
• for normal permissions, automatically granted without user
interaction.
• For dangerous permissions, user confirmation is required.
• Permission requests:– At runtime (before Android 6.0):
: no approval required
from user, for all kinds of permissions
• Permission requests:– At runtime (after Android 6.0):
: dangerous
permissions require explicit approval from user.
• In Android 6.0, if an app requests a dangerous permission X
at runtime:
– If the app does not currently have any permissions in the
permission group of X, the system shows a dialog box to ask
user approval.
– If the app already has another dangerous permission in the
same permission group as X, the system immediately grants the
permission without any interaction with the user.
• For example, if an app had previously requested and been
granted the READ_CONTACTS permission, and it then
requests WRITE_CONTACTS, the system immediately grants
that permission (note both in same permission groups)
Android permissions
• A form of discretionary access control.
• A permission can be seen as a ‘ticket’.
– Each app has a list of permissions (could be empty).
– Each object (component) has a list of permissions required
for the access to be granted.
• A capability is exercised when a subject (an app) makes an IPC
to an object (a component).
– Inter-process communication, the sharing of data across multiple and
commonly specialized processes
– Android reference monitor ensures that the caller
Android permissions A permission can be seen as a ‘ticket
– Each app has a list of permissions (could be empty).
– Each object (component) has a list of permissions required
for the access to be granted.
android services
App can offer services to other apps:
– Via dedicated Service component:
• Needs to be explicitly exported in order to be accessible from
other apps.
– Via a BroadcastReceiver component:
• Needs to specificy the Intent it can handle, via the use of Intent
Filters.
• An app offering a service can impose the permissions required
to access that service, but is not required to do so.
• No explicit security policies governing the provision of
services.
android services App can offer services to other apps via
– Via dedicated Service component:
• Needs to be explicitly exported in order to be accessible from
other apps.
– Via a BroadcastReceiver component:
• Needs to specificy the Intent it can handle, via the use of Intent
Filters
ANDROID can an app offering a service impose the permissions required
to access that service
An app offering a service can impose the permissions required
to access that service, but is not required to do so
Security Issues: non-Android specific
• Privilege misuse: – Information misuse – Phone misuse • Included libraries – Ad and analytics libraries – Developer toolkits • Kernel level vulnerabilities: – Vulnerabilities in Linux kernel, system libraries, device drivers, etc.
Android framework specific vulnerabilities
• Leaking information to logs • Leaking information via IPC • Unprotected Broadcast Receivers • Intent injection • JNI (java native interface) & C/C++ library vulnerabilities.
Android framework Privilege misuse
• Information misuse:
– Leakage of identifying information, such as IMEI
number, location information, etc.
– Phone identifiers used in advertising networks and to
track individuals.
• Phone misuse:
– Calls or SMS to premium numbers
– Audio/video eavesdropping
– Socket API uses (for custom network protocol)
– Query to obtain list of installed apps
Android framework Privilege misuse Information misuse:
– Leakage of identifying information, such as IMEI
number, location information, etc.
– Phone identifiers used in advertising networks and to
track individuals.
Android framework Privilege misuse Phone misuse:
– Calls or SMS to premium numbers
– Audio/video eavesdropping
– Socket API uses (for custom network protocol)
– Query to obtain list of installed apps
Android framework Included libraries • Advertisement and analytics libraries:
Often used by apps to generate revenue from ads.
– These libraries collect unique phone information.
– Communication with the ad server may not be protected,
causing leakage of information.
– Ad library may execute untrusted codes (eg Java script)
Android framework Included libraries •Developer toolkits:
– Some toolkits may replicate dangerous functionalities.
– users of the toolkits may not have control over the
included extra functionalities
Android Leaking of information via logs
Android provides a centralized logging facility via the
Log API.
• In early versions of Android, apps with READ_LOGS
permission can read the content of system logs.
– Sensitive information has been known to be leaked
through logs.
• In later versions of Android (since Jelly Bean) apps
can only read their own logs
In early versions of Android, apps with READ_LOGS
permission can
can read the content of system logs.
– Sensitive information has been known to be leaked
through logs
• In later versions of Android (since Jelly Bean) apps can only read
their own logs
Leakage of Information via IPC
• Any app can receive an Intent broadcast that does
not specify the target component.
• This is unsafe if the Intent object contains sensitive
information.
– A malicious app with an appropriate intent filter may be
able to intercept the Intent.
• Enck et al (2011) found many instances of apps
broadcast unsafe Intents, which contain sensitive
information
Android Unprotected Broadcast Receiver
• Applications use broadcast receiver components to
receive intent messages.
• Broadcast receivers define “intent filters” to
subscribe to specific event types are public.
• If the receiver is not protected by a permission, a
malicious application can forge messages.
– It can trick a legitimate app to perform privileged action on
its behalf.
Privilege Escalation “Confused deputy”:
B is not malicious,
but used as a proxy
to access internet.
Privilege Escalation Collusion:
C and D
are both malicious,
but have different
sets of permissions.
android Privilege Escalation give me an example
In July 2014, a bug was found by CureSec in the broadcast
receiver of the system component com.android.phone.
• No permissions imposed by the broadcast receiver on the
calling apps for certain Intents.
– Some intents were supposed to be restricted, but was instead
exported; due to a malformed tag in the manifest file.
• In one case, it allows an app with zero permission to leverage
the component com.android.phone to perform a phone call
on behalf of the calling app!
• Android systems before version 4.4.3 are affected.
android C/C++ Library vulnerabilities
Android/Java allows an app to call libraries
written in C/C++, via the use of Java Native
Interface (JNI).
• C/C++ codes may be more prone to buffer
overflow vulnerabilities.
• If the libraries being called run under root
privilege, a compromise could result in
attacker gaining root privilege!
Example: Stagefright bug
Discovered in August 2015 by Zimperium Inc.
• ‘Stagefright’ refers to the name of a Media library in
Android, written in C/C++, used to pre-process certain
media files.
• It contains several bugs: integer overflow and heap
overflow.
• Effect: allows an attacker to send specially crafted media
file (e.g., via MMS), and executes arbitrary codes
remotely.
QuadRooter
QuadRooter refers to 4 vulnerabilities affecting Android devices that
use Qualcomm® chipsets.
– Bugs in Qualcomm drivers for the chipsets; affected around 900
million Android devices.
• Any one of the vulnerabilities can be exploited to gain root
privilege.
• Discovered by Check Point researchers in April 2016; publicized in
August 2016.
• The bugs affect three components in the drivers:
– IPC router that provides inter-process communication between
Qualcomm components.
– Ashmem: android kernel anonymous shared memory feature.
– Kernel graphics support layer.
• Vulnerabilities in C code of the drivers; exploiting known flaws such
as race conditions, use-after-free bugs.
At the kernel layer Android inherits
the Linux security
mechanisms.
But most security/privacy concerns in Android lie in
the application level.
• At the application level, access control defined by
permissions.
• Hence Vulnerabilities exist even assuming the layer below (linux, core library) is secure
