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, NCU
Email : linliang258369@gmail.com
Outline
Introduction
Component Hijacking Attack
Implementation
Evaluation
Conclusion
Reference
1
Introduction
Component 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)
2
Ref : CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
3
Component hijacking attacks
Unauthorized access to protected resources
Enumerator
Service
Enumerator Service
Contact Manager App
Returns the
address book upon
request
Accepts
unauthorized
requests
READ
Android Framework
Contacts
Ref : CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
4
Component hijacking attacks
Unauthorized access to private resources
Setting Update
Receiver
Private
Storage
Android Framework
Key
Value
VoIP_Prefix
“1234”
Is_App_Lisenced
false
Ref : CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
Setting Update Receiver
Contact Manager App
Accepts external
updates
App Internal DB is
not permission
protected
Write to critical
area
5
AppSealer as a Security Service
1. No source code access
2. Vulnerability-specific patching
3. Minimal performance overhead
4. Minimal impact on usability
6
[ VulActivity ]
onCreate()
onStart()
– getLocation()
onDestroy()
– post(addr, location)
getLocation()
– getLastKnownLocation()
crypt()
post()
– HttpURLConnection
– outputStrem
7
8
9
10
11
Workflow
(1)IR Translation
(2)Slice Computation
(3)Patch Statement Placement
(4)Patch Statement Optimization
(5)Bytecode Generation
12
Taint Slice Computation
A. Forward Dataflow Analysis
1. Basic Algorithm : use Def-use chain
2. Special Considerations
a.
Static field
b.
Instance field
c.
Intent
d.
Class inheritance
e.
Thread
B. Backward Dependency Analysis
13
Slice 1
Slice 2
14
Slice 2
15
Slice 1
16
Slice 1
17
Slice 1
18
Slice 1
19
Patch Statement Placement
A. 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 Variables
C.
D.
E.
F.
1.
Local Variables
2.
Static/Instance Fields
3.
Parameters and Return Value
Instrumenting the Source
Instrumenting Taint Propagation
Cleaning the Taint
Instrumenting the Sink
20
Patch Statement Placement
B. Shadow Variables
1. Local Variables
21
Patch Statement Placement
B. Shadow Variables
2. Static/Instance Fields
22
Patch Statement Placement
B. Shadow Variables
3. Parameters and Return Value
23
Patch Statement Placement
A. 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 Variables
C.
D.
E.
F.
1.
Local Variables
2.
Static/Instance Fields
3.
Parameters and Return Value
Instrumenting the Source
Instrumenting Taint Propagation
Cleaning the Taint
Instrumenting the Sink
24
Patch Statement Placement
A. 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 Variables
C.
D.
E.
F.
1.
Local Variables
2.
Static/Instance Fields
3.
Parameters and Return Value
Instrumenting the Source
Instrumenting Taint Propagation
Cleaning the Taint
Instrumenting the Sink
25
Patch Statement Placement
D. Instrumenting Taint Propagation
1. Simple Assignments
26
Patch Statement Placement
D. Instrumenting Taint Propagation
2. Function Calls
27
Patch Statement Placement
D. 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.
28
Patch Statement Placement
A. 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 Variables
C.
D.
E.
F.
1.
Local Variables
2.
Static/Instance Fields
3.
Parameters and Return Value
Instrumenting the Source
Instrumenting Taint Propagation
Cleaning the Taint
Instrumenting the Sink
29
Patch Statement Placement
E. 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)
30
Patch Statement Placement
A. 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 Variables
C.
D.
E.
F.
1.
Local Variables
2.
Static/Instance Fields
3.
Parameters and Return Value
Instrumenting the Source
Instrumenting Taint Propagation
Cleaning the Taint
Instrumenting the Sink
31
Patch Statement Placement
F. 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
32
Patch Optimization
In 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
33
Patch Optimization
In order to reduce the amount of patch statements
O1. Removing Redundant BoolWrappers
O2. Removing Redundant Function Parameters
34
Patch Optimization
In 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.
35
Patch Optimization
In 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
36
Workflow
(1)IR Translation
(2)Slice Computation
(3)Patch Statement Placement
(4)Patch Statement Optimization
(5)Bytecode Generation
37
38
39
40
41
42
43
Evaluation
44
Evaluation
45
Evaluation
46
Evaluation
47
Conclution
A. Automatically generate patch
B. Shadow mechanism
C. Optimization
48