COVERT app

M.Tech (CSE) 1st semester

ABSTRACT• Problem: Enforcement of the permissions in

Android is at the level of individual apps, allowing multiple malicious apps to collude and combine their permissions or to trick vulnerable apps to perform actions on their behalf that are beyond their individual privileges.

• Research efforts are subject to a common limitation: they are intended to detect and mitigate vulnerabilities in a single app.

• COVERT’s analysis is modular and it statically analyzes the reverse engineered source code of each individual app, and extracts relevant security specifications in a format suitable for formal verification.

• Using COVERT to examine over 500 real-world apps corroborates its ability to find inter-app vulnerabilities in bundles of some of the most popular apps on the market.

INTRODUCTION• Previous techniques failed to identify vulnerabilities due

to the interaction of multiple apps, such as collusion attacks and privilege escalation chaining, which cannot be detected by analyzing a single app in isolation.

• COVERT increases the scope of application analysis This enables reasoning about the overall security posture of a system.

• The main objective of COVERT is to automatically– identify such vulnerabilities that occur due to the

interaction of apps comprising a system– by inferring the security properties from individual apps

and checking them as a whole by means of formal analysis

– determine whether it is safe for a bundle of apps, requiring certain permissions and interacting with each other, to be installed together.

• COVERT extracts essential information and captures them in an analyzable formal specification language and uses Alloy as a specification language, and the Alloy Analyzer as the analysis engine.

Android OverviewApplication ComponentsComponents are basic

logical building blocks of Android applications. There are four types of components:

• Activity • Service• Broadcast Receiver• Content Provider

IPCAndroid depends app insulation

to protect apps requires interactions to occur through a message passing mechanism, called inter-process communication. IPC is conducted by means of Intent messages.

Application ConfigurationEach Android application must

declare upfront its configuration. Component capabilities are specified as a set of Intent Filters that represent the kinds of requests a given component can respond to.

PermissionsEach application must declare

as part of its manifest the permissions it requires, and the Android system prompts the user for consent during the application installation.

Android platform provides over 130 pre-defined permissions, and apps can also define their own permissions.

Intent MessagesIntent message is an

event for an action to be performed along with the data that supports that action.

SandboxingSandboxing is a computer

security term referring to when a program is set aside from other programs in a separate environment so that if errors or security issues occur, those issues will not spread to other areas on the computer. 

Literature survey• Main focus of work is on performing program analysis over Android

applications for security and Android’s permissions and their use across applications. All the research work have never been evaluated over real-world applications.

• FlowDroid introduces a precise approach for static taint flow analysis for each app component. SCanDroid statically analyzes data flows to detect permission inconsistencies between apps that could possibly allow malicious access to sensitive information. It requires the source code of applications.

• TaintDroid detects information leak vulnerabilities using dynamic taint flow analysis at the system level. IPC Inspection prevents privilege escalation at OS level. Whyper is a tool that checks the app’s requested permissions against its description, enabling the user to determine if certain requested permissions are suspicious.

• Pscout is used to extract the permission specification from the Android OS source code using static analysis, leading to a comprehensive set of permission maps.

Architecture

COVERT

Parts

Model Extractor

Formal Analyzer

Models

App model

Android Framework spec.

Example scenarioA malicious app exploits the vulnerabilities of two other apps to send the device location data to the desirable phone number

Entity Extraction

and Resolution

Control Flow

Augmentation

Vulnerable Path

Identification

Static analysis technique

•Input as APK and app byte code•Generate app models (build on top of Soot and Dexpler)

Check for vulnerability

•Combine with formal spec of app framework•Alloy as specification language•Report of list of vulnerabilities

Method of Implementation1. MODEL EXTRACTORWe first need a model of each app to determine the inter-process communications and the security properties. A model for an Android application is a tupleA = <C, I, F, P,S >, where•C is a set of components, set of Intent messages, Intent filters, permissions and

set of sensitive paths•I is a set of event messages that can be used for both inter- and intra-app communications.•If component is non-empty, the Intent is called an explicit Intent, as the recipient is given explicitly.•F is a set of Intent Filters, describes an interface of c in terms of Intents that it can handle.•P is a union of required (Preq) and enforced permissions(Penf)•S is a finite set of vulnerable paths

Model Extractor

Formal AnalyzerAlloy Overview

Formal Model of Android Framework

Formal Model of Apps

Checking Android

Application models

There are four main reasons for choosing Alloy:1. Its comprehensible, object-oriented-like syntax, makes it useful for declarative specification of both apps and properties to be checked.2. Ability to automatically analyze specifications with no custom programming is useful as an automation mechanism.3. Effective module system allows us to split the overall, complicated system model among several tractable modules.4. The extraction approach to generate bundle specifications is incremental. Once an app model is extracted, it can be reused for analysis within several bundles of apps.

Formal Model of Android FrameworkThe analyzer provides two types of analysis: Simulation, in which the analyzer demonstrates consistency of model specifications by generating a satisfying model instance;Model Checking, which involves finding a counterexample a model instance that violates a particular assertion.There are six top-level signatures to model the basic element types: Application, Component, Intent Filter, Intent, Path, and Permission. These signatures are defined as abstract, meaning that they cannot have an instance object without explicitly extending them.

Formal model of appsThree pieces of Alloy specifications are conjoined in the process of modeling various parts of Android apps extracted from their APK files.

1. Specification module called appDeclaration

2. App model, represented in a separate Alloy module for each app.

3. Inter-process communication module that models all Intent messages created within app.

Checking Android Application modelsConsidering the privilege escalation, Davi et al state it as follows: “An application with less permissions (a nonprivileged caller) is not restricted to access components of a more privileged application (a privileged callee).”The assertion states that the

dst component (victim) has access to a permission (uses Permission) that is missing in the src component (malicious), and that permission is not being enforced in the source code of the victim component, nor by the application embodying the victim component.

Benefits

• COVERT can effectively detect inter-app vulnerabilities in few minutes.•Our prototype implementation of the approach only requires the availability of Android executable files, and not the original source code.•COVERT, can be used not only by developers, but also by end-users as well as third-party reviewers. •COVERT is implemented as a publicly available tool. We have built a prototype implementation of the model extractor component on top of the Soot static analysis tools for analyzing Java byte code. We use Dexpler transformer to translate Android’s dalvik bytecode into the Soot’s intermediate representation language, called Jimple.•All the research work have never been evaluated over real-world applications.

Mobile and Web-based applications

These work together to analyze the installed apps in a mobile device and generate the vulnerability report.

Applications

Desktop ClientDesktop Client is a JavaFX application that provides a

graphical user interface and enables end-users to analyze a set of APK files, which could be downloaded from online app stores such as Google Play.

Result AnalysisTo assess the effectiveness of our approach in revealing Android inter-app vulnerabilities, we have conducted an evaluation that addresses the following research questions:RQ1. What is the importance of this research? To what extent are Android apps over privileged and unsafe due to usage of permission-required APIs?RQ2. How well does COVERT perform? Does it enable compositional analysis of real-world Android apps? How much manual effort is involved in the analysis process?RQ3. What is the overall accuracy of COVERT in detecting inter-app vulnerabilities?RQ4. How does compositional analysis compare to single app analysis?RQ5. What is the performance of our prototype tool implemented atop SAT solving technologies and static analyzers?

Scatter plot for analysis time for model extraction of Android apps.

COVERT, a tool that analyzes Android applications in a compositional manner to detect inter-app and inter-component security vulnerabilities.COVERT comes with desktop, mobile and web-based front-end applications that facilitate the end-user interactions with the analysis engine.The experimental results corroborated its ability to reveal inter app vulnerabilities in real-world Android apps, many of which were previously unknown.

Conclusion

•COVERT can be extended, and significant components of it reused, for detecting other types of inter-app vulnerabilities, like application collusion and information leakage. For this, COVERT’s program analysis needs to be extended to take information flow into account for Android apps.•COVERT can be extended with dynamic analysis techniques which can be used to address vulnerabilities in native code. Android Apps may include native code in addition to Java code, in the form of a Java Native Interface (JNI) library, which cannot be sufficiently addressed through static analysis techniques.

future work

1. H. Bagheri, A. Sadeghi, J. Garcia, and S. Malek, “Covert: Compositional analysis of android inter-app vulnerabilities,” George Mason University, Tech. Rep.

2. K. W. Y. Au, Y. F. Zhou, Z. Huang, and D. Lie, “Pscout: Analyzing the android permission specification,” in Proceedings of CCS, 2012.

3. D. Jackson, “Alloy: a lightweight object modelling notation,” TOSEM,vol. 11, no. 2

4. E. Chin, A. P. Felt, K. Greenwood, and D. Wagner, “Analyzing inter-application communication in android,” in Proc. 9th Int.Conf. Mobile Syst., Appl. Services, 2011

5. L. Davi, A. Dmitrienko, A.-R. Sadeghi, and M. Winandy, “Privilege escalation attacks on android,” in Proc. 13th Int. Conf. Inf. Security, 2010

6. R. Pandita, X. Xiao, W. Yang, W. Enck, and T. Xie, “Whyper: Towards automating risk assessment of mobile applications,” USENIX Conf. Security, 2013

7. J. Woodcock, P. G. Larsen, J. Bicarregui, and J. Fitzgerald, “Formal methods: Practice and experience,” ACM Comput. Surv., vol. 41

8. D. Octeau, P. McDaniel, S. Jha, A. Bartel, E. Bodden,J. Klein, Y. L. Traon, Effective Inter-Component Communication Mapping in Android with Epicc:An Essential Step Towards Holistic Security Analysis, in: Proceedings of the 22nd USENIX Security Symposium, Washington, DC, 2013.

references

Vulnerability is not weakness. And that myth is profoundly dangerous. Vulnerability is the birthplace of innovtion, creativity and change.-Brene Brown