2014 Network and Distributed System Security Symposium

AppSealer: Automatic Generation of Vulnerability-

Specific Patches for Preventing Component Hijecking Attacks in Android Application

Mu Zhang, Heng Yin Syracuse University

林良軒 2014/05/26 @ Advanced Defense Lab Seminar, NCUEmail : linliang258369@gmail.com

OutlineIntroduction

Component Hijacking Attack

Implementation

Evaluation

Conclusion

Reference

1

IntroductionComponent Hijacking Attack : A class of attacks that seek to

gain unauthorized access (read/write or combined) to protected or private resources

through exported components in vulnerable apps.

Ref : CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities (CCS 2012)

3

4Ref : CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities

5

Component hijacking attacks

Ref : CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities

Contact Manager App

EnumeratorService

Enum

erator Service

Returns the address book upon request

Accepts unauthorized requests

READ

Contacts

Android Framework

Unauthorized access to protected resources

Component hijacking attacks

Ref : CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities

Setting U

pdate Receiver

Accepts external updates

App Internal DB is not permission protected

Write to critical area

Unauthorized access to private resources

Contact Manager App

Android Framework

Setting UpdateReceiver

PrivateStorage

Key ValueVoIP_Prefix “1234”

Is_App_Lisenced false

5

AppSealer as a Security Service

7

1. No source code access2. Vulnerability-specific patching3. Minimal performance overhead4. Minimal impact on usability

[ VulActivity ]

onCreate()

onStart()

– getLocation()

onDestroy()

– post(addr, location)

getLocation()

– getLastKnownLocation()

crypt()

post()

– HttpURLConnection

– outputStrem

8

9

10

11

12

Workflow

13

(1)IR Translation(2)Slice Computation(3)Patch Statement Placement(4)Patch Statement Optimization(5)Bytecode Generation

Taint Slice ComputationA. Forward Dataflow Analysis

1. Basic Algorithm : use Def-use chain

2. Special Considerationsa. Static field

b. Instance field

c. Intent

d. Class inheritance

e. Thread

B. Backward Dependency Analysis

14

15

Slice 1 Slice 2

Slice 2

16

Slice 1

17

Slice 1

18

Slice 1

19

Slice 1

20

Patch Statement PlacementA. Tainting Policy

1. Directly modifies the bytecode to keep track of selected tainted information

2. Each single local variable, field, etc. - Have a shadow variable

B. Creating Shadow Variables1. Local Variables

2. Static/Instance Fields

3. Parameters and Return Value

C. Instrumenting the Source

D. Instrumenting Taint Propagation

E. Cleaning the Taint

F. Instrumenting the Sink21

Patch Statement PlacementB. Shadow Variables

1. Local Variables

22

Patch Statement PlacementB. Shadow Variables

2. Static/Instance Fields

23

Patch Statement PlacementB. Shadow Variables

3. Parameters and Return Value

24

Patch Statement PlacementA. Tainting Policy

1. Directly modifies the bytecode to keep track of selected tainted information

2. Each single local variable, field, etc. - Have a shadow variable

B. Creating Shadow Variables1. Local Variables

2. Static/Instance Fields

3. Parameters and Return Value

C. Instrumenting the Source

D. Instrumenting Taint Propagation

E. Cleaning the Taint

F. Instrumenting the Sink25

Patch Statement PlacementA. Tainting Policy

1. Directly modifies the bytecode to keep track of selected tainted information

2. Each single local variable, field, etc. - Have a shadow variable

B. Creating Shadow Variables1. Local Variables

2. Static/Instance Fields

3. Parameters and Return Value

C. Instrumenting the Source

D. Instrumenting Taint Propagation

E. Cleaning the Taint

F. Instrumenting the Sink26

Patch Statement PlacementD. Instrumenting Taint Propagation

1. Simple Assignments

27

Patch Statement PlacementD. Instrumenting Taint Propagation

2. Function Calls

28

Patch Statement PlacementD. Instrumenting Taint Propagation

3. API Calls

1. getString(), toString()

2. Android.widget.TextView,setText()

3. Vector.add(Object)

4. Android.content.ContentValues.put(String key, Byte value)

4. Tracking References

If one of the references is tainted, all other references should also be tainted.

29

Patch Statement PlacementA. Tainting Policy

1. Directly modifies the bytecode to keep track of selected tainted information

2. Each single local variable, field, etc. - Have a shadow variable

B. Creating Shadow Variables1. Local Variables

2. Static/Instance Fields

3. Parameters and Return Value

C. Instrumenting the Source

D. Instrumenting Taint Propagation

E. Cleaning the Taint

F. Instrumenting the Sink30

Patch Statement PlacementE. Cleaning the Taint

To properly clean the taint, for each variable appearing in the def-use chain inside the slice, we need to find all its definitions.

For the definitions outside the slice, we need to insert a statement after that definition to set its shadow variable to 0(non-tainted)

31

Patch Statement PlacementA. Tainting Policy

1. Directly modifies the bytecode to keep track of selected tainted information

2. Each single local variable, field, etc. - Have a shadow variable

B. Creating Shadow Variables1. Local Variables

2. Static/Instance Fields

3. Parameters and Return Value

C. Instrumenting the Source

D. Instrumenting Taint Propagation

E. Cleaning the Taint

F. Instrumenting the Sink32

Patch Statement PlacementF. Instrumenting the Sink

If they are tainted by certain sources, we can raise a pop-up dialog to the user, asking for decision.- Restart- Continue

33

Patch OptimizationIn order to reduce the amount of patch statements

O1. Removing Redundant BoolWrappers Copy propagation and dead assignment elimination

O2. Removing Redundant Function Parameters

O3. Inlining Instrumentation Code

O4. Soot’s Build-in Optimizations

34

Patch OptimizationIn order to reduce the amount of patch statements

O1. Removing Redundant BoolWrappers

O2. Removing Redundant Function Parameters

35

Patch OptimizationIn order to reduce the amount of patch statements

O1. Removing Redundant BoolWrappers

O2. Removing Redundant Function Parameters

O3. Inlining Instrumentation Code Inlining the body of small function into its callers, the function call overhead can be avoided.

36

Patch OptimizationIn order to reduce the amount of patch statements

O1. Removing Redundant BoolWrappers

O2. Removing Redundant Function Parameters

O3. Inlining Instrumentation Code

O4. Soot’s Build-in Optimizations

37

Workflow

38

(1)IR Translation(2)Slice Computation(3)Patch Statement Placement(4)Patch Statement Optimization(5)Bytecode Generation

39

40

41

42

43

44

Evaluation

45

Evaluation

46

Evaluation

47

Evaluation

48

ConclutionA. Automatically generate patch

B. Shadow mechanism

C. Optimization

49