Android Declassification Infrastructure: Final Report



Download 33.36 Kb.
Date30.06.2017
Size33.36 Kb.
#22161
TypeReport

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 become the world’s leading smartphone platform since the end of 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 use 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 3rd party applications that use it. This process of asking for high permission while exporting low permissions is called declassification. 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 almost 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. We carry them with us everywhere we go. We install different applications on our phone to help us with our daily activities and for our entertainment. It is quite clear that an 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 become 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 activations 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 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. In order for an app to address a hardware device it needs the appropriate permission. The app declares in its manifest file the permissions 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 access 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 more 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 "Choosers" API. Android, 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 open 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 declassification. Our infrastructure is a declassifier.

First, we had to identify the most commonly used Android permissions given to real life applications. In order to decide 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, we designed our declassifier so that it enables access to 6 different 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 application 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.permission.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 application 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 permissions 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 the content provider (described below). Each package afterwards includes code which is specific to the service it implements.

Content Provider

With 3rd party application developers 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 provides it to applications through the single ContentResolver interface.


When looking at the list of services we wanted to export, we decided that the Contacts, Calendar and PhoneState are all content providing services. Each of these services holds data that the 3rd party application 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 matches the custom permission allowing it to be used. 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 by 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.

The 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 Documentation.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 unsecure as anyone listening in can recognize them and use them. After 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 mechanism which allows sending back an answer privately.

We 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 BroadcastReceiver, 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 ExternalStorage 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 manipulate. 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 implement 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 be 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 screen). 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 these services the application has to send an Intent containing both the appropriate Action and parameters. The application should also provide an implementation of a callback method which is run 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”.

PARTS 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 section we will describe the progress we went through along the way to our final solution.

Firstly, we needed to recall the scope and objectives of our project:

To Enable safer application development.

3rd 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 Permissions Usage Statistics.xlsx”. In addition, we judged our success based on our ability to sustain the ported apps’ original functionality, while granting them lower permissions.

When first presented with this project we were unfamiliar with the Android environment and framework. This led us to design a solution based on Intents and activities. The solution required each application to send Intents to our declassifier. The declassifier, in return, supplied the service to the calling application and returned the results 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 easy to use and intuitive, Intents are also unsecure. 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 unsecure, any application 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, we started reading 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 that 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 2nd milestone and towards our 3rd, we designed our declassifier as described above, assured 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 complex. This did not stand in unison with our success criteria and was therefore problematic.

The cause of this complexity lied in the BroadcastReceiver’s asynchronous working model. That means that an app could ask for a declassifier service by using the SendOrderedBroadcast method which returned 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 had to interfere with its natural 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 inside the OnActivityResult callback method).

As one of our main goals was to make porting easy, 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 (porting 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.

Several services, however, were not fit to be implemented 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 used 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.

These 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 Documentation.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.com/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 sustain their original functionality. 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” for 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 language. 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.permission.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.

For 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 application 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:

  1. 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 appears, 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.

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

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

  1. Upon installation, a 3rd 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 applications 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 declassifier 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 3rd party application implementing the OnActivityResult 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 Securing Android Apps - https://isecpartners.com/files/isec_securing_android_apps.pdf

  • Android Development Tutorial (by Lars Vogel) - http://www.vogella.com/articles/Android

  • Understanding Android's Security Framework (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.berkeley.edu/~afelt/felt-permissions-webapps11.pdf

  • Google Code – http://code.google.com

Download 33.36 Kb.

Share with your friends:




The database is protected by copyright ©ininet.org 2024
send message

    Main page