Presented by: Tom Staley

 Rising security concerns in the smartphone app community
 Use of private data:
 Passwords
 Financial records
 GPS locations
 Malware attacks have been found targeting smartphones

 Previous attempt by presenters to address security problems
 Tracks sensitive data as it flows between apps
 Raises an alert when sensitive data is transmitted off the phone
 Leaks are only found after the data has been lost

 Unlike PCs, the app market is highly centralized
 Scan apps as they join the market
 Currently applied manually, if at all
 Some banned behavior still slips through the cracks

 AppInspector
 Service run by market providers or by a third-party
 Uses multiple virtual smartphones to run instances of apps before they reach the market
 Entire process is automated to ensure thorough testing

 Three challenges with AppInspector
 How to track and log data
 How to determine security violations using the logs
 How to ensure all branches of code are covered

 Four main components
 Input generator
 Execution explorer
 Information flow tracker
 Security analyzer

 Security violation - when an app accesses data without permissions to do so
 Privacy violation – when an app discloses information without prompting the user
 AppInspector focuses on privacy violations

 Log data about explicit and implicit data flows
 Various actions also logged, like methods that access disk memory or device sensors
 Action logging has to be limited to reduce overhead

 Explicit data flow – following data through use of data dependencies
 Attach a “label” to data as it leaves the source of the data
 Track the label through the program until it reaches a
“sink”
 Implicit data flow – when sensitive information can be found by looking at control flow
 if (w == 0) x = y; else z = y;
 If w is privacy-sensitive, looking at values of x and z can determine if w == 0;

 Two methods to detect privacy violations
 When sensitive data is disclosed:


Use data dependency graph to trace sensitive data back to source
Check for user notifications or search license agreements for permissions

 App are event-driven
 Two types of events:
 UI inputs
 Callback triggers from device sensors
 These inputs can be randomly generated to test apps

 Randomly generating input is known as
Concrete Execution
 Developers tested this approach on 9 apps
 Fed constant stream of input for 30 minutes
 40% or lower code coverage found

 Another type of input testing known as symbolic testing
 Systematically tests all possible execution paths
 Highly inefficient

 Mix of concrete and symbolic execution
 Run symbolic execution on main application code
 All other code (code libraries, system code, etc.) tested with concrete execution
 Switch between the two methods as required during testing

 The app market is at risk for security and privacy violations
 AppInspector developed to scan apps before they reach marketplace
 Uses concolic execution to generate input
 Tracks sensitive data as it propagates through app
 Uses logs to determine if privacy violation has occurred

Peter Gilbert, "Vision: Automated Security Validation of
Mobile Apps at App Markets", MCS’11, June 28,
2011, Bethesda, Maryland, USA.