DELDroid: Determination & Enforcement of Least Privilege Architecture in AnDroid
•
1 like•923 views
Android is widely used for the development and deployment of autonomous and smart systems, including software targeted for IoT and mobile devices. Security of such systems is an increasingly important concern. Android relies on a permission model to secure the system's resources and apps. In Android, since the permissions are granted at the granularity of apps, and all components in an app inherit those permissions, an app's components are over-privileged, i.e., components are granted more privileges than they actually need. Systematic violation of least-privilege principle in Android is the root cause of many security vulnerabilities. To mitigate this issue, we have developed DELDroid, an automated system for determination of least privilege architecture in Android and its enforcement at runtime. A key contribution of DELDroid is the ability to limit the privileges granted to apps without modifying them. DELDroid utilizes static analysis techniques to extract the exact privileges each component needs. A Multiple-Domain Matrix representation of the system's architecture is then used to automatically analyze the security posture of the system and derive its least-privilege architecture. Our experiments on hundreds of real-world apps corroborate DELDroid's ability in effectively establishing the least-privilege architecture and its benefits in alleviating the security threats.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to DELDroid: Determination & Enforcement of Least Privilege Architecture in AnDroid
Similar to DELDroid: Determination & Enforcement of Least Privilege Architecture in AnDroid (20)
Recently uploaded
Recently uploaded (20)
DELDroid: Determination & Enforcement of Least Privilege Architecture in AnDroid
- 1. DELDroid: Determination & Enforcement of Least Privilege Architecture in AnDroid Mahmoud Hammad Software Engineering Ph.D. Candidate Mahmoud Hammad, Hamid Bagheri, and Sam Malek IEEE International Conference on Software Architecture (ICSA 2017) Gothenburg, Sweden, April 2017. 3/22/2017
- 2. 2 Android in the market Source: International Data Corporation (IDC)
- 3. Source: Statista Number of apps in Google Play store 3
- 4. Not as rosy as it may seem Source: NOKIA Threat Intelligence Report 4 Androidmalwaresamples
- 5. Over-privileged resource access 5 Implicit Intent ComposerSender ListMsgs Activity Service FunGame LevelUp Messaging Main Explicit Intent Legend SMS permission Location permission Private component <<Android system>>
- 6. Over-privileged Inter-Component Communication 6 Implicit Intent ComposerSender ListMsgs Activity Service FunGame LevelUp Messaging Main Explicit Intent Legend SMS permission Location permission Private component <<Android system>>
- 7. Research problem Components are over-privileged and violate the Least Privilege (LP) principle 7
- 8. LP in Android documentation The Android system implements the principle of least privilege. That is, each app, by default, has access only to the components that it requires to do its work and no more. This creates a very secure environment in which an app cannot access parts of the system for which it is not given permission. Android security mechanisms treat apps as the minimum security entities 8
- 9. Security Consequences • Hard to comprehend the security posture of an Android system • Increases the attack surface • Cause many security vulnerabilities • Privilege escalation attack • Hidden Inter-Component Communication (ICC) attack 9
- 10. FunGame Privilege Escalation Attack 10 ComposerSender ListMsgs LevelUp Messaging Main Implicit Intent Activity ServiceExplicit Intent Legend ix Intent SMS permission Location permission i1 i2 i3 // If (checkCallingPermission ("android.permission.SEND_SMS") == PackageManager.PERMISSION_GRANTED)
- 11. Hidden ICC Attack 11 ComposerSender ListMsgs FunGame LevelUp Messaging Main Implicit Intent Dynamically Loaded Code Activity ServiceExplicit Intent ix Intent SMS permission Location permission <<external>> i1i3 i2 Private component Legend
- 12. Outline Approach Experimental Results Threats & Conclusion 12
- 13. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 14. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 15. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 16. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 17. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 18. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 19. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 20. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 21. Android apps • Each Android app, APK file, includes • configuration file called manifest file • App’s bytecode • The manifest file specifies: • principal components that constitute the app • provided interface, i.e., Intent Filters • required permissions • enforced permissions • Bytecode contains among other things: • App’s business logic • Components communications • Enforced permissions 21
- 22. Step 1: Architectural Elements Extractor ID App Component Type Exported Intent Permissions Intents Name Filter Granted Used Enforced 1 Messaging ListMsgs Activity Yes {SMS} 2 Messaging Composer Activity Yes {SMS} {i1} 3 Messaging Sender Service Yes SEND_SMS {SMS} {SMS} 4 FunGame LevelUp Service No {Location} 5 FunGame Main Activity Yes MAIN {Location} {i2} 22
- 23. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 24. Multiple Domain Matrix (MDM) • MDM models a complex system with multiple domains • Each domain is modeled as a Design Structure Matrix (DSM) • DSM and MDM are very effective in capturing and analyzing the architecture of a complex system 24
- 25. Multiple Domain Matrix (MDM) Design Structure Matrix (DSM) Task 1 Task 2 Task 3 A system with three tasks Task 1 Task 2 Task 3 Task-to-person relationship P1 P2 MDM captures the architecture P1 P2 1 1 1 1 25 Task1 Task2 Task3 Task 1 1 Task 2 1 Task 3 1 Task1 Task2 Task3 Task 1 1 Task 2 1 Task 3 1
- 27. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 29. Original vs. LP architectures 29 Original Architecture LP Architecture
- 30. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 31. • Let us assume LevelUp does not use dynamic class loading Privilege escalation analysis 31
- 32. • DELDroid marks 𝑐𝑜𝑚𝑚𝑢𝑛𝑖𝑐𝑎𝑡𝑒 𝐿𝑒𝑣𝑒𝑙𝑈𝑝 , 𝑆𝑒𝑛𝑑𝑒𝑟 as a potential privilege escalation attack Privilege escalation analysis 32 LP Architecture
- 33. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 34. Communication ECA rule example 𝑬𝒗𝒆𝒏𝒕: 𝑖 ∈ 𝐼𝐶𝐶 𝑜𝑐𝑐𝑢𝑟𝑠 𝑪𝒐𝒏𝒅𝒊𝒕𝒊𝒐𝒏: 𝑖. 𝑠𝑒𝑛𝑑𝑒𝑟𝑃𝑘𝑔 = 𝐹𝑢𝑛𝐺𝑎𝑚𝑒 ∧ 𝑖. 𝑠𝑒𝑛𝑑𝑒𝑟𝐶𝑜𝑚𝑝 = 𝐿𝑒𝑣𝑒𝑙𝑈𝑝 ∧ 𝑖. 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑟𝑃𝑘𝑔 = 𝑀𝑒𝑠𝑠𝑎𝑔𝑖𝑛𝑔 𝑨𝒄𝒕𝒊𝒐𝒏: 𝑝𝑟𝑒𝑣𝑒𝑛𝑡 34
- 35. Resource access ECA rule example 𝑬𝒗𝒆𝒏𝒕: 𝑟𝑒𝑠𝑜𝑢𝑟𝑐𝑒𝐴𝑐𝑐𝑒𝑠𝑠𝑅𝑒𝑞𝑢𝑒𝑠𝑡 𝑪𝒐𝒏𝒅𝒊𝒕𝒊𝒐𝒏: 𝑟𝑒𝑞𝑢𝑒𝑠𝑡𝑒𝑟 = 𝐿𝑒𝑣𝑒𝑙𝑈𝑝 ∧ 𝑠𝑒𝑟𝑣𝑖𝑐𝑒 =Context.LOCATION_SERVICE 𝑨𝒄𝒕𝒊𝒐𝒏: 𝑝𝑟𝑒𝑣𝑒𝑛𝑡 35
- 36. DELDroidDesigntime ECA Rules Original Architecture LP Architecture Resource Monitor ICC Monitor Architectural Elements 5. LP Enforcer 4. Security Analyzer 1. Architectural Elements Extractor 3. Privilege Reducer Android Apps Layer System Resources 2. Privilege Analyzer ~~~ ~~~ ~~~ ~~~~ ~~~~~ ~~~~~ Analysis Result A,~~~ B,~~~ C,~~~ DELDroid Step Resource request ICC Repository DELDroid transaction Legend APKs Privilege Manager Layer Runtime
- 37. Outline Approach Experimental Results Threats & Conclusion 37
- 38. Implementation details • DELDRoid is a Java application • input : set of apps • output: LP architecture and ECA rules • The enforcement mechanism implemented in the AOSP version 6 (Marshmallow) • Privilege Manager introduced a new package in the Android runtime • This package does not affect the existing apps • Other components are modified such as ActivityManager and ContextWrapper • Installed on Android emulator and Nexus 5X phone 38
- 39. Evaluation • RQ1: How effective is DELDroid in reducing the attack surface? • RQ2: How effective is DELDroid in detecting and preventing attacks in real-world apps? • RQ3: What is the performance of DELDroid? 39
- 40. Evaluation setup Dataset Apps Benign 370 Vulnerable 335 Malicious 225 Malicious Dataset Malgenome Brain Test AndroTotal Contagio Dataset Apps Distribution 40 Benign 40% Vulnerable 36% Malicious 24%
- 41. Bundle Apps Components Intent Intent Explicit Implicit Filter Bundle 1 30 306 344 79 176 Bundle 2 30 432 468 379 287 Bundle 3 30 422 574 212 200 Bundle 4 30 449 348 370 511 Bundle 5 30 353 304 277 292 Bundle 6 30 541 890 476 4919 Bundle 7 30 562 412 38 324 Bundle 8 30 362 417 267 242 Bundle 9 30 265 180 98 166 Bundle 10 30 421 322 1231 185 Average 30 411.3 425.9 342.7 730.2 Avg. (per app) 13.7 14.2 11.4 24.3 RQ1: Attack surface reduction 41
- 42. Bundle Components Intent Intent Communication Domain Explicit Implicit Filter Original LP Reduction (%) Bundle 1 306 344 79 176 29,031 42 99.86 Bundle 2 432 468 379 287 78,237 625 99.20 Bundle 3 422 574 212 200 65,709 173 99.74 Bundle 4 449 348 370 511 80,372 205 99.74 Bundle 5 353 304 277 292 56,868 345 99.39 Bundle 6 541 890 476 4919 85,556 661 99.23 Bundle 7 562 412 38 324 82,863 137 99.83 Bundle 8 362 417 267 242 50,208 250 99.50 Bundle 9 265 180 98 166 25,817 129 99.50 Bundle 10 421 322 1231 185 50,001 74 99.85 Average 411.3 425.9 342.7 730.2 60,466.2 264.1 99.58 Avg. (per app) 13.7 14.2 11.4 24.3 2,015.5 8.8 99.56 RQ1: Attack surface reduction – communication 42
- 43. Bundle Components Intent Intent Permission Granted Domain Explicit Implicit Filter Original LP Reduction (%) Bundle 1 306 344 79 176 1,642 45 97.26 Bundle 2 432 468 379 287 2,954 61 97.94 Bundle 3 422 574 212 200 2,510 54 97.85 Bundle 4 449 348 370 511 4,234 78 98.16 Bundle 5 353 304 277 292 1,536 51 96.68 Bundle 6 541 890 476 4919 4,461 181 95.94 Bundle 7 562 412 38 324 1,577 58 96.32 Bundle 8 362 417 267 242 1,946 24 98.77 Bundle 9 265 180 98 166 1,568 30 98.09 Bundle 10 421 322 1231 185 2,386 28 98.83 Average 411.3 425.9 342.7 730.2 2,481.4 61.0 97.58 Avg. (per app) 13.7 14.2 11.4 24.3 82.7 2.0 97.54 RQ1: Attack surface reduction - permission 43
- 44. Bundle Components Intent Intent Priv. Esca. Security Analysis Explicit Implicit Filter Original LP Bundle 1 306 344 79 176 25,944 0 Bundle 2 432 468 379 287 35,601 110 Bundle 3 422 574 212 200 22,721 2 Bundle 4 449 348 370 511 33,551 0 Bundle 5 353 304 277 292 26,914 2 Bundle 6 541 890 476 4919 24,745 2 Bundle 7 562 412 38 324 15,503 1 Bundle 8 362 417 267 242 27,663 14 Bundle 9 265 180 98 166 19,428 8 Bundle 10 421 322 1231 185 16,953 3 Average 411.3 425.9 342.7 730.2 24,902.3 14.2 Avg. (per app) 13.7 14.2 11.4 24.3 498.0 0.3 RQ1: Attack surface reduction – potential attacks 44
- 45. RQ2: Attacks detection and prevention • 54 malicious and vulnerable apps • The steps and inputs required to create the attacks are known • The dataset contains • 18 privilege escalation attacks • 24 hidden ICC attacks through dynamic class loading • Detection: DELDroid analyzes the derived LP architecture • Prevention: manually exercise the apps to create the attacks 45
- 46. RQ2: Privilege escalation detection results 46 TP Malicious behavior detected (18) FP Benign behavior detected (1) FN Malicious behavior not detected (0) • 18 privilege escalation Precision ( ) = 94.74% Recall ( ) = 100%
- 47. RQ2: Attacks prevention 47 TP Malicious behavior prevented (42) FP Benign behavior prevented (1) FN Malicious behavior allowed (0) • 18 privilege escalation • 24 hidden ICC attacks • 42 attacks Precision ( ) = 97.76% Recall ( ) = 100%
- 48. • Execution time of running DELDroid on the 10 bundles, repeated 33 times RQ3: Performance – design time Recovery (min) LP Determination (sec) Analysis (sec) ECA Rules (sec) Average per bundle 69.5 ± 2.7 1.61 ± 0.69 0.002 ± 0.001 0.45 ± 0.99 48
- 49. • A script that sends 363 requests to an Android system • Each request causes the system to perform an ICC transaction • On average, DELDroid takes 25 ± 10 milliseconds to check an intercepted ICC RQ3: Performance – run time 49
- 50. Outline Approach Experimental Results Threats & Conclusion 50
- 51. Threats to validity • Not all hidden ICC communications are malicious • Previous study proposed a technique that check the integrity of the loaded code [1] • Static analysis tools cannot effectively analyze obfuscated apps • integrating dynamic analysis techniques [1] S. Poeplau et al. Execute this! analyzing unsafe and maliciousdynamic code loading in android applications. In NDSS, SanDiego, California, February 2014. 51
- 52. Conclusion • DELDroid is an automated approach for determining and enforcing the LP architecture for an Android system • The LP architecture narrows the attack surface and thwarts certain security attacks • Experimental results show • between 97% to 99% attack surface reduction • detecting and preventing security attacks (97% precision and 100% recall) • negligible runtime performance overhead 52
Editor's Notes
- In this presentation, I will talk about DELDroid, our automated system for determination and enforcement of least privilege architecture in Android.
- As you may know, Android is the most predominant mobile platform with 87% market share. Which means 87% of the smarphone users are running Android platform.
- One of the main reasons that people are attracted to smartphone devices is the abundant number of apps in the app stores. For example, Google play app store contains more than 2.6 million apps as of Dec. 2016, and there are numerous other app stores.
- Unfortunately, the number of malicious Android apps is increasing exponentially, as you can see in this figure. In fact, Android platform is the most targeted mobile platform not only because of its popularity, it is one reason, but also because the Android platform is not secure enough.
- I am saying that because, if you, as a user, installs an Android application, such as Messaging app or FunGame app, each app consists of several components, different screens, called Activities in Android, different services that run in the background, or different database components. If an app asks for permissions to access the various system resources, such as SMS permission in the messaging app or Location permission in the FunGame app, Android grants permissions at the granularity of applications. Therefore, all components in an application are granted the same permissions that are granted to their parent application. Keep in your mind that, not all components in an app are developed by the app’s developer. For example, if an app includes an advertisement library, payment processing library, or social networking library, these libraries they add components to the app, yet Android treats all components in an app alike and grant them the same permissions that are granted to their parent app. Therefore, almost all components have more permissions than they actually need. They can use these permissions to access the various system resources. So, this is the first issue, that components have more permissions than they actually need.
- The second issue is that, Android promotes component-based development in which components can communicate with one another either inside one app or across apps with no restrictions in most cases. As long a component is not set to private, all components from various apps can communicate with it. Components can communicate with one another using event messages called Intents. Either explicit Intent, in which the target component is explicitly specified or implicit Intent in which the action to be performed is specified. For example, a component can send an implicit Intent to all components that can open html file or play a music file. Again, since Android grants privileges at the granularity of apps, almost all components have more communication privileges than they actually need. So we have these two issues, components have more permissions than they actually need, and components have more communication privileges than they actually need. And These two issues form our research problem.
- Which is components are over-privileged and violate the well established least-privilege security principle. This security principle promotes for granting each component that exact privileges it needs to fulfil its task.
- This shows that Android security mechanisms treat applications as the minimum security entities and cannot distinguish between their components. https://developer.android.com/guide/components/fundamentals.html
- This systematic violation of least privilege security principle has many security consequences. among them, it makes comprehending the security posture of an Android system tedious and error prone, not only for a security architect, but also for security analysis tools that need to examine all possible communications and all allowed permissions in an Android system to understand the risk it poses. Also, it increases the attack surface of an Android system. So if a component is compromised, the impact might be severe due to the extra privileges that component has. Moreover, this violation is the root cause of many security vulnerabilities such as privilege escalation attack and hidden Inter-Component-Communication ICC attacks. In the next two slides, I will describe each vulnerabilit individually.
- Privilege escalation or permission re-delegation is an attack in which a component performs a privileged task on behalf of an unprivileged component. In Android, a component can define its provided capabilities using an object called Intent filter. For example, a component can say I can send a text message or I can open html file, etc. And Android uses these information to match the implicit Intent with the component that can handle it. In this Android system, the Sender component provides an interface to send text messages upon receiving an Intent from another component. So, once Sender receives Intent i1, it extracts the phone number and the message body and uses the SMS permission to send a text message. In this system, the Sender service is a vulnerable component in which it does not check if the calling component has SMS permission before sending a text message. So this is the missing code in this service. In this situation, another component such as LevelUp can communicate with the Sender using implicit Intent i3 to send a text message without having an SMS permission. This communication results in leaking the user’s location to a premium rate number.
- A more sophisticated attack is the hidden ICC attack. Instead of LevelUp directly communicating with the Sender to send a text message, it can leverage a dynamic class loading feature which allows LevelUp to download a JAR file from external sources, such as SD card or remote web server, then LevelUp can load and executes the contained codes in that JAR file. So the loaded code can use the location permission to determine the user’s location and creates an implicit Intent, i3, that LevelUp can use to communicate with the Sender service. Again, the LevelUp can send text messages to any premium rate number without having SMS permission. This hidden ICC attack is not detected by static analysis tools, the tools that analyze applications source code or bytecode without running them, since the code that allows LevelUp to communicate with Sender is not part of the FunGame app, neither its source code nor its bytecode. Additionally, dynamic analysis techniques, the techniques that run and monitor the execution of the applications, cannot effectively detect such vulnerability, especially if the app incorporates complicated evasion tactics such as timing-bombs. Execute the malicious code on Saturday at 3am. In this presentation, I will use this Android system as a running example to illustrate
- our approach and then present experimental results of DELDroid and conclude the presentation.
- This figure depicts our approach, DELDroid, an automated system for determination of least-privilege architecture, an architecture that grants each component the exact privileges it needs to fulfill its task, then it enforces it at runtime. Our approach consists of 5 steps:
- the first step takes a set of Android apps packages, APK files, and statically extracts information from them
- the second step derives the original system architecture, an architecture that shows the current privileges each component has as allowed or as permitted by Android platform. The permissions that each component is granted and the communication privileges each component has.
- the third step determines the exact privileges each component needs to fulfil its task and models that in an architecture called least-privilege architecture
- The fourth step analyzes the security posture of the Android system in light of the determined LP architecture to check if the system is vulnerable to privilege escalation attacks and reports that. Then, a security architect can further adapt or modify the determined architecture.
- LP Enforcer transforms the determined least-privilege architecture to a set of Event-Condition-Action rules. Each rule reads as follows: when an event occurs, check a condition, if it holds, executes the action.
- Then our Privilege Manager layer in our modified version of Android enforces the ECA rules at runtime. Now let’s see how each step works in light of our running example.
- Again, the first step takes a set of Android applications’ packages or APK files and leverages several static analysis tools to extract information from these applications.
- Each Android package or APK file contains a configuration file called manifest file and the app’s bytecode. The manifest file contains information about the components in the app, their properties such as their types and the capabilities that each component defines using Intent Filters, and the permissions that the application asks for. So, in our example, the Messaging app is granted the SMS permission and all of its components are granted it as well. Same thing for the FunGame application. The bytecode contains information about the used permissions, for example, the Sender service uses the SMS permission through calling the sensitive SMS APIs. Therefore, the Sender service uses the SMS permission. The enforced permissions are the permissions that a component requires from the calling components to have. Remember the checkCallingPermisssion API, if the Sender service used that code, the SMS permission would be an enforced permission by the Sender service. And also there is another way of enforcing permissions in Android in which an app can create a permission and uses that permission for self-protecting. In our running example none of the components is enforcing a permission and hence this domain is empty. In addition to that, this step extracts the latent Intents in the app’s bytecode. Therefore, Intent i1 and i2 are statically extracted from the app’s bytecode and placed in this table. Notice that neither the location permission usage nor the Intent i3 are statically extracted since they are not part of the app’s bytecode. They are part of the dynamically loaded code and hence they are not part of this table. The ID column in this table contains auto generated numbers for later use.
- This step analyzes the privileges each component has in terms of permissions it has and communication privileges it has, and it represents that in an architecture called the original system architecture. So this architecture shows how Android manages the components’ privileges. Our approach uses Multiple Domain Matrix to model the architecture.
- MDM is a matrix representation of a complex system with multiple domains. Each domain is modeled as Design Structured Matrix or Dependency Structure Matrix DSM. DSM and MDM are very effective tools in capturing and analyzing the architecture of a complex system. Let’s see an example.
- Suppose that we have this system that consists of three tasks where task 1 depends on Task 2, Task 2 depends on Task 3, etc. We can represent this system using DSM where each non-empty cell represent a dependency between the element in the row to the element in the column. Now, if we need to model another domain in this system, where a task is assigned to a person, for example Task 1 is assigned to person 1, task 2 is assigned to both person 1 and 2, in this case, we can use a MDM to represent the system with two domain. So in our approach we borrowed this concept to represent the architecture of an Android system with multiple domains.
- Regarding to our running example where by default all components in an app are granted the same permissions that are granted to their parent apps and components can communicate with one another, this would be the derived original architecture represented as MDM with 4 domain. The communication domain shows that the component in the row is allowed to communicate with the component in the column. Permission granted domain shows the granted permissions for each component. Since all components in an app are granted the same permissions, all components in the Messaging app are granted the SMS permissions. The permission usage are the directly used permissions by each component and the permission enforcement domain are the enforced permissions by each component as described in the table of the first step.
- Privilege Reducer step determines the exact privileges each component needs to fulfil its task and models that in an architecture called LP architecture in a MDM.
- For our running example, this is the determined LP architecture. The communication domain shows the needed communications that each component needs as determined by the Intents that each components creates and uses. For example, the Composer component is allowed to communicate with the Sender component since there is an Intent, i1. Same thing for the communication between Main and LevelUp. Notice that, the communication between LevelUp and Sender is not part of the LP architecture since the code that creates the Intent, i3, is not part of the FunGame’s bytecode. Permission granted domain shows the granted permissions for each component. Sender component is granted the SMS permission since it uses this permission to send text messages. On the other hand, Composer component is granted this permission since it communicates with the Sender that uses this permission and its app, Messaging app, is granted this permission. In this case, the Composer component has a legitimate reason to hold this permission.
- So what DELDroid did so far, it derived the original architecture and determined the LP architecture of an Android system. As you can see it reduced both the communication domain and the permission granted domain.
- Now, once DELDroid determined the LP architecture, the next step, Security Analyzer, analyzes the architecture for any potential privilege escalation attacks and report them, so a security architect can further manages the privileges. It worths mentioning that DELDroid can be configured to remove any communication marked as potential privilege escalation attack until a security architect decides otherwise.
- As a concrete example, let’s assume that LevelUp does not use dynamic class loading to communicate with the Sender component, instead it creates an implicit Intent and uses it to communicate with the Sender to leak the user’s location via a text message. In this case, the Location usage and the Intent i3 is part of the FunGame’s bytecode and hence it is statically extracted.
- This architecture would be the determined LP architecture for this Android system. The LP architecture allows the LevelUp to communicate with the Sender and grants LevelUp the location permission. Now, the LP Analyzer step automatically checks each communication and once it sees that there is a communication between LevelUp and Sender, in which Sender uses SMS permission without enforcing it and LevelUp does not have this permission, it marks this communication as potential privilege escalation attack. Then a security architect can further adapt or modify the architecture.
- Once the LP architecture is determined, this step transforms the architecture to a set of Event-Condition-Action or ECA rules that capture the architecture.
- Back to our running example where LevelUp uses dynamic class loading to conduct a hidden ICC attack. For this Android system, this is the determined LP architecture. Since LevelUp is not allowed to communicate with all components in the Messaging application, this step creates this ECA rule that prevents LevelUp from communicating with all components in the Messaging app. So, enforcing this ECA rule at runtime would prevent LevelUp from communicating with the Sender service and hence preventing the hidden ICC attack.
- Similarly, the LevelUp is not granted the Location permission in this architecture, therefore, this step creates this ECA rule that would prevent LevelUp from accessing the Location service.
- The generated ECA rules are enforced using the Privilege Manager Layer, a layer that we have added to the Android platform. This layer contains two components and the ECA rules repository. ICC Monitor component intercepts each ICC transaction and vet it against the stored ECA rules. Resource Monitor component intercepts each resource access request and checks it the requester component has a permission to access the requested resources.
- Let’s take a look at the DELDroid’s evaluation results.
- We have implemented DELDroid as a java application that takes a set of Android apps as input and generates a LP architecture and a set of rules that capture the architecture. The enforcement mechanisms implemented in the AOSP version 6. The privilege manager introduces a new package but this package does not affect the existing apps. Finally, we have successfully installed our modified Android version on Android emulator and Android Nexus 5X device.
- (S36) Our evaluation address these thre research questions. (1) The effectiveness of DELDroid in reducing the attack surface, (2) the ability of our approach in detecting and preventing security attacks, and (3) the performance overhead of our DELDroid
- To perform the evaluation, we have downloaded apps from various repositories as you can see from the upper table. 370 benign apps from Google play store; 335 vulnerable apps identified by a previous study, and 225 malicious apps drawn from various repositories shown in the green table.
- To answer the RQ1, we created 10 bundles each containing 30 randomly selected apps from the 3 datasets. Each bundle contains 24 benign, 3 malicious, and 3 vulnerable apps. This table shows the structure of each bundle in terms of the number of components, Intents, and Intent Filters.
- This table shows the attack surface reduction in the communication domain. For example, the possible communications in Bundle 1 is 99% reduced from over 29K to only 42 inter app communications (IAC).
- Similarly, the permission granted domain is also reduced by 97%.
- As I presented before in step 4, once the LP architecture is determined, DELDroid analyzes it for any potential privilege escalation vulnerabilities. This table depicts the number of the potential privilege escalation vulnerabilities in bith, the original and the LP architectures. For example, in Bundle 5, there are more than 26 thousand potential privilege escalation vulnerabilities and only 2 of them are in the LP architecture. These numbers show the effectiveness of our approach in reducing the attack surface of Android system.
- To answer the second research question, we used 54 apps with known vulnerabilities and the steps to generate the attacks. The dataset contains 18 privilege escalation attack and 24 hidden ICC attacks. We manually checked and confirmed the correctness of their implementation. For the determination, DELDroid determined and analyzed the LP architecture for this dataset and reported the detected potential privilege escalation attacks. For the prevention study, we manually installed these apps and exercised them while enforcing the determined LP architecture to see if DELDroid prevented the attacks or not.
- DELDroid detected 19 communications as privilege escalation attacks. 18 of them are true positive and 1 is false positive. Our manual inspection of the FP case showed that this was due to the shortcomings of the used static analysis tools. In particular, since the static analysis tools we relied upon are not path sensitive, they tend to over-approximate the behavior of Android architecture and hence leads to such FP. Overall, the precision is 94.7% and the recall is 100%
- Remember we have 18 privilege escalation attacks and 24 hidden ICC attacks, so the total is 42 attacks. DELDroid prevented all the 19 detected privilege escalation attacks and all the 24 hidden ICC attacks. Therefore, the precision is 97.7% and 100% recall. These high accuracy numbers show the ability of our approach in detecting and preventing certain security attacks.
- Last experiment, we measured the performance of DELDroid. We ran this experiment on the 10 bundles repeated 33 times to achieve high confident. On average, it takes about 70 minutes to statically analyze the apps and determines the LP architecture. The vast majority of the time is spent in the static analysis tools.
- For measuring the runtime performance overhead, we sent 363 request to an Android system, each request causes the system to perform an ICC transaction of some sort, then we measured the time it takes to check each ICC transaction. On average, it takes 25 milliseconds. This time cannot perceive as delay by the users, as Android documentation stated that the user starts noticing delays after 100-200 ms. These experimental results corroborate DELDroid’s effectiveness in reducing the attack surface and its ability to detect and prevent security attacks in a negligible time.
- Some limitation of DELDroid: not all hidden ICC communication are malicious, although a previous study showed that benign developers, even for the top 50 apps, are not infallible of mistakenly use this feature such as downloading a code from http servers rather than https. They proposed an enhancement to the Android kernel to check the integrity of the loaded code before executing it. So we can integrate such a technique in our approach. Our approach also has some limitations inherited from the use of of the static analysis tools such as their ineffectiveness to analyze an obfuscated code. Therefore, we are planning to integrate dynamic analysis approaches to discover the architecture.
- I have presented DELDroid, an automated system for determining and enforcing the least privilege architecture of an Android system without the need to modify the apps. Our experimental results show the effectiveness of our approach in reducing the attack surface and the ability of our approach in detecting and preventing certain security attack in a negligible time. Moreover, our approach allows a security architect to adapt or modify the architecture and enforces it while the system is running.