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
>
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Comments 0
Log in to post a comment