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 Ecosystem App Developer Phone/Tablet App Ad Network Ad Plugin IntroductionChallengesPEDALEvaluationConclusion See/Click Ads App User Ad Plugin Paid by User Clicks Paid by Impressions

3 Ecosystem Incentives are Skewed Against Users “ Users felt the least comfortable when private resources were used for advertising” “ Users felt the least comfortable when private resources were 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 IntroductionChallengesPEDALEvaluationConclusion “Mobile advertising services were a consistent privacy concern for the most participants”

Therefore, our position is that… 4 This cannot be achieved in Android Android 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 IntroductionChallengesPEDALEvaluationConclusion

5 IntroductionChallengesPEDALEvaluationConclusion 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 IntroductionChallengesPEDALEvaluationConclusion Our Approach – Examples

7 IntroductionChallengesPEDALEvaluationConclusion

8 IntroductionChallengesPEDALEvaluationConclusion 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 IntroductionChallengesPEDALEvaluationConclusion 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 IntroductionChallengesPEDALEvaluationConclusion

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 IntroductionChallengesPEDALEvaluationConclusion

12 IntroductionChallengesPEDALEvaluationConclusion Challenges on privilege de-escalation Most 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 of privilege inheritance Any solution for privilege de-escalation must prevent this kind of privilege inheritance

13 IntroductionChallengesPEDALEvaluationConclusion PEDAL Overview PEDAL 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 IntroductionChallengesPEDALEvaluationConclusion Finally, the Rewriter, by analyzing information flow across bytecode sets, can prevent privilege inheritance

15 Separator Implementation IntroductionChallengesPEDALEvaluationConclusion Most important: choose the set of features that ensure high classification accuracy

16 IntroductionChallengesPEDALEvaluationConclusion 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 Implementation Rewriter 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 IntroductionChallengesPEDALEvaluationConclusion

18 Rewriter Implementation Preventing Privilege Inheritance Focus on resource access core functions in the app logic to Internet access calls in the ad library IntroductionChallengesPEDALEvaluationConclusion Once these potential leakage paths have been identified, Rewriter performs the same kind of interposition as above Once these potential leakage paths have been identified, Rewriter performs the same kind of interposition as above Native Libraries Marginally Affect our Control

19 IntroductionChallengesPEDALEvaluationConclusion 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 IntroductionChallengesPEDALEvaluationConclusion

21 Evaluation: the Separator IntroductionChallengesPEDALEvaluationConclusion

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 IntroductionChallengesPEDALEvaluationConclusion 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) Control Location (feed fake location) IntroductionChallengesPEDALEvaluationConclusion 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 IntroductionChallengesPEDALEvaluationConclusion 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 obfuscations and source code obfuscation PEDAL is robust, by design, to both package name obfuscations and 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 overhead for apps PEDAL is effective and imposes negligible runtime overhead for apps