Efficient Privilege De-Escalation for Ad Libraries in Mobile Apps

Bin Liu (SRA), Bin Liu (CMU), Hongxia Jin (SRA), Ramesh Govindan (USC)

2

The Mobile Ad EcosystemApp Developer

Phone/Tablet App

Ad Network

Ad Plugin

Introduction Challenges PEDAL Evaluation Conclusion

See/Click Ads

App User

Ad PluginPaid by User Clicks

Paid by Impressions

3Ecosystem Incentives are Skewed Against Users

“ Users felt the least comfortable when private resourceswere used for advertising”

Ad libraries taking unwarranted liberties with personal data on devices in order to more efficiently target ads

Users are especially concerned about privacy risks posed by ad libraries

Introduction Challenges PEDAL Evaluation Conclusion

“Mobile advertising services were a consistent privacy concern for the most participants”

Therefore, our position is that…4

This cannot be achieved in AndroidAndroid permissions model governs app access to resources,

however, acts on the whole apps, at install time

Once the app is installed, the app and all its included libraries are granted access to these resources

Considering these privacy concerns on ad libraries

Ad libraries fundamentally need less privilege than app logic

The user should be able to specify what resources should be granted to ad libraries

Introduction Challenges PEDAL Evaluation Conclusion

5

Introduction Challenges PEDAL Evaluation Conclusion

Our Approach – Privilege De-Escalation

An ad library can have fewer resource access privileges than the app logic itself

Users can selectively deny resource access privileges to the ad libraries without affecting the main app logic

6

Introduction Challenges PEDAL Evaluation Conclusion

Our Approach – Examples

7

Our Approach – Examples

Introduction Challenges PEDAL Evaluation Conclusion

8

Introduction Challenges PEDAL Evaluation Conclusion

How to effect selective privilege de-escalation?

To implement such a system, we need to answer two questions

Both challenges are non-trivial

How to identify ad library code in an app?

Challenges

9

Challenges on Identify Ad Libraries

Introduction Challenges PEDAL Evaluation Conclusion

There is no annotation that preserves the separation between bytecodes from app logic and bytecodes from an ad library

We can at best access the so called bytecodes which are a intermediate code obtained by compiling source codes

10

Challenges on Identify Ad Libraries

However, advanced ad libraries use package-level or code-level obfuscation to foil this method

Some researchers suggest to use bytecode path matching to identify ad libraries in bytecodes, e.g. /com/google/ads

Introduction Challenges PEDAL Evaluation Conclusion

11

Challenges on privilege de-escalation

The solution must be highly efficient; significant slowdowns in app execution time can affect usability

Ideally, the solution must not require changes to the OS or the VM, or must not require rooting a phone

Introduction Challenges PEDAL Evaluation Conclusion

12

Introduction Challenges PEDAL Evaluation Conclusion

Challenges on privilege de-escalationMost important, in a substantial fraction of apps, ad libraries

inherit privileges from the app logic

Any solution for privilege de-escalation must prevent this kind ofprivilege inheritance

13

Introduction Challenges PEDAL Evaluation Conclusion

PEDAL OverviewPEDAL contains: a Separator and a Rewriter

Input: a packaged app & Output: a repacked app with de-escalated privileges for any (obfuscated) ad libraries in the app

14

PEDAL Overview

Obfuscation resistant classification and binary-rewriting achieve selective de-escalation on ad libraries

By using binary rewriting, our approach does not require OS level changes, and also achieves significant efficiency

This design achieves the challenges we have reviewed before

Introduction Challenges PEDAL Evaluation Conclusion

Finally, the Rewriter, by analyzing information flow across bytecode sets, can prevent privilege inheritance

15

Separator Implementation

Introduction Challenges PEDAL Evaluation Conclusion

Most important: choose the set of features that ensure high classification accuracy

16

Introduction Challenges PEDAL Evaluation Conclusion

We choose six groups of features that are informative to ad library classification

Usage of Android basic components

Usage of selective Android permissions

Usage of visual elements Usage of information sources and sinks

Usage of APIs for runtime permission check

Keyword matching for class/method/field names

We do not use bytecode path information, and the chosen features are resistance to code obfuscation

Separator Implementation

17

Rewriter ImplementationRewriter effects privilege de-escalation by binary re-

writing based on user-specified privacy policies

Rewriter interposes on resource accesses by the ad library or the app logic

Rewriter only interposes what we called core resource access functions

Introduction Challenges PEDAL Evaluation Conclusion

18

Rewriter Implementation

Preventing Privilege Inheritance

Focus on resource access core functions in the app logic to Internet access calls in the ad library

Introduction Challenges PEDAL Evaluation Conclusion

Once these potential leakage paths have been identified,Rewriter performs the same kind of interposition as above

Native Libraries Marginally Affect our Control

19

Introduction Challenges PEDAL Evaluation Conclusion

Evaluation: the Separator

Crawled 63,105 free apps from Google Play Store

Train a SVM from 335 ad modules and 335 non ad modules: Recall 98.4%, Precision 98.5%

Randomly chose 200 apps, and manually check the classification result

Even with obfuscation in most of these apps (120/200) our classifier performs an accuracy of 93%

20

Evaluation: the Separator

Our Separator is more efficient than the traditional package name matching approach

Among all apps, our Separator discovered 2,598 unique ad library modules, belonging to 546 unique ad library sources

This is at least 5X more than the reported numbers in papers that maintain a pre-defined blacklist of ad package names

Introduction Challenges PEDAL Evaluation Conclusion

22

Evaluation: the Rewriter

How much the runtime overhead the rewriting code has added

We select 100 apps, and uses an UI automation tool to run both original and rewritten apps

Introduction Challenges PEDAL Evaluation Conclusion

Both versions of a app were fed identical click streams

Executing these 100 apps on showed a total increase in runtime of 0.89% on average.

Due to limitations of static flow analysis

23

Evaluation: the Rewriter

100 Apps + Pre-defined clickstream for each app

No Control Control Internet (block ads)

Control Location(feed fake location)

Introduction Challenges PEDAL Evaluation Conclusion

843 ads, 304 are location targeted 9 ads 806 ads, 249/23 targets

fake/real location

Due to missing core functions

How effective the control can be?

24

Conclusion

Introduction Challenges PEDAL Evaluation Conclusion

PEDAL: a system to achieve selective privilege de-escalation for ad libraries

PEDAL performs automated classification to identify ad library code, and rewrite core resource functions to achieve de-escalation

PEDAL is robust, by design, to both package name obfuscationsand source code obfuscation

PEDAL shows remarkable classification accuracy and efficacy, yet requires reasonable computing power to process apps

PEDAL is effective and imposes negligible runtime overheadfor apps