CHEX:
Statically Vetting Android Apps for
Component Hijacking Vulnerability

Chao Shi
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
1
Scribed from www.cc.gatech.edu/grads/l/long/download/CHEX_CCS12.pptx
Systematic Detection of Capability Leaks in Stock Android Smartphones
 Jacob Sherin
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
2
Component Hijacking Vulnerability
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
3
Vetting vulnerable apps in large scale
High volume of app submissions
Inexperienced developers
Large number of vulnerable apps
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
4
Component hijacking vulnerability
Components in Android Apps
Type
Activity
Service
Broadcast Receiver
Content Provider
Mutually independent yet interactive
Secure interaction mechanism exists
People ignorance
Export Component
The component is publicly available
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
5
Component hijacking attacks
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
6

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.
Component hijacking attacks
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
7
Unauthorized access to protected resources
Component hijacking attacks
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
8
Unauthorized access to private resources
Code Example
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
9
Malicious app:

Ibinder binder;
/* Connect to the service */
…
/* Send message to the service */
Messenger mMessenger = new Messenger(binder)
mMessenger.send(msg);
Component Hijacking vulnerable app
Data flow view
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
10
GetLastLocation
(Sensitive Source)
Message
(Input Source)
currLoc
(GV)
SendParams
(Transit sink)
params
(Transit Source)
HTTPClient Execute
(critical sink)
Chain of components.
A data-flow perspective
Component hijacking 
read/write protected or private data via exported components
Detecting component hijacking  finding “hijack-enabling flows”
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
11
App entry points
Points where transfers the control to the app.
Start point
Callbacks
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
12
Definition: App entry points are the methods that are defined by the app and intended to be called only by the framework.
Challenges
Reliably discovering all types of entry points (or event handlers) in their completeness
Soundly modeling the asynchronous invocations of entry points for analysis.
Assess the collective side-effects of individual data flows and identifying the converged flow of interest
Tracking data flows across splits and components (different thread, do in the background)
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
13
More complex view
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
14
GetLastLocation
(Sensitive Source)
Message
(Input Source)
currLoc
(GV)
SendParams
(Transit sink)
params
(Transit Source)
HTTPClient Execute
(critical sink)
currLoc
(GV)
Entry Point
Entry Point
Handle Message
Background,
New thread
Capability Leak
15
Capability Leaks
Capability Leak: A situation where an app can gain access to a restricted API without requesting proper permission

Explicit Capability Leak: Broadening access to a restricted API by exposing it via another API

Implicit Capability Leak: Inheriting permissions from other applications

Explicit Capability Leaks
Implicit Capability Leaks
Applications don`t have permissions, user identifiers (UIDs) do.
CHEX Design
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
19
Related Work Limitations
Only protected resources being checked.
No completeness in entry point discovery.
No in-depth analysis. Simply checking the usage of exported methods in the component.
No scalability methods
Only test on small set of apps.
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
20
Major Contributions
Designed a sound method which automatically discovers all types of app entry points with low false rate.
Designed a method to model the interleaved execution of the multiple entry points and track data flow between them.
Build CHEX, a in-depth, scalable, context-sensitive, flow-sensitive static app vetting tool for component hijacking vulnerabilities and tested on large set of apps.
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
21
Dalysis: Dalvik Analysis Framework
Consumes off-the-shelf Android app package (.apk)
Generates SSA IR (adopted from WALA)
Supports extensible backend for multiple types analysis tasks
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
22
Entry point discovery
Observation: only two ways to “register” entry points
Declaring them in the manifest file (parse manifest)
Overriding/implementing the designated interfaces
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
23
Unused methods overriding framework




Entry points
Dead code
How to distinguish?
Containing class is instantiated
Original interface is never called by app
Entry point discovery
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
24



Unused methods overriding framework




Entry points
App splitting
Modeling app execution by permuting split executions in all feasible orders

Why reasonable?
Most splits cannot be interleaved
Efficient pruning techniques
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
25
App




Definition:
A split is a subset of the app code that is reachable from an entry point.
SDS and PDS
Permutation Data-flow Summary (PDS)
Linking two adjacent SDSs in a feasible permutation
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
26
Split Data-flow Summary (SDS)
Intra-split data-flows that start and end at
heap variables, sources, or sinks.
When permutation ends, all possible data-flows have been enumerated.
Example
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
27
Identifying “hijack-enabling flows”
Using descriptive policies to specify flows of interests
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
28
Critical Sink
Performance
Median processing time: 37sec
22% apps took >5min
Accuracy
254/5,486 flagged as vulnerable
True positive rate: 81%
Evaluations
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
29
5,486 apps from the official and alternative markets
Hardware spec: Intel Core i7-970 with 12GB RAM
Insights
50 entry points of 44 types per app
99.7% apps contain inter-split data-flows
Vulnerabilities found
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
30
False positives
Sophisticated request validations
Infeasible split permutations
False negatives
Control-flow driven hijacks
Discussions
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
31
Capability Leaks
CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities
32
Detecting Capability Leaks
Android SDK gives us no tools!
Function composition
Capability leak: g(x) = f(x) + some other stuff

Intuitive Algorithm
Find interesting (dangerous) APIs (f(x))
Find new API definitions (g(x))
Link them!
System Overview
Possible Path Identification
Construct a control-flow graph


Find all paths from an IPC entry point to an API of interest
Possible Path Identification: Challenges
Object references
Class hierarchy used to conservatively resolve references
Extensive use of callbacks
Use framework knowledge to stitch together callbacks
Infeasible Path Pruning
Many potential paths exist
Most are either impossible or uninteresting

Must prune these uninteresting paths
Branch conditions need an understanding of program data-flow
Explicit permission checks are “infeasible paths”
Approach: Symbolic Path Simulation
Symbolic Path Simulation
Results
Results
Case Studies
Explicit Capability Leaks (Without Arguments)

Explicit Capability Leaks (With Arguments)

Implicit Capability Leaks
Explicit Capability Leaks (Without Arguments)

Samsung Epic 4G
Pre-loaded app, com.sec.android.app.Selective-Reset
Displays reset confirmation screen
SelectiveResetReceiver class
Listens for Android.intent.action.SELECTIVE_RESET Intent, then waits for confirmation
Starts SelectiveResetService, then listens for android.intent.action.SELECTIVE_RESET_DONE
This calls CheckInService.masterClear()
Explicit Capability Leaks (With Arguments)
HTC capability leaks
SEND_SMS
CALL_PHONE
RECORD_AUDIO

Similar formats
Exercised capability takes a number of arguments, certain components can be passed in Intent.
Explicit Capability Leaks (With Arguments)
Implicit Capability Leaks
HTC Wildfire S
Built-in MessageTab app, com.android.MessageTab
CALL_PRIVILEGED capability
It is used to manage phone`s SMS messages, but for convenience allows the user to dial contacts directly through a “contact details” screen
Does not request CALL_PHONE or CALL_PRIVILEGED in its manifest
BUT! It does declare a sharedUserId attribute
android.uid.shared
Shared with several core Android apps, including com.android.htcdialer, which has both phone-dialing permissions
Future Work and Improvement
Handle native code in addition to Dalvik bytecode

Expand permission set, only 13 now

Chained capability leaks
App-defined permissions

Expand to include third-party user apps