Detecting and Preventing Privilege-Escalation on Android

1. Detecting and Preventing Privilege-Escalation on Android Jiaojiao Fu

2. outline • Importance & Seriousness • Android security mechanisms • Security risks • Related work • Our work • Conclusions

3. Importance • More serious malware threats • Suspicious samples increasing rapidly Growth trend of total Android suspicious samples Malware Threats to Mobile OSs

4. Security mechanisms • Two main Android security mechanisms • Sandbox • Permission

5. Permission • 2 types • Provided by Android OS • Defined by apps • 4 protection levels • Normal: low risk, automatically grant • Dangerous: higher-risk ask for user’s explicit approval • Signature: only apps with the same certificate • signatureOrSystem

6. ICC: inter-component communication • Components • Activities • Services • Broadcast receivers • Content providers • Intents-communication way of components within or across applications • Explicit intents-specified a component • Implicit intents-not specified a component

7. Android specific security risks • Confused deputy • Collusion attacks

8. Confused deputy • What is it? • Hard to avoid: • Expose by default • undertrained developers • Example Component expose Component hijack Service perm Receiving external requests Permissions: read_contacts internet Contact manager app

9. Collusion attacks • What is it？ • Two or more apps cooperate purposely to achieve privilege escalation • Type 1 : ICC Sandbox Sandbox Sandbox App a Permissions: - App bpermission:p1 App c Cc1 Cc2 Ca1 Ca2 Cb1 Cb2 p2 p1 √ allowed √ allowed √ allowed ×not-allowed

10. Collusion attacks-type 2 • Type 2 • Indirect communication : system components and file systems • Example • Covert channels • Vibration settings • Volume settings • Screen • File locks • ··· Collection app Deliver app Notification broadcast

11. How to solve these two specific android security risks: confused deputy and collusion attacks?

12. Related work • 1. CHEX: statically vetting Android apps for component hijacking vulnerabilities【CCS’12】 • 2. Towards Taming Privilege-Escalation Attacks on Android【NDSS’12】 • 3. Flexible and Fine-Grained Mandatory Access Control on Android for Diverse Security and Privacy policies【USENIX’13】

13. CHEX: statically vetting Android apps for component hijacking vulnerabilities • Detecting the possibility of confused deputy • Static analysis method Figure 1: CHEX workflow

14. CHEX-limitations • Static method-not comprehensive • only Dalvikcode • no NDK- otherprogramming language • Detecting component hijecking vulnerabilities • No other kinds of permission escalation

15. Previous work-2&3 • Taming privilege-escalation attacks on android with diverse security and privacy policies • Methodology Android framework Service hook Policy Self-defined Content provider hook Privilege escalation or not Linux kernel system hook（filesystem，···）

16. Previous works-2&3-limitations • complexity, can’t be used in the wild • Self-defined policies • May be wrong: an app-phone contacts manager- use facebook for app sharing

17. Our work • Detecting and Preventing Privilege-Escalation on Android in the Wild • Motivation • Detecting and preventing privilege escalation • Design requirements • No framework and kernel modification • Low overhead • Recommendations for users

18. Architecture monitor framework App A Permission of A intent Linux kernel Strace System call A System call B System call permission map total system call Privilege escalation or not

19. Key steps • System Call-permission map (s-p map) • System call recording • Intent trace • Total system call

20. S-P Map monitor framework App A Permission of A intent Linux kernel Strace System call A System call B System call permission map total system call Privilege escalation or not

21. S-P Map System call permission System calls System calls System calls System calls …… …… ……

22. Real system call monitor framework App A Permission of A intent Linux kernel Strace System call A System call B System call permission map total system call Privilege escalation or not

23. Real system call • Encode before write • Low overhead • Improve the efficiency of the analysis • Get app B’s pid • Get app B’s system calls • Add B’s system calls to app A

24. Runtime-monitor & Decision monitor framework App A Permission of A intent Linux kernel Strace System call A System call B System call permission map total system call Privilege escalation or not

25. Runtime-monitor & Decision • Only monitor the intents starting services、 broadcast receivers, not activities • Get permissions of app A • When IPC happened, we compare the permission needed and the permission requested. • Decision: If the permission needed is not included in manifest file, report security warning to users

26. Contributions • First s-p map (system call-permission) • First tool for users aware • Comprehensive: not only Dalvikcode, but also NDK • Practicality: No policies self-defined • Wide covering: solving privilege-escalation introduced by component exposure and collusion attacks • On-line user report

27. thank you!!