Term Project Proposal: - FAU Android - Florida Atlantic University

COT5930
–

Security for Wireless Systems Fall ‘10

Research Project Report

Professor Eduardo Fernandez


Charles Norona

Case Study of the Android Privilege Escalation Attack



Charles Norona

Florida Atlantic University

Cnorona1@fau.edu



Abstract



Recent investigations in Android security
imply that there is a serious privilege escalation
problem with the platform’s secur
ity model.
Although the problem is not unfounded its
definition can be better defined and identified

in
a recently updated version of the platform
. The
experiment described in this paper attempts to
recreate the experiments and attacks mentioned
in literat
ure which would then validate and
elaborate on the implications of the problem.
Later proposed security exercises

will be
described and encouraged.

1. Introduction

This section will describe various concepts
the reader should become familiar with to better

understand the context of the experiment.

1.1. Android Platform

and its
Components

The Android platform is an operating system
and development platform primarily for mobile
devices.
All applications are contained in
security sandbox to mitigate unauthoriz
ed
interactions with other applications and
components [1].
The most common components
of android applications are activities, broadcast
receivers, services, and
content providers
.

All of
these components for the exception of the
content providers can be
activate
d

via messages
known as intents [2].

Below is a list of
descriptions for the common components from
[3]:



Activities
. An Activity is usually one
screen of your application, hence there
could be one or more Activities per
application. It represents t
he user
interface, the application’s presentation
layer. To display information and
respond to user actions, Activities use
Views to form the graphical user
interface. The transition between
Activities is done by having one
Activity starting the next one.



Services
. A Service is a component that
runs in the background, thus not having
a visual user interface. Because of this,
it will not interact with the user, but
rather it will do some work silently,
invisibly, for you. They are used to
perform regular pr
ocessing that needs to
continue even when your application’s
Activities are not active or visible. As
an example, a Service might fetch data
over the network, in the background,
while the user normally interacts with
the application.



Content Providers
. Wh
en you want
specific data to be available to other
applications, you will use a Content
Provider. The data can be stored in a
SQLite database, or in a File, and you
can configure your own Content
Provider to permit access to that data.
For example, on an A
ndroid phone,
there is a specific Content Provider to
access the contact information.



Broadcast Receivers
. A Broadcast
Receiver receives and reacts to
broadcast messages. When you have an
event
-
driven environment, and you have
to be able to listen for eve
nts and act in
response, then you will register a
Broadcast Receiver to listen for events
that match a specific filter criteria, and
execute the desired action afterwards.



Intents
. Intents, or asynchronous
messages, are used to specify what
intentions you

have in terms of a
specific action being performed;
mainly, you use them to activate other
components of your application. The
COT5930
–

Security
for Wireless Systems Fall ‘10

Research Project Report

Professor Eduardo Fernandez


Charles Norona


2

content of the message, for activities
and services, names the action being
requested, and specifies the URI of the
data to act
on, among other things.

1.2. Permissions as
a
Mandatory
Access Control Mechanism

Android uses a mandatory access control
mechanism called permissions. By default
applications have no permissions and cannot
access permissible

or restricted

components su
ch
as network connectivity,
phone calling
applications
, read
ing

or writ
ing

to SD cards, etc.
In order to access these restricted components
application developers have to declare their use
in
the application’s manifest file

which
describes

the application
fo
r the android system

[1]
[4]
[5]
.

If an application attempts to use a restricted
component the system will throw a
SecurityException

and will result in the
application crashing.

1.3. Intents and Intent Filters

In android the way to achieve inter
-
process
com
munication is through the use of intents.
Intents are messages that contain information for
activating other components and passing
additional information
to those specific
components
.
Intent filters are implicit intent
entries that the application or comp
onent is
willing to receive and react upon

[2]
.

Within an application sandbox intents can be
passed explicitly, meaning that the developer can
instantiate an intent with the specific name of the
component s/he wishes to activate. Alternatively,
a developer

can instantiate implicit intents where
a label is given to an intent and is shared to other
developers for the sole purpose of allowing them
to activate target components. Implicit intents
can be created and used outside a target
component or application’
s sandbox

[2]
.

2.
Related Work

Some work has been done in the field of
Android security and investigations into the
android privilege escalation problem.

Lucas Davi et al. were the first to discover the
privilege escalation problem. Their case study
invo
lved an unauthorized use of the Phone
application as well as a scenario where a user
installs a non
-
malicious application that
succumbs to a buffer overflow vulnerability.
This allows an attacker to take advantage o
f the
vulnerability, using the applicatio
n’s permission
to use the
network

to send unauthorized text
messages.

Davi and his colleagues encourage the
use of reference monitors to complement
android’s security
mechanism [
5].

Both Jesse Burns and William Enck have
written literature that orients rea
ders to the nature
of the android security model and exposes
possible vulnerabilities and educate developers
how to mitigate creating such vulnerabilities
[
7
][
8
].

3.
Methods

This project was conducted as per
requirements for the Security for Wireless
Syste
ms course taught by Dr. Eduardo
Fernandez and required
few

task stages:
researching current and past literature, concoct
hypothesis based on experience and learned
concepts from said literature, repeating
experiments to validate hypothesis and claims
from

literature.

Developing Android applications requires one
to setup the Eclipse
IDE

with the Android
Development Tools plug
-
in. Instructions on
setting up the Eclipse IDE for Android can be
found at
developer.an
droid.com

[
9].

The targeted
platform for these experiments is android 2.2 and
was

launched using the IDE’s virtual device
which runs the said version of the platform.
Three projects were created, one for each
application described in Davi et al’s experime
nt
[5]. AppC is the target application, AppB
became the application which was permitted to
activate AppC, and AppA

(attacker app)

became
the app without permissions to launch AppC but
will attempt to anyway either by directly or by
proxy through AppB.

The

experiment

involved two phases.
Each

phase experimented with attempts to launch
AppC

and later
AppB with

three conditions:




“Callee app” has n
o intent filters
and

no permission enforcement.



“Callee app” has
intent filters
but

no
permission enforcement.



“C
allee app” has intent filters and
permission enforcement.



AppC

has sanctioned internet capabilities and
demonstrates this with the launch of th
e device’s
B
rowser application.

A custom permission,

LAUNCH_CUSTOM_BROWSER
,

was eventually
declared and enforce
d.

AppB has sanctioned permissions to launch
AppC. An attempt to do this explicitly failed but
COT5930
–

Security
for Wireless Systems Fall ‘10

Research Project Report

Professor Eduardo Fernandez


Charles Norona


3

an implicit intent message succeeded on some
conditions. Results will be explained in the next
section.

AppA has no sanctioned permissions and
attempts to call A
ppC and then AppB for
demonstration purposes. The results of this
experiment will be explained in the next section.

Source code of the three projects from this
experiment
is
posted under the documents
section of the FAU Android group website,
http://android.fau.edu/documents/#experiments
.


4.
Results

Both
“
callee
” applications
, AppC and AppB,
were only able to be called under certain
conditions mentioned in the previous section.
The figure belo
w shows which caller apps were
able to
activate the “callee” applications with the
given conditions:


“Callee”

No intent
filter

and

n
o perm
.

e
nf
rcmt.

With
intent

filter

but

No perm
.

e
nf
rcmt.

With

intent
filter

and

perm
.

e
nf
rcmt.

AppC

None

AppB,
AppA

AppB

AppB

None

AppA

None

Figure 1: Condition vs. “Callee” table.
Shows which caller app was able to activate
indicated “
callee
”

under indicated conditions.


All attempts to make explicit intent calls
failed since other application packages were not
recognized
.

Security exceptions resulted when AppA
attempted to

access AppC directly. However, it
was able to
use the

unregulated AppB to activate
AppC.

None of the “callee” applications were able to
be activated until intent filters were declared in
their respectiv
e AndroidManifest.xml files.

Intent filters allowed applications to be
implicitly activated. Enforcing permissions
requires third party application developers to
declare that their caller applications use the
targeted, restricted component in the
AndroidMa
nifest.xml file.

5.
Discussion

The hypothesis that was formulated at the
beginning of this work was that permission
escalation attacks were not as easy to cause in
the Android platform. Although android
engineers did some due diligence to mitigate this
fro
m happening the ultimate last defense against
this is the security savvy of the application
developer. Unfortunately, Davi et al are right in
saying that “application developers in general are
not security experts…”
[5].

This is
especially

true

since there
is plenty of documentation and ease
of access to the SDK that application developers
can learn to develop at their own leisure without
regard to security.

Because of these
considerations it is prudent to consider the
hypothesis wrong.

In order to better p
rotect end users from
this

problem efforts need to be made to better reach
out and educate application developers on the
implications of using intent filters and opening
access to
their applications for use with other
components. Some suggestions have alre
ady
been proposed such as the use of reference
monitors by Davi et al and exercising careful
security policy
-
making by Enck[5][8].
Although
permission enforcement does a good job of
helping application developers from unwittingly
granting access to non
-
per
mitted components it
is not enough to stop dedicated attackers. For
this adopting both suggested fixes of reference
monitors

on restricted components

and good
security policy establishment would be much
more effective in protecting restricted
applications
and components.

6.
Conclusion

This experiment offers

more context and
definition while investigating the android
permission escalation problem. Although there
are some mechanisms in the platform now that
help developers keep their applications secure
some
unwitting application authors might
unintentionally leave their programs open for
access by attackers. To prevent this from
happening more efforts ought to be made to
educate developers in basic security principles
and practices such as the defining of sec
urity
policies and the use of reference monitors.

COT5930
–

Security
for Wireless Systems Fall ‘10

Research Project Report

Professor Eduardo Fernandez


Charles Norona


4

7
. References

[1
]
“
Security and Permission.
”

Android Developer’s
Framework Topics.
http://developer.android.com/guide
/topics/security/sec
urity.html#arch
. [Accessed Dec. 5, 2010].


[2
]

“
Application Fundamentals.
”

Android Developer’s
Framework Topics.
http://developer.android.com/guide/topics/fun
damenta
ls.html

[Accessed Dec. 5, 2010].


[3]
Fonoage, Mihai. “Application Components and
Lifecycle.” Android Fundamentals Course Module.
ht
tp://android.fau.edu/wp
-
content/uploads/2010/04/05_Application
-
Components
-
and
-
Lifecycle_Mihai.doc
. [Accessed
Dec. 5, 2010].


[4] “
The AndroidManifest.xml File.” Android
Developer’s Framework Topics.

http://developer.android.com/guide/topics/manifest/ma
nifest
-
intro.html
. [Accessed Dec. 5, 2010].


[5
] Davi, Lucas et al. “Privilege Escalation Attacks on
Android.”

13th Information
Security Conference (ISC
2010) Paper.

http://www.trust.rub.de/research/publications/DDSW1
0/
.

[Accessed Dec. 5, 2010].


[6] “Intents and Intent Filters.”
Android Developer’s
Framework Topics.
http://developer.android.com/guide/topics/intents/inten
ts
-
filters.html
. [Accessed Dec. 5, 2010].


[7] Burns, Jesse. “Mobile Application Security on
Android.” Black Hat 2009 conference paper.
https://www.isecpartners.com/files/iSEC_Securing_A
ndroid_Apps.pdf
. [Accessed Dec. 5, 2010].


[8]

Enck, William. “Understanding Android Security.”
Research paper.
http://www.patrickmcdaniel.org/pubs/sp09.pdf
.
[Accessed Dec. 5, 2010].


[9]
Android SDK Quick Start Tutorial. Website:
http://developer.android.com/sdk/index.
html
.
[Accessed: Nov. 26, 2010]
.

8. Appendices

This section contains all of the documents
relevant to the experiment and research of this
paper.

8.1. Example of Declaring and
Enforcing Permissions

<
manifest

xmlns:android
=
"http://schemas.an
droid.com/apk/re
s/android"

package
=
"c_harley.securityexperi
ment01.appC"

android:versionCode
=
"1"

android:versionName
=
"1.0"
>

<!
--

Enforce the declared
permission with the
android:permission tag.
--
>

<
application

android:icon
=
"@drawable/icon"

android:label
=
"@string/app_name"
>

<
activity


android:name
=
".Main"


android:label
=
"@string/app_name"

android:permission
=
"c_harley.sec
urityexperiment01.appC.permissio
n.ACCESS_INTERNET"
>

<
intent
-
filter
>

<
action

android:name
=
"android.intent.act
ion.MAIN"

/>

<
category

android:name
=
"android.int
ent.cat
egory.LAUNCHER"

/>

</
intent
-
filter
>

<
intent
-
filter
>

<
action

android:name
=
"c_harley.securitye
xperiment01.LAUNCH_CUSTOM_BROWSE
R"

/>

<
category

android:name
=
"android.intent.cat
egory.DEFAULT"

/>

</
intent
-
filter
>

</
activity
>

</
application
>

<
permission

and
roid:name
=
"c_harley.securitye
xperiment01.appC.permission.ACCE
SS_INTERNET"

android:label
=
"@string/permlab_a
ccessInternet"

android:permissionGroup
=
"android
.permission
-
group.NETWORK"

android:description
=
"@string/per
mdesc_accessInternet"

android:protectionLeve
l
=
"dangero
us"

/>
<
uses
-
permission

android:name
=
"android.permission
.INTERNET"
></
uses
-
permission
>

</
manifest
>