Cot5930 Security for Wireless Systems Fall ‘10 Research Project Report
Download 34.18 Kb.
|
- Navigate this page:
- 1. Introduction
- 1.2. Permissions as a Mandatory Access Control Mechanism
- 1.3. Intents and Intent Filters
- 2. Related Work
- 5. Discussion
- 6. Conclusion
- 7. References
- 8. Appendices
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 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. IntroductionThis 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 ComponentsThe 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]:
1.2. Permissions as a Mandatory Access Control MechanismAndroid 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 FiltersIn 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 WorkSome 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. MethodsThis 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:
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. ResultsBoth “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:
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. DiscussionThe 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. ConclusionThis 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. AppendicesThis section contains all of the documents relevant to the experiment and research of this paper. 8.1. Example of Declaring and Enforcing Permissionspackage="c_harley.securityexperiment01.appC" android:versionCode="1" android:versionName="1.0">
android:name=".Main" Directory: wp-content -> uploads -> 2010 2010 -> Hr 116 Application for Employment with Hills and Dales 2010 -> Polimaster ltd V. Rae systems inc polimaster ltd.; Na&se trading co., Limited, Plaintiffs-Appellants 2010 -> The game a morality play in one act by Louise Bryant 2010 -> Seamheads at sabr 40 2010 -> Curriculum vitae 2010 -> Mid atlantic coaching clinic 2010 -> The Case for Integrating Crisis Response with Social Media Chapter One: Introduction 2010 -> Press pack shamrock Bowl XXIV american football – Tallaght Stadium 2010 -> Andy Northedge1 2010 -> Partnership Brokers Training Download 34.18 Kb. Share with your friends:
|