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 security 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 literature 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 unauthorized 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 activated 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 the 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 processing 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. When 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 Android 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 events 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 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 such as network connectivity, phone calling applications, reading or writing 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 for 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 communication 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 component 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 involved 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 of the vulnerability, using the application’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 readers 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 Systems 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.android.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 experiment [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 no intent filters and no permission enforcement.
“Callee app” has intent filters but no permission enforcement.
“Callee app” has intent filters and permission enforcement.
AppC has sanctioned internet capabilities and demonstrates this with the launch of the device’s Browser application. A custom permission, LAUNCH_CUSTOM_BROWSER, was eventually declared and enforced.
AppB has sanctioned permissions to launch AppC. An attempt to do this explicitly failed but 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 AppC 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 below shows which caller apps were able to activate the “callee” applications with the given conditions:
| “Callee” | No intent filter and no perm. enfrcmt. | With intent filter but No perm. enfrcmt. | With intent filter and perm. enfrcmt. |
| 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 respective 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 AndroidManifest.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 from 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 protect 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 already 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-permitted 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 security policies and the use of reference monitors.
7. References
[1] “Security and Permission.” Android Developer’s Framework Topics. http://developer.android.com/guide/topics/security/security.html#arch. [Accessed Dec. 5, 2010].
[2] “Application Fundamentals.” Android Developer’s Framework Topics. http://developer.android.com/guide/topics/fundamentals.html [Accessed Dec. 5, 2010].
[3] Fonoage, Mihai. “Application Components and Lifecycle.” Android Fundamentals Course Module. http://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/manifest-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/DDSW10/. [Accessed Dec. 5, 2010].
[6] “Intents and Intent Filters.” Android Developer’s Framework Topics. http://developer.android.com/guide/topics/intents/intents-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_Android_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.android.com/apk/res/android"
package="c_harley.securityexperiment01.appC" android:versionCode="1"
android:versionName="1.0">
<application android:icon="@drawable/icon" android:label="@string/app_name">
<activity
android:name=".Main"
android:label="@string/app_name"
android:permission="c_harley.securityexperiment01.appC.permission.ACCESS_INTERNET">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
intent-filter>
<intent-filter>
<action android:name="c_harley.securityexperiment01.LAUNCH_CUSTOM_BROWSER" />
<category android:name="android.intent.category.DEFAULT" />
intent-filter>
activity>
application>
<permission
android:name="c_harley.securityexperiment01.appC.permission.ACCESS_INTERNET"
android:label="@string/permlab_accessInternet"
android:permissionGroup="android.permission-group.NETWORK"
android:description="@string/permdesc_accessInternet"
android:protectionLevel="dangerous" /><uses-permission android:name="android.permission.INTERNET">uses-permission>
manifest>
No comments:
Post a Comment