Lei Wu, Michael Grace, Yajin Zhou,
Chiachih Wu, Xuxian Jiang
Department of Computer Science
North Carolina State University
CCS 2013
 Introduction
 Design
• Provenance Analysis
• Permission Usage Analysis
• Vulnerability Analysis
 Reachability Analysis
 Reflection Analysis
 Implementation
and evaluation
• Provenance Analysis
• Permission Usage Analysis
• Vulnerability Analysis
 Discussion
 Related
work
 Conclusion
 Ten
representative stock Android images
 Five popular smartphone vendors
 To assess the extent of security issues
 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
 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.
 Architecture
of SEFA
 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
 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
 Permission overprivilege
• Initial permission set of apps
• Step1
 To generate the complete requested permission set: Rset
 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
 Algorithm
1
Initial R set
To generate the
complete R set
To generate the U
set
To generate the
permission
overprivilege set
 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
 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
 Algorithm
Appendix
• Execution flow
Check the
summary of each
callee c is
modified or not
invoking
inter-analysis
related to c (????)
????
 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
 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
vulnerable,
Add to V ifis
c is
vulnerable
add to V
• For all other components able to start
current component
 Do reflection analysis among them
• Return V
 SEFA
was written in Java and Python
 Processing time of each image:70 min
avg.
 Manual verify of vulnerabilities
 Baksmali
 Devices
2010-2012
 Permission
Usage Analysis
• % of Overprivilege apps
 87.96% -> 83.61%: avg.: 85.78%
 Vulnerabilities
• % of vulnerable apps
 Worst in %: HTC wildfire S, LG Optimus P880
 Vulnerabilities: customizations
• Customizations: vender and third-
parties
• % of vulnerable apps of
customizations
 Vulnerabilities
• Inherited: from previous product
• Introduced: new found in the new product
 Vulnerabilities
• Critical vulnerabilities
• Other: vendor- or model- specific
 Vulnerabilities: cross-app
vulnerabilities
• Difficult to detect
• % of cross-app vulnerabilities
 Reflection
Two hard-coded local
attack sample
socket:
 Pre-load app: Keystring_misc
FactoryClientRecv
FactoryClientSend
• Protected component:PhoneUtilReceiver
Able to receive command
• Permission:
from local socket
com.sec.android.app.phoneutil.permission
• systemOrSignature level
 Another
app: FactoryTest
Protected
• Feasible path: able to start this component of
Keystring_misc
• Cross app vulnerability path
 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
 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
 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
 Evaluate
the security impact of vender
customizations
 Overprivilege app analysis
 Static reachability and reflection analysis