CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerability Vetting vulnerable apps in large scale High volume of app submissions Inexperienced developers Accurate and scalable app vetting methods Large number of vulnerable apps Component hijacking vulnerability 2 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities Components in Android Apps Type Activity Service Broadcast Receiver Content Provider App1 App2 Export Component The component is publicly available Android Framework 3 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities What can go wrong? Unauthorized access to protected resources Enumerator Service Enumerator Service Contact Manager App Returns the address book upon request Accepts unauthorized requests Android Framework Contacts 4 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities What can go wrong? Unauthorized access to private resources Setting Update Receiver Private Storage Android Framework Setting Update Receiver Contact Manager App Overwrites sensitive data upon update Accepts external updates 5 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities Component hijacking attacks 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 6 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities CHEX -- Component Hijacking Examiner Goal: Vetting large volumes of apps for component hijacking vulnerabilities Accurate • Deep inspection • Generic coverage Fast CHEX • Static analysis • No de-compilation App market model • No source code required • No human assistance 7 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities Analysis approach A data-flow perspective Component hijacking read/write protected or private data via exported components Detecting component hijacking finding “hijack-enabling flows” App Private Protected Android Framework 8 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities Challenges Lack of generic analysis tools for Dalvik bytecode Dealing with Android apps’ programming paradigm • Multiple entry points • Event-based model Data flow analysis on Android apps can be expensive • Asynchronous execution • Inter-component data flows 9 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities Code Example Component Hijacking vulnerable app Malicious app: Ibinder binder; /* Connect to the service */ … /* Send message to the service */ Messenger mMessenger = new Messenger(binder) mMessenger.send(msg); CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 10 App entry points Points through which control transfers to the app Start point Callbacks Definition: App entry points are the methods that are defined by the app and intended to be called only by the framework. App launch points Component lifecycle callbacks UI event handlers Asynchronous constructs CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 11 App splitting Definition: A split is a subset of the app code that is reachable from an entry point. App Modeling app execution by permuting split executions in all feasible orders Why reasonable? Most splits cannot be interleaved Efficient pruning techniques Android Framework 12 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities SDS and PDS Src1 G1 Split Data-flow Summary (SDS) Intra-split data-flows that start and end at heap variables, sources, or sinks. G1 Permutation Data-flow Summary (PDS) Linking two adjacent SDSs in a feasible permutation Sink1 Src1 G1 When permutation ends, all possible data-flows have been enumerated. 13 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities Sink1 Identifying “hijack-enabling flows” Using descriptive policies to specify flows of interests Sensitive Input Input Sensitive … Public … Critical … Inputspecified exit 14 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities Evaluations 5,486 apps from the official and alternative markets Hardware spec: Intel Core i7-970 with 12GB RAM Performance Accuracy Median processing time: 37sec 254/5,486 flagged as vulnerable 22% apps took >5min True positive rate: 81% Insights 50 entry points of 44 types per app 99.7% apps contain inter-split data-flows CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 15 Case study Attack Class Data Theft Representative cases Sending 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 Proxy Object embedded in input used to start Activity Data tampering Input string submitted to server as game score 16 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities Conclusion Studied component hijacking vulnerabilities Defined from a data flow perspective Generalizing similar attacks Designed and implemented CHEX Identifying hijackenabling flows Suited for large volume app vetting Overcoming analysis challenges of apps Conducted large-scale experiments 254 / 5,486 apps 37.02 sec Case studies 17 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities 18 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities Dalysis: Dalvik Analysis Framework Parse manifest Meta data Constants Disassemble bytecode (DexLib) Class hierarchy Point-to analysis Instruction translation Abstract interpretation SSA conversion Call graph builder SSA IR Instructions Frontend 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 SDG builder … Backend 20 Entry point discovery Observation: only two ways to “register” entry points Declaring them in the manifest file Overriding/implementing the designated interfaces Unused methods overriding framework Dead code Entry points How to distinguish? Containing class is instantiated Original interface is never called by app 21 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities More complex view Entry Point GetLastLocation (Sensitive Source) Message (Input Source) currLoc (GV) SendParams (Transit sink) currLoc (GV) params (Transit Source) Handle Messag Entry Point HTTPClient Execute (critical sink) Background, New thread 22 CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities