mobile sec 1b

Question 1

Intents

Answer 1

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)

Question 2

Two types of intents:

Answer 2

– Explicit intents

– Implicit intents:

Question 3

Explicit intents:

Answer 3

specify the component to start by name
(the fully-qualified class name).

Question 4

– Implicit intents:

Answer 4

: do not name a specific component, but
declare a general action to perform, which allows a
component from another app to handle it.

Question 5

Intent Filters

Answer 5

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

Question 6

Intent resolution

Answer 6

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

Question 7

Android Security: Kernel Security

Answer 7

: inherits features of Linux security.

Question 8

App sandboxing via users and groups permissions of Linux

Answer 8

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

Question 9

Android Security: Kernel Security::: File system:

Answer 9

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

Question 10

• SELinux enforcement (since Android 5.0)

Answer 10

ensures further app

isolation in addition to user-group isolation.

Question 11

Android Security: Kernel Security “Rooting” of device:

Answer 11

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

Question 12

Android Security: Kernel Security Device Administration:

Answer 12

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.

Question 13

Android apps run in a sandbox and by default __________

Answer 13

t have limited

access to system resources.

Question 14

The Android OS manages accesses to

Answer 14

manages accesses to critical resources such as:
– camera functions, location data (GPS), Bluetooth, telephony,
SMS/MMS, network/data connections.

Question 15

The Android OS Requests to critical resources can be done through:

Answer 15

– 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

Question 16

Android Permissions

Answer 16

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.

Question 17

Android Permissions

• Two types of permissions

Answer 17

normal permissions and dangerous permissions.

Question 18

Android Permissions Normal permissions:

Answer 18

– 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).

Question 19

• Android Permissions Dangerous permissions:

Answer 19

– 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).

Question 20

Android Permissions

• Dangerous Permissions - say more

Answer 20

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.

Question 21

Permission Groups

Answer 21

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.

Question 22

when is a permission group relevant

Answer 22

only when enforcing

permission granting/denial of a dangerous permission

Question 23

• A permission group collects

Answer 23

s permissions related to

certain data/resource access

Question 24

Granting Permissions

Answer 24

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

Question 25

An app specifies the permissions it needs in its

Answer 25

manifest file

Question 26

• Permission requests:– At installation time:

Answer 26

• for normal permissions, automatically granted without user
interaction.
• For dangerous permissions, user confirmation is required.

Question 27

• Permission requests:– At runtime (before Android 6.0):

Answer 27

: no approval required

from user, for all kinds of permissions

Question 28

• Permission requests:– At runtime (after Android 6.0):

Answer 28

: dangerous

permissions require explicit approval from user.

Question 29

• In Android 6.0, if an app requests a dangerous permission X
at runtime:

Answer 29

– 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)

Question 30

Android permissions

Answer 30

• 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

Question 31

Android permissions A permission can be seen as a ‘ticket

Answer 31

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

Question 32

android services

Answer 32

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.

Question 33

android services App can offer services to other apps via

Answer 33

– 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

Question 34

ANDROID can an app offering a service impose the permissions required
to access that service

Answer 34

An app offering a service can impose the permissions required
to access that service, but is not required to do so

Question 35

Security Issues: non-Android specific

Answer 35

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

Question 36

Android framework specific vulnerabilities

Answer 36

• Leaking information to logs
• Leaking information via IPC
• Unprotected Broadcast Receivers
• Intent injection
• JNI (java native interface) & C/C++ library
vulnerabilities.

Question 37

Android framework Privilege misuse

Answer 37

• 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

Question 38

Android framework Privilege misuse Information misuse:

Answer 38

– Leakage of identifying information, such as IMEI
number, location information, etc.
– Phone identifiers used in advertising networks and to
track individuals.

Question 39

Android framework Privilege misuse Phone misuse:

Answer 39

– Calls or SMS to premium numbers
– Audio/video eavesdropping
– Socket API uses (for custom network protocol)
– Query to obtain list of installed apps

Question 40

Android framework Included libraries • Advertisement and analytics libraries:

Answer 40

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)

Question 41

Android framework Included libraries •Developer toolkits:

Answer 41

– Some toolkits may replicate dangerous functionalities.
– users of the toolkits may not have control over the
included extra functionalities

Question 42

Android Leaking of information via logs

Answer 42

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

Question 43

In early versions of Android, apps with READ_LOGS

permission can

Answer 43

can read the content of system logs.
– Sensitive information has been known to be leaked
through logs

Question 44

• In later versions of Android (since Jelly Bean) apps can only read

Answer 44

their own logs

Question 45

Leakage of Information via IPC

Answer 45

• 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

Question 46

Android Unprotected Broadcast Receiver

Answer 46

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

Question 47

Privilege Escalation “Confused deputy”:

Answer 47

B is not malicious,
but used as a proxy
to access internet.

Question 48

Privilege Escalation Collusion:

Answer 48

C and D
are both malicious,
but have different
sets of permissions.

Question 49

android Privilege Escalation give me an example

Answer 49

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.

Question 50

android C/C++ Library vulnerabilities

Answer 50

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!

Question 51

Example: Stagefright bug

Answer 51

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.

Question 52

QuadRooter

Answer 52

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.

Question 53

At the kernel layer Android inherits

Answer 53

the Linux security

mechanisms.

Question 54

But most security/privacy concerns in Android lie in

Answer 54

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