Detecting and Preventing Privilege-Escalation on Android

Jiaojiao Fu

1

outline

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

2

Importance

• More serious malware threats• Suspicious samples increasing rapidly

3

Malware Threats to Mobile OSs

Growth trend of total Android suspicious samples

Security mechanisms

• Two main Android security mechanisms• Sandbox • Permission

4

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

5

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

Android specific security risks

• Confused deputy• Collusion attacks

7

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

Collusion attacks

• What is it？• Two or more apps cooperate purposely to

achieve privilege escalation

• Type 1 : ICC

9

SandboxApp a

Permissions: -

Ca1 Ca2

SandboxApp b

permission:p1

Cb1 Cb2

SandboxApp c

Cc1 Cc2p1 p2

√ allowed √ allowed

×not-allowed√ allowed

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

How to solve these two specific android security risks: confused deputy

and collusion attacks?

11

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

CHEX: statically vetting Android apps for component hijacking vulnerabilities

• Detecting the possibility of confused deputy

• Static analysis method

13

Figure 1: CHEX workflow

CHEX-limitations

• Static method-not comprehensive• only Dalvikcode• no NDK- other programming language

• Detecting component hijecking vulnerabilities

• No other kinds of permission escalation

14

Linux kernel

Previous work-2&3

15

Android framework

Service hookContent

provider hook

system hook （ filesystem， ···）

PolicySelf-

defined

• Taming privilege-escalation attacks on android with diverse security and privacy policies

• Methodology

Privilege escalation or not

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

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

Architecture

18

Strace

framework

App A

Linux kernel

monitor

intent

System call A System call B

total system call

Permission of A

System call

permission map

Privilege escalation or not

Key steps

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

19

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

permission map

Privilege escalation or not

S-P Map

21

A

B

C

D

E

F

System call permission

…… ……

System calls

System calls

A

System calls

B

System calls

C

……

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

permission map

Privilege escalation or not

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

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

permission map

Privilege escalation or not

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

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

thank you!!

27