Long Lu, Zhichun Li, Zhenyu Wu, Wenke Lee and Guofei Jiang CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerability

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 2 2 Component hijacking vulnerability Accurate and scalable app vetting methods

Components in Android apps CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 3 3 Basic building blocks of apps Mutually independent yet interactive Exportable App1App2 Android Framework

What can go wrong? CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 4 4 Contact Manager App EnumeratorService Enumerator Service Returns the address book upon request Accepts unauthorized requests Contacts Android Framework Unauthorized access to protected resources

What can go wrong? CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 5 5 Setting Update Receiver Overwrites sensitive data upon update Accepts external updates Unauthorized access to private resources Contact Manager App Android Framework Setting Update Receiver Private Storage

Component hijacking attacks CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 6 6 A class of attacks that seek to gain unauthorized access to protected or private resources through exported components in vulnerable apps. Vulnerable apps exist on target devices The attacking app is already installed

Similar attacks and countermeasures CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 7 7Attacks On permission- protected resources On a small set of apps Detections Lack of an in- depth and scalable method Alerting exported components Mitigations Enforcing strict permission delegation policy Data leakage prevention

CHEX -- Component Hijacking Examiner CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 8 8 Deep inspection Generic coverage Accurate Static analysis No de-compilation Fast No source code required No human assistance App market model Goal : Vetting large volumes of apps for component hijacking vulnerabilities CHEX

Analysis approach  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 9 9 App Android Framework Private Protected

Challenges CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 10 Lack of generic analysis tools for Dalvik bytecode Multiple entry points Event-based model Dealing with Android apps’ programming paradigm Asynchronous execution Inter-component data flows Data flow analysis on Android apps can be expensive

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 11 Class hierarchy Instructions Meta data Constants Parse manifest Disassemble bytecode (DexLib) Instruction translation Abstract interpretation SSA conversion SSA IR Frontend Backend Point-to analysis Call graph builder SDG builder …

Android Framework Modeling Android Framework  Design choice: model the framework  For data-flow analysis, we model  Asynchronous entry points  Framework-assisted data-flows CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 12 App System managers LibrariesRuntime Reflections Mixed languages Large codebase …

App entry points  Points through which control transfers to the app  Start point  Callbacks CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 13 App launch points Component lifecycle callbacks UI event handlers Asynchronou s constructs Others Definition: App entry points are the methods that are defined by the app and intended to be called only by the framework.

Entry point discovery Observation: only two ways to “register” entry points  Declaring them in the manifest file  Overriding/implementing the designated interfaces CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 14 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 15 Unused methods overriding framework Entry points 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 16 App Android Framework 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 17 G1 Src1 G1 Sink1 Src1 G1 Sink1 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.

Identifying “hijack-enabling flows”  Using descriptive policies to specify flows of interests CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 18 … Sensitive Public … Input Critical … Input Sensitive Input- specified exit

Performance  Median processing time: 37sec  22% apps took >5min Accuracy  254/5,486 flagged as vulnerable  True positive rate: 81%  254/5,486 flagged as vulnerable  True positive rate: 81% Evaluations CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 19  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

Case study CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 20 Attack Class Representative cases Data TheftSending GPS data to URL specified by input string Capability Leak Input string used as hostname for socket connection Code Injection Input string used for raw SQL query statement Input string used as shell command Intent ProxyObject embedded in input used to start Activity Data tamperingInput string submitted to server as game score

Conclusion Conducted large-scale experiments 254 / 5,486 apps37.02 secCase studies Designed and implemented CHEX Identifying hijack- enabling flows Suited for large volume app vetting Overcoming analysis challenges of apps Studied component hijacking vulnerabilities Defined from a data flow perspectiveGeneralizing similar attacks CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 21

False positives  Sophisticated request validations  Infeasible split permutations False negatives  Control-flow driven hijacks Discussions CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 22