Android Declassification Infrastructure: Final Report

texturegainfulΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

65 εμφανίσεις

Android Declassification Infrastructure:

Final
Report

PART A:

An abstract description

In today's world, smart phones are getting richer in capabilities and sensors every month. We trust our
phones with storing our most private information in them. We use
it for work and for connecting with
our family and friends and carry them with us everywhere we go.

One of the most popular operating systems for mobile phones today is Google's Android. It has beco
me
the world’
s leading smartphone platform since

the end o
f 2010.

At the half
point mark
of 2012, there
were 400 million devices activated and 1 million activations per day.

In June 2012, there were more than
600,000 apps available for Android, and the estimated number of applications downloaded from
'
Google
Play
'

(Google's online store)
was
over
20 billion.

Android allows applications to communicate with the hardware's devices (e.g. camera, SD card, etc.)
using its permission mechanism. From the moment an app
is granted

a specific
permission, it can access
and us
e the
appropriate
hardware device any time it wants to. The problem with these permissions is
their coarse granularity level
.

This presents a high security and privacy threat for users who are unaware
of what the app they just downloaded does.

We built an

application level infrastructure which intermediates between the various apps using it and
the OS. Our infrastructure asks for high permissions while exposing a finer grained permission
"interface" to 3
rd

party applications that use it.
This process of as
king for high permission while exporting
low permissions is called
d
eclassification
.
Upon installation, these applications can request only what
they truly require. In this manner, applications run the same way as before while keeping the user a lot
calmer
.

We identified the most commonly used Android permissions given to applications.

Based on our
findings, we designed our declassifier
to

enable access to 6 different phone “services”
(substituting the
coarse grained native OS permissions). These
permissions are
:

READ_CONTACTS

WRITE_EXTERNAL_STORAGE

READ_PHONE_STATE

READ_CALENDAR

RECORD_AUDIO

CHANGE_WIFI_STATE

For each of these OS permissions, our declassifier defines a set of custom, finer
-
grained permissions
which subdivide it
.

We tested our code

by successfully porting open source applications to use our declassifier.

PART B:
Background & Motivation

In today's world, smart phones are getting richer in capabilities and sensors

every month
.
It feels like
a
lmost everyone has a smart phone.
We trust

our phones
with

storing our most private information in
them
. We use it for work and for connecting with our
family and
friends.

W
e carry them with us
everywhere we go.
We install different applications on our phone to help us with our daily activities an
d
for our

entertain
ment
.
It is quite clear that a
n over
-
privileged application
could

pose a serious threat

to
us as end users
.

One of the most popular operating systems for mobile phones today is Google's Android. Android is
Linux
-
based

and
open source
.
It
has beco
me the world’
s leading smartphone platform since

the end of
2010.

For the first quarter of 2012, Android had a 59% smartphone market share worldwide.

At the half
point mark
of 2012, there were 400 million devices activated and 1 million activati
ons per day.

Android has
a large community of developers which
write primarily
in

Java.

Writing

Android

apps is
simple and
very
straight

forward.

In June 2012, there were more than 600,000 apps available for
Android, and the estimated number of application
s downloaded from
'
Google Play
'

(Google's online
store)
was
over
20 billion.

Android allows applications to communicate with the hardware's devices (e.g. camera, SD card, etc.)
using
its

permission mechanism
.
In order for an app to
address a hardware devic
e it needs
the
appropriate

permission. The app
declares in its manifest file the permission
s

which it intends to use
.
Upon installation, the user is required to actively confirm the app's use of the requested permission.
From that moment on, the app can ac
cess
and use
the hardware device
any time

it wants to.

The problem with
these permissions is their
coarse
granularity level. For example, a

malicious

app can
request access to use the phone's audio recorder
, pretending to be a voice
related
app

(i.e. Viber
,
Skype)
.
After the user's confirmation, such an app can potentially record the user at any time without his
knowledge. This presents a high security and privacy threat for users who are
unaware of

what the
app
they just downloaded does
.

There are many mor
e examples of such coarse granularity
in Android's
permissions
.


As was shown
to us
in class,
Microsoft
also realized this issue and solved it by adding
an abstraction
layer integrated within windows Phone OS
,

namely


its "Launchers" and "C
hoosers" API. A
ndroid,
however, does not
yet
offer
such
an integral
solution. That means there are hundreds of millions of

costumers walking around with a

potentially

harmful

device in their pocket without even knowing it.



Part C:
Our Project

Even though

Android is ope
n source, our project does not involve changing the OS itself. Instead, we
built

an application level infrastructure which intermediates between the various apps using it and the
OS.

What our code basically does is ask for high permissions while exposing
a finer grained permission
"
interface
"

to applications that use it
. Upon installation, the applications
using our infrastructure
can
request
only

what they
truly

require
.
In this manner, applications run
the same way
as before

while
keeping
the user a lot calmer.
For example,
an application
asking for

write access to the phone's
external storage will now be granted access

to a small, confined part of the SD card,

preventing it from
manipulating data that does not belong to it
.

This process of asking for high permission while exporting low permissions is called
d
eclassification
. Our
infrastructure is a
d
eclassifier
.

First, we had to identify the most commonly used
Android
permissions given to real life applications.
In
order to d
ecide which are most commonly used we
took

a survey in Google Play. Our findings can be
found in the attached Excel
document:

Android Permissions Usage Statistics.xlsx

.

Based on our findings
, w
e designed
our

declassifier
so

that it enables access to 6 di
fferent phone

services


(and potentially a lot more)
.

It

grants

the apps everything they
most probably
need, while
keeping the user as safe as possible.

Thus, applications utilizing
it
are
easier to develop, less buggy and
most importantly


less
privileged and more secure
.

These are the 6
coarse
-
grained

Android permissions we chose to focus on:

1.
android.permission.
READ
_CONTACTS



Allows an application to read the user's contacts

data.

2.
android.permission.
WRITE_EXTERNAL_STORAGE



Allows an app
lication to write to external storage

(i.e
.

the phone's SD card)
.

3.
android.permission.READ_
PHONE_STATE



Allows
read only access to phone state.

4.
android.permission.READ_
CALENDAR



Allows an application to read the user's calendar data.

5.
android.per
mission.
RECORD
_
AUDIO



Allows an application to record audio.


6.
android.permission.
CHANGE_WIFI_STATE



Allows applications to change Wi
-
Fi connectivity state.


For each of these

OS

permissions, our declassifier defines a set of custom
, finer
-
grained

permissions
which subdivide
it
.

For example, instead of requesting the READ_PHONE_STATE permission, an
application can now request only access to reading the phone's sim card serial number
, the IMEI (given
the network is GSM), etc
. This way, the applicati
on has only access to what it needs (instead of access to
all of the phone state properties) without interfering with its normal
flow
.

A detailed description of
each OS permission, potential harmful usage scenarios and a description of
the

custom permissi
on
s

can be found in the attached document
:


Declassifier Documentation.docx

.

Let's take a

closer look at
our declassifier's
implementation details
. It is divided to 7 Java packages:

1.

my.declassifier

2.

my.declassifier
.audiorecord

3.

my.declassifier
.calendar

4.

my.declassifier
.contacts

5.

my.declassifier
.externalstorage

6.

my.declassifier
.phonestate

7.

my.declassifier
.wifi

The
top
-
most
package contains

the

code which is common to all other packages, including the
application's main GUI Activity

and the implementation of t
he content provider (described below)
. Each
package
afterwards
includes code which is specific to the service it implements.

Content Provider

With 3rd party application developer
s

in mind, we decided to implement
content

providing
services as
easy to use
as
possible. In Android, a
content
providing
service is usually implemented using
a
ContentProvider. A
ContentProvider encapsulates data and provide
s

it to applications through the single
ContentResolver

interface.

When
looking at the list of services we want
ed

to export
, we decided that the Contacts, Calendar and
PhoneState are all content providing services.
Each of these services holds

data that the 3
rd

party
appl
ication can query on a

need to know


basis. And so,
the declassifier implements a ContentProvider
class. This way,
each service
holds an interface to a

SQLite
database

which, depending on the requesting
application's permission, can be queried for data.

Each service exports an interface which matche
s the custom permission allowing it to be
use
d
. This
interface is actually a URI for each sub
-
service provided by the
main
service. For example, in order to
query the Calendar service for an event description b
y its title, the application has to query the
ContentResolver using the following URI:

content://my.declassifier/
calendar
/description_by_title

-
'
my.declassifier
'

is the ContentProvider's base path
.

-

'
calendar
'

is the service
path.

-

'
description_by_title
'

is the wanted sub
-
service.


T
he parameters for the query (e.g. what is the event's title) are passed via the "selection" parameter of
the query method.

The full list of
services &
sub
-
services URIs can be found in the attached file:

Declassifier
Document
ation.docx

.

The syntax of the "selection" query parameters for each service can be found in
the code documentation.

BroadcastReceiver

Unlike other popular Oses, in Android each app runs as a separate process under a distinct UID.
This

means that in order
for a 3rd party app to communicate with our declassifier, some kind of IPC is
required
. Android offers several ways for IPC. Using Intents is
u
nsecure as anyone listening in can
recognize them and use them.

A
fter thoroughly reading the iSEC article
(
https://isecpartners.com/files/isec_securing_android_apps.pdf
) and
looking for a solution online,
we
concluded that
the most secure way of IPC is
achieved
using a BroadcastReceiver.

It filters incoming
intents by caller permissions and enables a callback m
echanism which allows sending back
an
answer

privately
.

W
e implemented our ExternalStorage service as a BroadcastReceiver.

An app that wants to use this
service

(provided that it has the permission to do so)

has to send an

ordered broadcast to our
Broadcas
tReceiver
,

including
the appropriate intent and parameters.

The app also has to implement its
own BroadcastReceiver which will be responsible for handling the callback result. This
BroadcastReceiver will also be sent via the ordered broadcast.

The External
Storage service basically allocates a folder for each application that uses it. The folder is
named using the app's UID (provided by the app upon different requests). This folder is the only path in
the external storage that the app can utilize and manipul
ate. This is done using the service's interface
which allows writing files, deleting files
,

etc.

The ExternalStorage service interface and custom permissions can be found in the attached file:

Declassifier Documentation.docx

.

Activity

We decided to imple
ment
several

services
as
a
proxy
from the app to the requested
service. In this
design we require

the user to actively grant access to a certain service for every
request

made by
the
application
. Please note that the user's confirmation can

theoretically
b
e replaced by a smarter
,
automatic
mechanism
,

which
will be
based on a set of rules including location, time, count, etc.

In order for the user to be able to confirm the action, we needed
a
GUI.
The BroadcastReceiver is
not
capable of creating a
GUI
or
showing one

(bringing it to the main scree
n
)
.
This
led us to
resort to
the
natural GUI
container

in Android

-

Activity.

We implemented both the Wifi and AudioRecord as Activities. In order to use th
ese services the
application has

to sen
d

an Intent contain
ing
both
the appropriate Action and parameters.

The
application should also provide an implementation of a callback method which
is r
u
n

once the result of
the action is ready (
i.e.

after the declassifier finished its job).

Both the RecordAudio and the Wifi

services' interfaces and custom permissions can be found in the
attached file:

Declassifier Documentation.docx

.



PART
S

D

&

E
: Now and Then

We did not come to our final solution right away. Our progress involved several cycles of planning,
implementing,

testing and occasionally going back to planning and starting the cycle all over again. In
this se
ct
ion we will describe the progress we went through
along the way
to our final solution.

Firstly, we need
ed

to
recall

the scope and objectives of our project:

To
Enable safer application development.

3
rd

party applications using our infrastructure will be granted lower permissions, but
should
sustain their original functionality.

Make
the permission mechanism finer grained.

Porting of applications should be
simple and intuitive.

Our success criteria
were
based on the quantity of applications we are able to port. For that matter, we
took
the

survey described in part C of this document. Our findings can be found in the attached Excel
document: “
Android Permissi
ons Usage Statistics.xlsx
”. In addition, we judge
d

our success based on our
ability to sustain the ported apps’ original functionality
,

while granting them lower permissions.

W
hen
first
presented with this project we were unfamiliar with the Android enviro
nment and
framework. This led us to design

a
solution based on Intents and activities. The solution required each
application to se
nd Intents to our declassifier
. The declassifier, in return, supplied the service to the
calling application and returned the

result
s

using the “OnActivityResult” method.

Presenting our progress in the first class milestone
brought forth

an important issue which we did not
pay enough attention to, and that is the security issue

(See section 1 of project scope)
. Although very
ea
sy to use

and intuitive, Intents are also un
secure. We realized that there are many inconsistencies in
such

a design. For example, who guarantees
that the applications that are sending the Intents are
authorized to do so? Since Intents are
un
secure, any ap
plication can intercept it and use it as its own,
allowing it to “disguise”
itself as another application.

The above drawback forced us to re
-
plan our design. We understood that further knowledge of the
Android framework is needed.
Thus, w
e started readin
g material relevant to the Android environment in
general and to security in Android in part.
In addition, we
used web forums and online examples to get a
deeper understanding of how to program correctly and securely in Android.
As a result, and with more
emphasis on security, we
entered
our
second
planning stage. At the
end of this period, the conclusion
was that we needed to use a

BroadcastReceiver
that will export custom permissions
(
for
further
details
on the BroadcastReceiver
see section C above).
At t
hat point we
had a secure channel for applications to
communicate with our declassifier. Soon afterwards, we entered our second implementation phase, re
-
implementing the declassifier in accordance to our new design.

All through the
2
nd

milestone and towards our
3
rd
, we designed our declassifier as described above,
as
sure
d

that this was the most secure design. We still believe it is. However, when we entered our
testing stage, we ran into another obstacle. As secure as our design was, we
lost sight of who we are
developing this declassifier for. We tried porting applications to use our declassifier, but that required
many changes in the application’s code, making the whole nature
of porting applications
unintuitive

and
sometimes quite comp
lex
.

This
did
not stand in unison with our success criteria and
was
therefore
problematic.

The cause of this complexity lie
d

in the BroadcastReceiver
’s

asynchronous
working model. That means
that
an app
could

ask for a declassifier service

by using the
SendOrderedBroadcast method which

return
ed

immediately. The result
of the operation
was
read using a callback method which the caller
supplied upon initiation. As a result, in order to port a real life application we sometimes ha
d

to
interfere with its nat
ural flow. Things tend to get tougher in case the application is already written in an
asynchronous design (
i.e.

the app queries the calendar content provider
from
in
side

the
OnActivityResult callback method).

As o
ne of our main goals was to make porting e
asy, we realized that we missed something along the
way. This meant that we had to
, once again,

go back to the planning phase, establishing where security
was critical, and where security failed in comparison to ease of use. After much planning, we came to

the conclusion that on several occasions, ContentProviders are the
more natural

choice of
implementation. This setback forced us to re
-
implement the relevant
services

using our new design.
After re
-
planning our design

we saw that the testing phase

(portin
g apps)

progressed more smoothly,
better suiting our success criteria, and
giving us confidence in the implementation we
decided
on.

In
other occasions,
we decided to keep
the services
as BroadcastReceivers.

S
everal services, however,
were not fit to be im
plemented as ContentProviders, as they were not
providing content. In addition, they required a GUI and therefore could not be implemented as
BroadcastReceivers. Therefore, these services were implemented as Activities. This implementation
was

not the most

ideal of solutions, since it still
use
d

an
asynchronous

model
, making it more difficult to
port applications

(once again undermining our success criteria)
. We believe that, given more time, we
could have found a more fitting design.

During the
entire
process described above
, we had to choose which services we wanted to implement.
Such a decision demanded thorough research on the
different permissions Android OS offers,
their
danger levels,
granularity
and
possible
malicious
scenarios.
T
hese permissions

also
had to correspond to
our statistics (i.e.
we
preferred

permissions that were widely used on real life applications
)
. The detailed
analysis of these
permissions and their implementation as services

is described in the attached file
“Declassifier Docum
entation.docx”.

With the final design of our solution, we continued to the final testing phase. That entailed porting open
source applications to use our declassifier and its services. Below is the list of ported applications:

SMS Popup


For use with the
Phone State declassifier

http://code.google.com/p/android
-
smspopup/

Auto Answer


For use with the Contacts declassifier.

http://code.google.co
m/p/auto
-
answer/

My Simple Notepad


For use with the External Storage declassifier.

http://code.google.com/p/my
-
simple
-
notepad/feeds

Wifi Compass


For use with the Wifi declassifier.

http://code.google.com/p/wificompass/

GVoiceMail


For use with the Voice Record declassifier.

http://code.google.com/p/gvoicemail/

This sits well with our

success criteria, as we managed to port an application for almost all of our
declassifier services. By using our declassifier, the above applications are now more secure and use a
finer grained permission mechanism. We managed to susta
in their original fu
nctionality. Moreover,
most of the applications we found suitable were,
after the design changes stated above
, rather easy to
port.

The only service we had trouble porting an application for is the Calendar. Please see the attached
“Progress Report.docx” f
or a detailed
explanation
why.

For a detailed guide on how to install and port the above applications, see the attached “Ported
Application Guides” files.



PART F: Appendix A


Implementing
Internet
Service in our Declassifier

Our project consisted of iterative steps. Along the way, we had some setbacks that required us to
reevaluate and re
-
implement some of our code. In addition, Android was new to us, and required
additional time to truly understand how to program in this lang
uage. The Internet declassifier, unlike the
rest of the declassifiers in this project, required more complex solutions in order to implement. Taking
the time constraints into consideration and our lack of knowledge, we were unable to complete the
Internet
declassifier. However, we believe that, given more time, such a declassifier is feasible. Below
we present a POC of how we planned on implementing the Internet declassifier.

In Android, 2 permissions are relevant to connecting to the internet:

1.

Android.perm
ission.ACCESS_NETWORK_STATE


Allows applications to access information
about networks (in other words, to know at any time the state of the device's connection to the
Internet).

2.

Android.permission.INTERNET


Allows applications to open network sockets.

Fo
r our project purposes, the first permission is less of an issue since it does not present a high risk
factor. Therefore, we leave this permission as is.

The second permission is of much importance and has critical security implications. When an applicatio
n
receives this permission, it can connect and disconnect from the internet whenever it chooses to. In
addition, there is no limitation to which domains it may connect to.

Our idea of a declassifier

for this service is to limit the application’s internet access to specific domains.
There are two ways of achieving this:

a.

The first way is to leave the decision to the user. Whenever an application tries to connect to a
URL address, a pop up screen appear
s, alerting the user of what site (URL) the app is trying to
connect to. The user now has the option of allowing to denying access.

b.


Another way is to limit the access to the internet by different parameters (such as address,
time, location etc).

Our decl
assifier permission will be defined as my.declassifier.INTERNET and it will work as follows:

1.

Upon installation, a 3
rd

party application requests this permission.

2.

When the application chooses to surf to a URL, it creates an intent and encapsulates in it the

action of the connecting to the web. In addition, it inserts its UID and the URL into the intent
(using the putExtra method).

3.

The declassifier receives the action using the intent
-
filter located in its manifest.

4.

The use of intent
-
filter filters out applic
ations that are not authorized to access the internet
(apps that were not granted the above permission).

5.

If authorized, the request now reaches the user. The popup screen starts and the user chooses
the relevant action.

6.

If the user accepts, the declassifi
er can now add the URL to the UID of the application and save
the mapping in a dictionary so next time the same request won’t need to start the popup screen
again. (NOTE: The dictionary
must

be highly protected, encrypted and secure). The popup
screen may
also include a checkbox that enables not saving the entries it already received (i.e.
"Remember My Decision", as we often see in Firewall products).

7.

The result of the declassifier will be caught by the 3
rd

party application implementing the
OnActivityResul
t method.

8.

If allowed to access to the URL, the application gets the Inputstream (using the getExtras
method) that opens above the declassifier’s connection and start receiving the stream.

Possible Issues:

We assume in this design that we can transfer an
InputStream from one process to
another. There is a possibility that in Android you are not allowed to do so.



PART F:
Appendix B
-

Resources and Knowledge



Android Dev Guide

-

http://developer.
android.com/guide/index.html




Java JDK Documentation
-

http://docs.oracle.com/javase/6/docs/api/




Android Application Development Tutorial
-

http://thenewboston.org/list.php?cat=6



iSEC
S
ecuring

A
ndroid

A
pps

-

https://isecpartners.com/files/isec_securing_android_apps.pdf



Android Development Tutorial (by Lars Vogel)
-

http://www.vogella.com/articles/Android



U
nderstanding
A
ndroid's
S
ecurity
F
ramework

(by William Enck and Patrick McDaniel)


http://siis.cse.psu.edu/slides/
android
-
sec
-
tutorial.pdf



The Effectiveness of Application Permissions (by Adrienne Porter Felt, Kate Greenwood, David
Wagner)
-

http://www.cs.be
rkeley.edu/~afelt/felt
-
permissions
-
webapps11.pdf



Google Code


http://code.google.com