long lu, zhichun li, zhenyu wu, wenke lee and guofei jiang chex: statically vetting android apps for...

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 apps

Component 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

Enumerator

Service

Enu

mera

tor S

erv

iceReturns the address book upon request

Accepts unauthorized requests

Contacts

Android Framework

Unauthorized access to protected resources


5

What can go wrong?

Settin

g U

pd

ate

R

ece

iver

Overwrites sensitive data upon update

Accepts external updates

Unauthorized access to private resources

Contact Manager App

Android Framework

Setting Update

ReceiverPrivateStorage


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

Challenges

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


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 conversion

SSA 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 discovery

Observation: 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 study

Attack Class Representative cases

Data TheftSending GPS data to URL specified by input string

Capability LeakInput string used as hostname for socket connection

Code InjectionInput string used for raw SQL query statementInput string used as shell command

Intent ProxyObject embedded in input used to start Activity

Data tamperingInput string submitted to server as game score


21

Conclusion

Conducted large-scale experiments

254 / 5,486 apps 37.02 sec Case studies

Designed and implemented CHEXIdentifying hijack-

enabling flowsSuited for large

volume app vettingOvercoming 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 chex: statically vetting android apps for...

Documents

android apps chex

vetting android apps

large volumes of apps

flows chex

challenges chex

countermeasures chex

scalable app vetting

basic building blocks