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

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

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

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

5. 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 5

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 6

7. Android specific security risks Confused deputy Collusion attacks 7

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

9. Collusion attacks What is it ？ Two or more apps cooperate purposely to achieve privilege escalation Type 1 : ICC 9 Sandbox App a Permissions: - Ca1Ca2 Sandbox App b permission:p1 Cb1Cb2 Sandbox App c Cc1Cc2 p1 p2 √ allowed ×not-allowed √ 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 ··· 10 Notification broadcast Collection app Deliver app

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

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 】 12

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

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

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

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 16

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 17

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

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

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

21. S-P Map 21 A B C D E F System call permission …… …… System calls A B C ……

22. Real system call 22 Strace framework App A Linux kernel monitor intent System call A System call B total system call Permission of A System call permissio n map 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 23

24. Runtime-monitor & Decision 24 Strace framework App A Linux kernel monitor intent System call A System call B total system call Permission of A System call permissio n map 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 25

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 26

27. thank you!! 27