long lu, zhichun li , zhenyu wu , wenke lee and guofei jiang

Long Lu, Zhichun Li, Zhenyu Wu, Wenke Lee and Guofei Jiang

CHEX:Statically Vetting Android

Apps for Component Hijacking

Vulnerability

CHEX: Statically Vetting Android Apps for Component Hijacking Vulnerabilities

2

Vetting vulnerable apps in large scale

High volume of app submissions

Inexperienced developers Large number of vulnerable

appsComponent hijacking vulnerability

Accurate and scalable app vetting methods


3

Components in Android apps

Basic building blocks of apps

Mutually independent yet interactive

Exportable

App1 App2

Android Framework


4

What can go wrong?

Contact Manager App

EnumeratorService

Enumerator Service

Returns the address book upon request

Accepts unauthorized requests

Contacts

Android Framework

Unauthorized access to protected resources


5

What can go wrong?

Setting Update Receiver

Overwrites sensitive data upon update

Accepts external updates

Unauthorized access to private resources

Contact Manager App

Android Framework

Setting UpdateReceiver

PrivateStorage


6

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


7

Similar attacks and countermeasures

Attacks• 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


8

CHEX -- Component Hijacking Examiner

• 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


9

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

Android Framework

Private

Protected


10

ChallengesLack 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


11

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

Classhierarchy

Instructions

Meta data

Constants

Parsemanifest

Disassemblebytecode (DexLib)

Instruction translationAbstract interpretation

SSA conversionSSA IR

Frontend Backend

Point-to analysis

Call graph builder

SDG builder

…


12

Android Framework

Modeling Android Framework Design choice: model the

framework For data-flow analysis, we

model Asynchronous entry points Framework-assisted data-

flows

App

System managers

Libraries Runtime

ReflectionsMixed

languagesLarge

codebase…


13

App entry points Points through which control transfers to the app Start point Callbacks

App launch points

Component lifecycle callbacks

UI event handlers

Asynchronous

constructsOthers

Definition: App entry points are the methods that are defined by the app and intended to be called only by the framework.


14

Entry point discoveryObservation: only two ways to “register” entry points

Declaring them in the manifest file Overriding/implementing the designated interfaces

Unused methods overriding framework

Entry points

Dead code

How to distinguish? Containing class is instantiated Original interface is never called by app


15

Entry point discovery


Entry point

s


Entry points


16

App splitting

Modeling app execution by permuting split executions in all feasible orders

Why reasonable? Most splits cannot be

interleaved Efficient pruning techniques

App

Android Framework

Definition: A split is a subset of the app code that is reachable from an entry point.


17

SDS and PDS

Permutation Data-flow Summary (PDS) Linking two adjacent SDSs in a feasible

permutation

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.


18

Identifying “hijack-enabling flows” Using descriptive policies to specify flows of interests

…

Sensitive

Public

…

Input

Critical

…

Input

Sensitive

Input-specifie

dexit


19

Performance Median processing time:

37sec

22% apps took >5min

Accuracy 254/5,486 flagged as vulnerable True positive rate: 81%

Evaluations 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


20

Case studyAttack Class Representative cases

Data Theft Sending GPS data to URL specified by input string

Capability Leak Input string used as hostname for socket connection

Code InjectionInput string used for raw SQL query statementInput 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


21

Conclusion

Conducted large-scale experiments254 / 5,486 apps 37.02 sec Case studies

Designed and implemented CHEXIdentifying hijack-enabling flows

Suited for large volume app vetting

Overcoming analysis challenges of apps

Studied component hijacking vulnerabilities Defined from a data flow perspective Generalizing similar attacks

long lu, zhichun li , zhenyu wu , wenke lee and guofei jiang

Documents