1. Lei Wu, Michael Grace, Yajin Zhou, Chiachih Wu, Xuxian Jiang Department of Computer Science North Carolina State University CCS 2013

2.  Introduction  Design Provenance Analysis Permission Usage Analysis Vulnerability Analysis  Reachability Analysis  Re fl ection Analysis

3.  Implementation and evaluation Provenance Analysis Permission Usage Analysis Vulnerability Analysis  Discussion  Related work  Conclusion

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

5.  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.  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 secure than before.

7.  Architecture of SEFA

8.  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.  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.  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.  Algorithm 1 Initial R set To generate the complete R set To generate the U set To generate the permission overprivilege set

12.  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.  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 analysisdef- 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.  Algorithm Appendix Execution flow Check the summary of each callee c is modified or not invoking inter-analysis related to c (????) ????

15.  Reflection attack: ExampleExample  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.  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 Add to V if c is vulnerable

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

18.  Devices 2010-2012

19.  Permission Usage Analysis % of Overprivilege apps  87.96% -> 83.61%: avg.: 85.78%

20.  Vulnerabilities % of vulnerable apps  Worst in %: HTC wildfire S, LG Optimus P880

21.  Vulnerabilities: customizations Customizations: vender and third- parties % of vulnerable apps of customizations

22.  Vulnerabilities Inherited: from previous product Introduced: new found in the new product

23.  Vulnerabilities Critical vulnerabilities Other: vendor- or model- specific

24.  Vulnerabilities: cross-app vulnerabilities Difficult to detect % of cross-app vulnerabilities

25.  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 Two hard-coded local socket: FactoryClientRecv FactoryClientSend Able to receive command from local socket Protected

26.  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.  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.  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.  Evaluate the security impact of vender customizations  Overprivilege app analysis  Static reachability and reflection analysis