The Impact of Vendor Customizations on Android Security

1. The Impact of Vendor Customizations on Android Security Lei Wu, Michael Grace, Yajin Zhou, ChiachihWu, Xuxian Jiang Department of Computer Science North Carolina State University CCS 2013

2. Outline • Introduction • Design • Provenance Analysis • Permission Usage Analysis • Vulnerability Analysis • Reachability Analysis • Reflection Analysis

3. Outline(cont) • Implementation and evaluation • Provenance Analysis • Permission Usage Analysis • Vulnerability Analysis • Discussion • Related work • Conclusion

4. Introduction Ten representative stock Android images Five popular smartphone vendors To assess the extent of security issues

5. Introduction • 482.5 million sold in the Q4 of 2012 • 70% global market share • Android open source project (AOSP) • Vendor customizations • Third party apps: vendors or carriers • Three stage process • Stock images: provenance analysis • permission usages of pre-load apps: unnecessary permission request • Pre-load apps vulnerabilities analysis: permission re-delegation attack and private information leakage

6. Introduction • SEFA: Security Evaluation Framework for Android • Evaluation result: worrisome • 81.78% pre-load apps are from vendor customizations • 85.78% pre-load apps are over privileged, majority of them are from vendor customizations ? • 64.71% to 85.00% vulnerabilities are from vendor customization(Samsung, HTC, LG, except for Sony). • Current HTC is more securethan before.

7. Design:SEFA Architecture of SEFA

8. Design: Provenance Analysis • Provenance Analysis • AOSP app: Android open source project. • Original apps of Android • Vendor app: identified by signatures • Apps developed by venders. • Third-party app: identified by signatures • Apps developed by third-parties. • Exceptions • AOSP app may be modified by venders. • SONY Conversation app vs AOSP Mms app

9. Design: Provenance Analysis • SEFA determines AOSP procedure: • By matching app and package names • By matching component names in the manifest file. • By calculating the similarity between paths and apps. • Path: sequence of methods from entry point into a sink • Sink: operation requiring dangerous and sensitive permissions • Static analysis • Baksmali • Firmware release and update information

10. Design: Permission Usage Analysis • Permission overprivilege • Initial permission set of apps • Step1 • To generate the complete requested permission set: R-set • Initial requested permission set from manifest files of apps • To include shared permission set: SharedUserId • Step2 • To calculate the used permission set: U-set • Used by API invocations • Used by Intents • Used by content providers • Step3: • The overprivilege set: R–U

11. Design: Permission Usage Analysis Initial R set To generate the complete R set To generate the U set To generate the permission overprivilege set Algorithm 1

12. Design:Vulnerability Analysis • Vulnerabilities: • Permission re-delegation attack • Aims at using for dangerous actions • Passive content leak: world readable content provider • Content pollution:world writable content provider • Aims at serious content leak • Find the paths • From open entrypoints to sinks • Sensitive-sinks: APIs to sensitive permissions • Bridge-sinks: invocations indirectly another components • In-component: reachability analysis • Cross-component: reflection analysis

13. Design:Reachability Analysis • To determine the feasible paths from the entrypoint set of all Android components. • Step1: intra-procedural reachability analysis • building the call graphs and resolve it by using def-use analysis • The resolution starts rom the initial state to seek for a fix point of state changes with iteration • The result of states of variables and fields is named as a “summary” • Step2: inter-procedural reachability analysis • Propagate the states among different methods • Re-issue step1 if the summary is changed. • Feasible path: execution flow

14. Design: Reachability Analysis Check the summary of each callee c is modified or not invoking inter-analysis related to c (????) ???? • Algorithm Appendix • Execution flow

15. Design: Reflection Analysis • Reflection attack: Example • Vulnerability paths • in-component: reachability analysis • From unprotected component to a sink located in the same component • cross-component: none • From unprotected component to a sink located in the different component but in the same app • cross-app: none • From unprotected component to a sink located in the different component in the different app • Reflection analysis: to find all possible connections among components/apps

16. Design: Reflection Analysis • Add to V if c is vulnerable • Algorithm 2: reflection analysis • For current component and visited component list: • If current component is visited, return with V • Or append current component into visited component list. • If this current component is vulnerable, add to V • For all other components able to start current component • Do reflection analysis among them • Return V

17. Implementation and Evaluation SEFA was written in Java and Python Processing time of each image:70 min avg. Manual verify of vulnerabilities Baksmali

18. Implementation and Evaluation Devices 2010-2012

19. Implementation and Evaluation • Permission Usage Analysis • % of Overprivilege apps • 87.96% -> 83.61%: avg.: 85.78%

20. Implementation and Evaluation • Vulnerabilities • % of vulnerable apps • Worst in %: HTC wildfire S, LG Optimus P880

21. Implementation and Evaluation • Vulnerabilities: customizations • Customizations: vender and third-parties • % of vulnerable apps of customizations

22. Implementation and Evaluation • Vulnerabilities • Inherited: from previous product • Introduced: new found in the new product

23. Implementation and Evaluation • Vulnerabilities • Critical vulnerabilities • Other: vendor- or model- specific

24. Implementation and Evaluation • Vulnerabilities: cross-app vulnerabilities • Difficult to detect • % of cross-app vulnerabilities

25. Case study: Samsung S3 Two hard-coded local socket: FactoryClientRecv FactoryClientSend Able to receive command from local socket Protected • Reflection attack sample • Pre-load app: Keystring_misc • Protected component:PhoneUtilReceiver • Permission: com.sec.android.app.phoneutil.permission • systemOrSignature level • Another app: FactoryTest • Feasible path: able to start this component of Keystring_misc • Cross app vulnerability path

26. Case study: Samsung S3 • sCloudBackupProvider app • Four content providers in the app with package name: • Com.sec.android.sCloudBackupProvider • Exposing access interfaces to databases • Calllogs.db, sms.db, mms.db, settings.db • Interfaces are protected by two normal-level permissions • Able to be accessed by any third-party app

27. Discussion • Software development policies • Sony • HTC • Popular product vs poor security level • Samsung S3 • Limitations • Not cover customization of system level code • High false positive rate of analysis • Manually verify avg. 300 paths per device • It would be better to use dynamic analyzer

28. Related work • Provenance Analysis • SMIT: malware database • DroidMOSS, DNADroid, PiggyApp: detecting repackaging app in markets. • Permission Usage Analysis • Pscout: overprivilege apps • Vulnerability Analysis • DroidRanger: detect malicious app in markets • TaintDroid, MockDroid, TISSA: privacy leaks • ComDroid, Woodpecker, CHEX: in-component vulnerability detection

29. Conclusion Evaluate the security impact of vender customizations Overprivilege app analysis Static reachability and reflection analysis