ABSTRACT ZHOU, YAJIN. Android Malware

ABSTRACT

ZHOU, YAJIN. Android Malware: Detection, Characterization, and Mitigation. (Under the direction of Xuxian Jiang.)

Recent years, there is an explosive growth in smartphone sales and adoption. The popularity is partially due to the wide availability of a large number of feature-rich smartphone applications (or apps). Unfortunately, the popularity has drawn the attention of malware authors: there were reports about malicious apps on both official and alternative marketplaces. These malicious apps have posed serious threats to user security and privacy. The primary goal of my research is to understand and mitigate the Android malware threats. In this dissertation, we first presented a systematic study to gain a better understanding of malware threats on both official and alternative app marketplaces, by proposing a system called DroidRanger to detect malicious apps on them. Specifically, we first proposed a permission- based behavioral footprinting scheme to detect new samples of known Android malware families. Then we applied a heuristics-based filtering scheme to identify certain inherent behaviors of unknown malware families. This study showed that there is a clear need for a rigorous vetting process, especially for non-regulated alternative marketplaces. After that, we characterized Android malware from various aspects to provide better insights of existing malware threats to the whole research community. That’s because without a deep understanding of Android malware, one can hardly imagine that effective mitigations could be proposed. The characterization and a subsequent evolution-based study of representative families revealed that they were evolving rapidly to circumvent the detection from existing mobile anti-virus software. The Android Malware Genome Project [11], spun off from this research, has helped researchers from more than 450 universities, research labs and companies all over the world to develop more effective solutions. In light of the threats, we further proposed a system called AppCage that thoroughly confines the run-time behavior of third-party Android apps. It leverages two complimentary user-level sandboxes to interpose and regulate the app’s access to sensitive APIs, and further block malicious behaviors of Android malware. Specifically, the first sandbox named dex sandbox hooks into the app’s Dalvik virtual machine instance and redirects each sensitive framework API to a proxy which strictly enforces the user-defined policies, and the second sandbox named native sandbox leverages software fault isolation to prevent app’s native libraries from directly access- ing the protected APIs or subverting the dex sandbox. Our evaluation showed that AppCage can successfully detect and block attempts to leak private information by third-party apps, and the performance overhead caused by AppCage is negligible for apps without native libraries and minor for apps with them. © Copyright 2015 by Yajin Zhou

by Yajin Zhou

A dissertation submitted to the Graduate Faculty of North Carolina State University in partial fulﬁllment of the requirements for the Degree of Doctor of Philosophy

Computer Science

Raleigh, North Carolina

2015

APPROVED BY:

Huiyang Zhou Vincent Freeh

Kapil Singh Xipeng Shen

Xuxian Jiang Chair of Advisory Committee DEDICATION

To my wife Lily, without whom I cannot survive sleepless nights during my PhD journey.

ii BIOGRAPHY

Yajin Zhou is originally from Jiangsu, China. He received his Bachelor of Science from Suzhou University in 2003, and Master of Science from University of Science and Technology of China in 2007, respectively. After that, he spent three years working as a software engineer in industry. Since summer 2010, he came to USA to pursue his Doctor of Philosophy degree in Computer Science under the direction of Dr. Xuxian Jiang. His research focused on proposing and de- veloping practical solutions to improve mobile security and privacy, mainly from the aspect of enriching the app ecosystem. Based on his research, he has cofounded the Android Malware Genome Project (http://www.malgenomeproject.org) and shared the dataset of representative Android malware with more than 450 universities, research labs and companies worldwide. He will graduate with a Ph.D. degree in Computer Science from the North Carolina State University in summer 2015, and join Qihoo 360, a leading security company in China.

iii ACKNOWLEDGEMENTS

First, I would like to thank my advisor, Dr. Xuxian Jiang, for his numerous help during my PhD study. I was inspired not only from his insights, but also his enthusiasm and the attitude of curiosity in research. I would like to thank Prof. Zhi Wang from Florida State University for his kind help and useful discussion. I am thankful to Prof. Vincent W Freeh, Prof. Huiyang Zhou, Prof. Xipeng Shen and Dr. Kapil Singh for their time and efforts severing in my PhD thesis committee and the insightful comments that helped to improve this dissertation. Second, I am grateful to many persons for their support: Dr. Kapil Singh from IBM T.J. Watson Research Center who was the mentor during my internship there in summer 2012, Prof. Dongyan Xu from Purdue University who provided useful advise and help during my job searching, Prof. Zhenkai Liang from National University of Singapore who was acting as my referee and gave me constructive advise, Prof. Peng Ning from NC State University and all my academic brothers in the Cyber Defense Labs, Jinku Li, Michael Grace, Wu Zhou, Chiachih Wu, Lei Wu, Kunal Patel. I am thankful to my friends at NC State University, Pu Yang, Xiaoling Huang, Yi Xu, Rong Jin, Zhiming Shen, Cunfang Shen, Wenbo Shen, Juan Liu. Special thanks to my old friends from Suzhou University and University of Science and Technology of China, Yi Luo, Yan Zhang, Xuhui Li, Zhen Huang, Chunguang Tang, and all the brothers from 311, Tao Wang, Lei Jin, Anquan Zheng, Kun Shen, Mingdong Zhang. I really miss our good old times together. Third, I am also grateful to organizations that generously funded my graduate research. The work in this dissertation was supported in part by US National Science Foundation (NSF) and the US Army Research Office (ARO) under several grants. As usual, any opinions, findings, and conclusions or recommendations expressed in this dissertation do not necessarily reflect the views of the NSF and the ARO. Last but certainly not least, I deeply appreciate the support and encouragement from my family, in particular my wife, Lily Xu, and our kid, Kevin Zhou. I cannot imagine how I can survive sleepless nights during my PhD journey without the strength gained from them. I am grateful to my parents, who were giving me the life and the best they have, and my aunt and uncle, who gave me the opportunity of better education, which has changed my entire life. Thanks for the help and encouragement from my two sisters. I cannot forget how they protected me when I was young. Also I would like to thank the help from my parents-in-law’s family.

iv TABLE OF CONTENTS

LIST OF TABLES ...... vii

LIST OF FIGURES ...... viii

Chapter 1 Introduction ...... 1 1.1 Background and Problem Overview ...... 1 1.2 Our Approach ...... 2 1.3 Dissertation Contributions ...... 4 1.4 Terminology ...... 5 1.5 Dissertation Organization ...... 6

Chapter 2 Related Work ...... 7 2.1 Android Malware Detection ...... 7 2.2 Android Malware Defense ...... 8 2.3 Mobile Application Security ...... 9 2.4 Software Fault Isolation ...... 11 2.5 Mobile Application Sandbox ...... 11

Chapter 3 Detecting Malicious Apps in Oﬃcial and Alternative App Market- places ...... 13 3.1 Introduction ...... 13 3.2 Design ...... 15 3.2.1 Detecting Known Android Malware ...... 16 3.2.2 Detecting Unknown Android Malware ...... 19 3.3 Evaluation ...... 21 3.3.1 Detecting New Samples of Known Malware ...... 22 3.3.2 Detecting Zero-day Malware ...... 26 3.3.3 Summary of Detected Malware ...... 28 3.4 Discussion ...... 28 3.5 Summary ...... 29

Chapter 4 Dissecting Android Malware: Characterization and Evolution ... 31 4.1 Introduction ...... 31 4.2 Malware Timeline ...... 33 4.3 Malware Characterization ...... 35 4.3.1 Malware Installation ...... 35 4.3.2 Activation ...... 41 4.3.3 Malicious Payloads ...... 42 4.3.4 Permission Uses ...... 47 4.4 Malware Evolution ...... 48 4.4.1 DroidKungFu ...... 48 4.4.2 AnserverBot ...... 50

v 4.5 Malware Detection ...... 51 4.6 Discussion ...... 53 4.7 Summary ...... 55

Chapter 5 Sandboxing Third-party Android Apps with Hybrid User-level Sandboxes ...... 56 5.1 Introduction ...... 56 5.2 Background and Threat Model ...... 58 5.2.1 Dalvik Virtual Machine ...... 58 5.2.2 Java Native Interface ...... 59 5.2.3 Dynamic Loading and Linking ...... 59 5.2.4 Threat Model ...... 60 5.3 System Design ...... 60 5.3.1 Overview ...... 61 5.3.2 Dex Sandbox ...... 62 5.3.3 Native Sandbox ...... 63 5.4 Implementation ...... 69 5.4.1 Dex Sandbox ...... 69 5.4.2 Native Sandbox ...... 70 5.4.3 Native Sandbox Optimizations ...... 73 5.5 Evaluation ...... 74 5.5.1 Eﬀectiveness of AppCage ...... 74 5.5.2 Security Analysis ...... 76 5.5.3 Compatibility of AppCage ...... 77 5.5.4 Performance Evaluation ...... 79 5.6 Discussion ...... 81 5.7 Summary ...... 82

Chapter 6 Conclusion and Future Work ...... 83

BIBLIOGRAPHY ...... 85

vi LIST OF TABLES

Table 3.1 The number of remaining apps after ﬁltering the repository with RECEIVE - SMS/SEND SMS permissions ...... 17 Table 3.2 The number (and percentage of) apps with native code not in the default location ...... 20 Table 3.3 Statistics of collected apps from existing app marketplaces ...... 21 Table 3.4 Ten known malware families used in this study ...... 22 Table 3.5 Essential permissions of 10 known malware families ...... 23 Table 3.6 The number of infected apps by 10 known malware families on 5 studied marketplaces ...... 24 Table 3.7 The missed known malware families by Lookout Security & Antivirus software ...... 25 Table 3.8 Two zero-day malware families detected by DroidRanger ...... 26 Table 3.9 The total number of malware samples detected by DroidRanger ...... 28

Table 4.1 The timeline of 49 Android malware in our collection ...... 34 Table 4.2 An overview of existing Android malware - Part I: installation and activation 36 Table 4.3 The (abbreviated) Android events/actions Of interest to existing malware . . 39 Table 4.4 The list of platform-level root exploits and their uses in existing Android malware ...... 42 Table 4.5 An overview of existing Android malware - Part II: malicious payloads . . . 44 Table 4.6 The overview of six DroidKungFu malware families ...... 48 Table 4.7 Detection results from four representative mobile anti-virus software . . . . . 52

Table 5.1 Conﬁned operations by the current prototype ...... 69 Table 5.2 AppCage successfully blocks malicious behaviors of samples in 15 malware families ...... 74 Table 5.3 AppCage detects malicious behaviors ...... 75 Table 5.4 Some apps used in compatibility test ...... 78 Table 5.5 Code size increase ...... 79

vii LIST OF FIGURES

Figure 1.1 An overview of the dissertation ...... 2

Figure 3.1 The overall architecture of DroidRanger ...... 15 Figure 3.2 The list of commands supported in Plankton ...... 27

Figure 4.1 The Android malware growth in 2010-2011 ...... 33 Figure 4.2 An update attack from BaseBridge ...... 38 Figure 4.3 An update attack from DroidKungFuUpdate ...... 40 Figure 4.4 An update attack from AnserverBot ...... 40 Figure 4.5 The comparison of top 20 requested permissions by malicious and benign apps ...... 47

Figure 5.1 ClassObject and Method in Dalvik ...... 59 Figure 5.2 System architecture of AppCage ...... 60 Figure 5.3 Dalvik hooking of SmsManager.sendTextMessage ...... 62 Figure 5.4 Instrumentation of native code by AppCage ...... 66 Figure 5.5 Memory layout of the native sandbox ...... 70 Figure 5.6 An example of indirect branch trampoline ...... 72 Figure 5.7 CaﬀeineMark with and without AppCage ...... 80 Figure 5.8 Normalized overhead of the native sandbox ...... 81

viii Chapter 1

Introduction

1.1 Background and Problem Overview

Recent years, there is an explosive growth in smartphone sales and adoption. The report from Gartner showed that there were over 968 millions of smartphones sold in the year of 2013, and this was the first time that smartphone sales surpassed sales of feature phones [47]. The popularity is partially propelled with the large collection of feature-rich smartphone applications (or apps) in various marketplaces. For example, the number of total apps on official app market, i.e., the Google Play, has reached 1.5 million in June 2014 [1]. Moreover, in addition to the official marketplaces, there also exist a number of third-party or alternative ones (e.g., Amazon AppStore for Android [7]), which further boost the popularity. These centralized marketplaces or app stores streamline the process of browsing, downloading and installing a variety of apps - therein facilitating the use of smartphones. Unfortunately, such popularity has drawn the attention of malware authors. For instance, DroidDream [94] and DroidDreamLight [113] were detected from the official app market in March and May 2011, respectively. In September 2011, a highly sophisticated Android trojan using public, encrypted blog entries for command and control (C&C) was identified by researchers [16]. It has been highlighted [77] that “among all mobile malware, the share of Android-based malware is higher than 46% and still growing rapidly.” According to the latest report from Lookout, in year 2014 there was an astounding 75% increase in Android mobile malware encounter rates in the United States compared to year 2013 [2]. The rapid growth of Android malware has posed serious threats to user security and privacy. The malware could steal user private data, cause financial loss and even exploit system vulnerabilities to gain higher privilege. After that, malicious apps could turn the compromised

1 Detecting Dissecting Sandboxing Malicious Apps in Android Malware: Third-party Android Official and Alternative Characterization Apps with Hybrid App Marketplaces and Evolution User-level Sandboxes

Figure 1.1 An overview of the dissertation phones into a botnet controlled through Internet or short message. For instance, the Droid- Dream malware attempts to gain the root privilege of the system by exploiting a known system vulnerability. Then it downloads and installs more malicious apps in the background without user’s awareness, and performs further malicious operations. Because of the rapid growth of malicious apps and the serious consequences that could be caused, there is a pressing need to eﬀectively mitigate or defend against them.

1.2 Our Approach

In this dissertation, we first presented a systematic study to understand the overall health of existing app marketplaces in Chapter 3. Then to gain a better understanding of Android malware threats, we systematically characterized Android malware from various aspects, including their installation methods, activation mechanisms as well as the nature of carried payloads in Chap- ter 4. This study has provided insights and a comprehensive malware dataset to the research community to help develop more effective defense solutions. At last, in Chapter 5 we proposed a novel and practical system using hybrid user-level sandboxes to mitigate Android malware threats. This system is able to thoroughly confine the run-time behavior of third-party Android apps and block the malicious operations based on user provided policies. It does not need any framework modifications or the root privilege, thus can be readily deployed. Figure 1.1 shows the overview of this dissertation. Specifically, in Chapter 3, we tried to understand the overall health of existing app marketplaces, including both official and alternative (or third-party) ones. In particular, our goal here is to detect malicious apps on these marketplaces. For that purpose, we used a crawler to collect all possible (free) apps we can obtain from five representative marketplaces within a two-month period. In total, we collected 204, 040 apps. Then we took the following approaches to detect malicious ones among them. (1) First, in order to detect the infection from known malware families, we proposed a scalable and efficient scheme called permission-based behavioral footprinting. Instead of taking a traditional approach with content invariants as malware

2 signatures, our scheme took a scalable design by initially filtering out these apps based on the inherent Android permissions required by the malware for its wrongdoings and then matching them with malware-specific behavioral footprints (that characterize the malware behavior). (2) Second, in order to detect unknown malware, we proposed a heuristics-based filtering scheme that defines suspicious behaviors from possibly malicious apps and then used them to detect suspicious apps. Example heuristics include the attempts to dynamically fetch and execute code from a remote untrusted website. For each suspicious app, we further dynamically monitored its runtime execution to confirm whether it is truly malicious or not. If the app is malicious and does not appear in our (malware) database, we considered it as zero-day malware and then generated the corresponding permission-based behavioral footprint in a feedback loop to detect other samples in the collection. Then, in Chapter 4, we characterized existing Android malware families based on the samples collected through various channels to better understand Android malware threats and provide insights to the research community. First, we presented the first large collection of 1260 Android malware samples in 49 different malware families. Second, based on the collected malware samples, we performed a timeline analysis of their discovery and thoroughly characterized them based on their detailed behavior break-down, including the installation, activation, and payloads. The timeline analysis is instrumental to revealing major outbreaks of certain Android malware in the wild while the detailed breakdown and characterization of existing An- droid malware is helpful to better understand them and shed light on possible defenses. Third, we performed an evolution-based study of representative Android malware, which showed that they were rapidly evolving and existing anti-malware solutions were seriously lagging behind. For example, it is common for Android malware to have encrypted root exploits or obfuscated command and control (C&C) servers. The adoption of various sophisticated techniques greatly raises the bar for their detection. At last, we proposed a system named AppCage to defend against Android malware threats in Chapter 5. AppCage leverages two complimentary user-level sandboxes to regulate the app’s access to sensitive APIs and dangerous operations (e.g., making phone calls), and further block malicious behaviors of Android malware. Like other in-app mechanisms [20, 30, 31, 61, 121], AppCage does not need changes of Android framework, nor requires the root privilege, thus can be readily deployed. Specifically, AppCage synthesizes a wrapper app for each target app (i.e., a third-party app to be confined). The wrapper sets up the first sandbox, i.e, dex sandbox, for the app by hooking into its instance of Dalvik virtual machine and redirecting sensitive framework APIs to their respective stubs. The stubs interpose the access to those APIs and enforce the user-defined policies. However, API hooking alone could be subverted by the app using native

3 code. To address this challenge, AppCage relies on a second sandbox, native sandbox, to confine the app’s native code. The native sandbox leverages software fault isolation (SFI) [115] to ensure that the app’s native libraries (including the system libraries they depend on) cannot escape from the sandbox or directly modify the code or data outside the sandbox. The app thus cannot tamper with the dex sandbox using native code. In addition, native sandbox prevents the app’s native code from directly requesting sensitive data or performing dangerous operations via binder [22], the Android’s ubiquitous inter-process communication mechanism. Combining those two sandboxes, AppCage can comprehensively interpose the app’s access to key Android APIs and enforce user-defined policies to block malicious operations of Android malware. We have implemented a prototype of AppCage and evaluated its effectiveness, compatibility, and performance. Our experiments showed that AppCage can successfully detect and block attempts to leak the user’s private data by both malicious and benign-but-invasive Android apps, and the security analysis demonstrated that native sandbox can protect our system from being bypassed or subverted. Moreover, the prototype is shown to be compatible with the popular Android apps we downloaded from the Google Play, and it incurs negligible overhead for apps without native code and minor for ones with native code.

1.3 Dissertation Contributions

The contributions of this dissertation are threefold: the detection, characterization and mitigation of Android malware.

• Detection of Android malware We have conducted the first systematic study to understand the overall health of both official and alternative Android marketplaces. We collected 204, 040 Android apps from various marketplaces and then proposed two different schemes to detect malicious apps among them. We believe this was one of the most extensive study ever performed at that time.

• Characterization of Android malware We have characterized the existing Android malware from various aspects. This study provided insights of the existing Android malware and a comprehensive malware dataset to the whole research community. It has had a real impact on both academia and industry. The Android Malware Genome Project [11], spun oﬀ from this research, has helped researchers from more than 450 universities, research labs and companies all over the world to better understand malware threats and develop more eﬀective solutions.

4 • Mitigation of Android malware We have proposed a system called AppCage to mitigate the Android malware threats. This system thoroughly conﬁnes the run-time behavior of third-party Android apps without requiring framework modiﬁcations or root privilege. It leverages two complimentary user-level sandboxes to interpose and regulate the app’s access to sensitive APIs, and further block the malicious operations of Android malware. Our evaluation showed that AppCage can successfully detect and block attempts to leak private information by malicious apps, and the performance overhead caused by AppCage was negligible for apps without native libraries and minor for apps with them.

1.4 Terminology

This section establishes the terminology that is used in this dissertation.

• App Marketplace: An app marketplace is a centralized place for developers to upload their apps, and users to download and install the apps. There are two different types of app marketplaces, i.e., official ones and alternative ones. The official app marketplaces are the ones created by the smartphone platform vendors, including Google and Apple. They are usually pre-installed on the shipped devices. For instance, the Google Play is the official app marketplace that is pre-installed on most Android devices. Besides the official ones, there also exist some alternative app marketplaces, mainly due to regional or localization reasons. In this dissertation, we also use other terms app market, app store for same meanings.

• Android Malware: Android malware means malicious apps targeting the Android platform. These malicious apps could steal user private data without user awareness, cause ﬁnancial loss to users or exploit system vulnerabilities to gain high privilege and perform further malicious operations. Malicious apps are deﬁned by their malicious intentions, which are not the part of legitimate functionalities of apps.

• App Permission: Permissions of an app deﬁne the privileges of the app to perform system-wide operations. These permissions are requested by app developers and need to be approved by users during app installation.

• App Repackaging: App repackaging is the behavior of repackaging and redistributing apps, usually without the permission of original app developers. During this process, malicious payloads could be injected into the repackaged apps.

5 • Update Attack: Update attack is one way used by attackers to trick users to install malicious apps. These malicious apps are usually disguised as the updated version of benign apps. After being installed, malicious payloads will be triggered and executed.

• Dalvik Virtual Machine: Dalvik virtual machine is the one used by the Android operating system to execute Android apps. The app is programed using the Java language and then transformed to the dex byte code executed on the Dalvik virtual machine.

• JNI: JNI is the acronym of Java Native Interface. It is a framework that enables the byte code running in Java virtual machine to invoke or to be invoked by native functions which are programed using native languages, including C, C++ and assembly. This technology is used in Android operating system to invoke functions from the byte code running on the Dalvik virtual machine to the native functions, or vice versa.

• Sandbox: Sandbox is a security mechanism to run untrusted code in an environment that could conﬁne the behaviors of untrusted code. It has been proposed and widely used to isolate untrusted and potentially malicious software components.

• Software Fault Isolation: Software fault isolation is a technology that could be used to implement a sandbox. It usually leverages a software to instrument the original program to isolate untrusted components, so that the compromised or malicious components will not be used to compromise the whole system. Software fault isolation systems usually leverage hardware features to be eﬀective.

1.5 Dissertation Organization

The rest of this dissertation is organized as follows. First, we will introduce closely related work in Chapter 2. Second, we will present a systematic study to understand the overall health of the app marketplaces in Chapter 3. After that, we characterize and study the evolution of Android malware in Chapter 4. At last, to defend the Android malware threats, we propose a system using hybrid user-level sandboxes to conﬁne the runtime behaviors of Android apps in Chapter 5. Finally, we conclude this dissertation and propose possible future directions in Chapter 6.

6 Chapter 2

Related Work

In this chapter, we introduce and compare related work in the areas of Android malware, mobile app security, software fault isolation and mobile application sandbox, the main components in this dissertation.

2.1 Android Malware Detection

The first category of related work includes the ones that leverage static, dynamic or hybrid program analysis techniques to detect malicious Android apps. RiskRanker [51] determined the risk category based on the dangerous behaviors of apps and then the selected apps were manually analyzed to detect malicious ones. WHYPER [80] used natural language processing to bridge the gap between user expectations and app functionality in order to aid the risk assessment of third-party apps. Peng et al. used probabilistic generative models to rank the risks of Android apps [83]. Since malicious apps usually transmit private data in the background without user’s intention, it’s important to detect whether the data transmission is intended. AppIntent [123] was such a system. It used the symbolic execution to generate the event sequences that can lead to the data transmission, then the generated sequences can help an analyst to determine if the data transmission is user intended or not. FlowDroid [17] performed accurate static taint analysis on Android apps based on a precise model of Android app’s lifecycle. The context-, flow-, field- and object-sensitivity allowed the analysis to reduce the false alarms. We note that Google Bouncer [9] was developed to vet and block malicious ones before they were admitted to the Google Play. While the details behind Google bouncer was un- clear, researchers found that it used an emulator to dynamically test the uploaded apps [91]. TaintDroid [37] leveraged the dynamic taint analysis to detect the privacy leakage of Android

7 apps. It tracked the taint tags on the level of Dalvik virtual machine, and had a relatively small performance overhead compared with other taint tracking systems. Also it tracked the information flow in the file system. DataChest [142] tracked information flow of unstructured data, a type of private data whose semantics could not be inferred from the platform APIs. AppsPlayground [88] was a framework to automatically detect and analyze Android (malicious) apps by performing the dynamic taint tracking, API monitoring, and kernel-level monitoring. To increase the code coverage, it proposed mechanisms to trigger the execution of the app code. VetDroid [131] leveraged TaintDroid and implemented a permission-based taint analysis. The evaluation result showed that it could find more privacy leaks than TaintDroid and was able to find the causes of the leaks. Mobile-Sandbox [107] combined both static and dynamic analysis to detect malicious apps. It first used the static analysis to find the permissions requested by the app and then disassembled the code to find the dangerous methods, strings and etc. Then it leveraged the dynamic analysis model to log runtime information of the app. CopperDroid [90] and DroidScope [122] were two systems that dynamically analyzed the behaviors of malicious Android apps.

2.2 Android Malware Defense

To mitigate Android malware threats, researchers have proposed a number of systems to enable fine-grained and runtime control of Android apps. They roughly fall into the following two categories. The first category consists of solutions that extend the Android framework (and the kernel) to allow fine-tuning of the apps’ permissions [21, 24, 26, 57–59, 75, 117, 119, 138, 142]. By doing so, malicious behaviors of the malware will be blocked at runtime. The (experimental) permission manager [58] was introduced in Android version 4.3 as a hidden service. It allowed the users to configure the permissions of the installed apps. For instance, the users could allow some permissions and deny other permissions of the installed apps. Though this service cannot block the installation of the malicious apps, however, it could block the malicious behaviors at runtime and protect users. AppFence [59] and TISSA [138] can be configured to return the mock private data, instead of the real one, to the apps. In this case, the malicious apps could only retrieve the fake private data, not the real one. AirBag [119] leveraged the virtualization technique to enhance the popular Android platform and boost the defense capability against Android malware. It created an isolated runtime environment for the untrusted Android apps and mediated their access to various system resources. Framework enhancement appears to be a natural solution to the problem. However, the requirement to update key Android components

8 could strongly impair their practical deployment. Even the adoption of the official (experimental) permission manager [58] could take a long time due to the deep fragmentation of the Android platform [10, 120, 137]. The second category includes the “in-app” mechanisms that control the app’s access to sensitive APIs through (Dalvik) bytecode rewriting [20, 31, 61, 89] or native code interposing [121]. RetroSkeleton [31] was an app rewriting framework to intercept the method invocations. It could enforce the security policies for each target apps. By setting up proper policies, malicious behaviors of apps could be detected and blocked. I-ARM-Droid [30] identified a set of security- sensitive API methods and specified their security policies. Then the policies were enforced by rewriting the Dalvik code of the app. These systems do not require changes to the Android framework and thus can be readily deployed. However, dynamically loaded classes (e.g., classes loaded by DexClassLoader) could pose serious challenges to these systems. On the other hand, Aurasium [121] interposed the inter-process communication [22] between the app and remote Android services. Therefore, it can accommodate dynamic classes, but has to bridge the “semantic gap” by reconstructing high-level semantics from the exchanged raw messages, overall a tedious and error-prone task. For instance, Aurasium has to reconstruct the high-level semantics of detailed IPC calls to the remote system service to enforce the policies. More importantly, all those systems can be bypassed or subverted by a malicious app using a native library. For example, the app can leverage native code to tamper with the instrumented bytecode [12] or skip security checks by “restoring the global offset table entries” [121]. The limitations of these systems motivated us to propose a novel and practical defense mechanism in Chapter 5.

2.3 Mobile Application Security

In the area of understanding and improving mobile app security, the ﬁrst category of related work includes the ones that detect and mitigate the confused-deputy problem [56] of Android apps. Researchers found that the confused-deputy problem exists in both third-party apps [41, 140] and preloaded apps [52, 120]. Woodpecker [52] analyzed eight popular Android devices and discovered that the preloaded apps does not properly enforce Android permissions. As a result, a malicious app would leverage the capability of other preloaded apps to perform malicious behaviors, without having the required permissions. Woodpecker found that 11 of 13 privileged permissions (or capabilities) could be leaked in the studied phones. ContentScope [140] systematically studied two types of vulnerabilities, i.e., passive content leak and content pollution. These two vulnerabilities were due to the open property of an Android component: content provider. The result showed that among the examined 62, 519 apps, 1, 279 and 871

9 were susceptible [140]. To effectively detect the confused-deputy problem, researchers have proposed various tools to statically analyze Android apps. For instance, CHEX [68], Epicc [78] and ComDroid [27] analyzed the communication between different components and found potential security risks existing in the apps. Accordingly, to deal with this problem, QUIRE [32] and Felt et al. [41] offered extensions to the Android IPC model that allow the ultimate imple- mentor of a privileged feature to check the IPC call chain to ensure unprivileged apps cannot launch confused-deputy attacks unnoticed. Similarly, Bugiel et al. [25] used a runtime monitor to regulate communications between apps. The second category includes the ones that expose privacy risks due to in-app ad libraries. AdRisk was a system [53] that systematically identified potential risks posed by existing in- app ad libraries. Although the ad libraries identified by AdRisk do not seem to have malicious intentions, they usually contain potential risks ranging from leaking user’s private information to executing untrusted code from the Internet. Another work [23] took a sample of 114, 000 apps and then extracted and classified their ad libraries. They found that the use of permissions has increased over the last several years, and more libraries were able to use permissions that pose particular risks to user privacy and security. To address the privacy concerns of the in-app ad libraries, several solutions have been proposed. AdDroid [82] was proposed to integrate the advertising libraries into the Android framework. The AdSplit approach [105] was proposed to separate the application and its advertisement library by running them in different processes. Zhang et al. proposed Activity Frame (AFrame) [130] to provide permission, display and input isolation of ad libraries. The third category includes the ones to detect app repackaging. Such systems include DroidMOSS [133], PiggyApp [135], DNADroid [29], AppInk [134] and DIVILAR [136]. Droid- MOSS [133] used the fuzzy hashing to detect the repackaged apps (potential malware) in third- party android markets. The experiments with 22, 906 apps showed that 5% to 13% of these apps were repackaged. The repackaged apps were mainly used to replace in-app advertisements or inject malicious payloads. PiggyApp [135] proposed an efficient method to detect piggybacked apps, which were one special kine of repackaged apps. The basic idea is that the injected payload is often not an integral part of the repackaged app. PiggyApp first decoupled an app into primary and non-primary modules. Then various semantic features of the primary modules were extracted and converted into vectors. At last an efficient search algorithm was developed to compare the similarities of the feature vectors. To defeat the threats of app repackaging, a watermarking mechanism was proposed in AppInk [134]. In particular, for each app under the protection, AppInk generated a new app with a watermark and another manifest app. Then the manifest app was used to recognize the embedded watermark. DIVILAR [136] is a virtualization-

10 based mechanism to deal with the app repackaging threat. In encoded the instruction set of an Android app into diﬀerent forms and leveraged the customized virtual machine to execute the encoded instruction set.

2.4 Software Fault Isolation

The third piece of this dissertation, i.e., the user-level sandboxes to confine runtime behaviors of Android apps, leveraged the software fault isolation (SFI) technology to sandbox native code. SFI has been widely researched and deployed [45, 63, 71, 81, 104, 115, 124, 129, 132]. Most of these systems targeted the x86 architecture [45, 63, 71, 81, 124, 129]. ARMor [132] was a system providing SFI for the ARM architecture. However it did not support dynamic linking, and has a high performance overhead which makes it impractical for real deployment. Native Client for ARM [104] provided a customized compiler to generate confined ARM binaries. It thus required source code access which is not available for the app’s native code. ARMlock [141] implemented an efficient fault isolation solution. However it required the support from kernel space and thus cannot be used without the change to the phone’s firmware. Robusta [106] and Arabica [108] were two closely related systems. They leveraged Native Client and the JVMTI (JVM Tool Interface) to sandbox the native libraries of JVM, respectively. Robusta recompiled the source code of the native libraries, and Arabica needed the support of JVMTI that is unavailable in Dalvik VM. Klinkoff et al. proposed a SFI mechanism to protect managed code and the .NET run-time from the unmanaged code (or native code) [64]. It isolated unmanaged code in a separate process. Similarly, the NativeGuard [109] leveraged the process boundary to isolate untrusted native libraries.

2.5 Mobile Application Sandbox

With the ability of Bring Your Own Device(BYOD) to the enterprise, diﬀerent types of mobile application sandboxes have been proposed to secure the enterprise data. For example, divide [34] provided a sandbox based solution to secure enterprise data. It used a separate app on the phone which has the functionalities that are needed by enterprise users, e.g., sending emails and encrypting ﬁles. This type of sandbox could secure the data running inside the app. However, since the sandbox is still a normal app, it cannot prevent the data from being leaked if the malicious app obtains the higher privilege. Due to this limitation, researchers have proposed the sandbox based on virtualization technology. For instance, VMWare proposed a mobile hypervisor which could run two virtual phones at the same time. One phone is for business and

11 another one is for personal use. Our work AppCage is different from these two types of mobile application sandboxes because we have different security model. The purpose of AppCage is to confine the behavior of untrusted third-party apps, while other systems are to protect the enterprise data on the phone.

12 Chapter 3

Detecting Malicious Apps in Oﬃcial and Alternative App Marketplaces

3.1 Introduction

In this chapter, we will present a systematic study to understand the overall health of existing app marketplaces. With the popularity of smartphones and mobile apps, these marketplaces have become the centralized places for developers to upload their apps and users to download and install apps. There are two types of app marketplaces, i.e., official app marketplaces provided by platform vendors, e.g., Google and Apple, and alternative ones mainly for localization purpose. These marketplaces further boost the popularity of smartphones since they streamline the process of browsing, downloading and installing a variety of apps - therein facilitating the use of smartphones. Unfortunately, such popularity has drawn the attention of malware authors. A few reports [94, 95, 113] already showed the presence of malicious apps in these marketplaces. For instance, DroidDream [94] and DroidDreamLight [113] were detected from the official app marketplace, i.e., the Google Play, in March and May 2011, respectively. While these reports offer detailed analysis about the spotted (individual) malware, they do not provide a systematic view of the overall health of existing app marketplaces. Enck et al. [38] studied 1, 100 free apps from the Google Play and attempted to understand a broad range of security-related metrics among them (as an indication of the overall app security). However, the study is limited in only examining a small number of apps, i.e., top 50 free apps from the 22 app categories. The main purpose of this study is to understand the overall situation of existing app marketplaces, including both official and alternative (third-party) ones. In particular, our goal here

13 is to detect malicious apps on these marketplaces. To do that, we used a crawler to collect all possible (free) apps we can obtain from five representative marketplaces within a two-month period. In total, we have collected 204, 040 apps. To detect malware infection among them, we took the following approach. (1) First, in order to detect the infection from known malware, we propose a scalable and efficient scheme called permission-based behavioral footprinting. Instead of taking a traditional approach with content invariants as malware signature, our scheme takes a scalable design by initially filtering out these apps based on the inherent Android permissions required by the malware for its wrongdoings and then matching them with malware-specific behavioral footprints (that characterize the malware behavior – Section 3.2.1). (2) Second, in order to detect unknown malware, we propose a heuristics-based filtering scheme that defines suspicious behaviors from possibly malicious apps and then uses them to detect suspicious apps (Section 3.2.2). Example heuristics include the attempts to dynamically fetch and execute code from a remote untrusted website. For each detected suspicious app, we further dynamically monitor its runtime execution to confirm whether it is truly malicious or not. If the app is malicious and does not appear in our (malware) database, we consider it zero-day and then generate the corresponding permission-based behavioral footprint in a feedback loop to detect other samples in the collection. We have implemented both schemes in a system called DroidRanger and used the system to detect infected apps in the collected 204, 040 samples from five different marketplaces. Among the collected apps, 153, 002 of them come from the Google Play and the rest 51, 038 apps come from four other (alternative) marketplaces. To evaluate the effectiveness of our system, we have initially generated behavioral footprints from 10 known Android malware families1. Based on these footprints, DroidRanger successfully detected 171 infected apps among our collection: 21 infected apps in the Google Play and 150 in four other alternative marketplaces. Moreover, we have implemented two additional heuristics to capture suspicious dynamic code loading behavior, either remotely or locally. These two heuristics effectively lead to the discovery of two sophisticated zero-day malware with 40 samples in our collection (Section 3.3)2. Overall, by combining both schemes to detect known and zero-day Android malware, DroidRanger reported 211 infected apps in our collection. If we calculate the infection rate, about 0.02% of apps from the Google Play are infected while 0.20% to 0.47% of apps from alternative marketplaces are infected. As a result, the infection rate in alternative marketplaces is an order of magnitude higher than the Google Play. Considering the recent trend in observing an unprece-

1The list of known Android malware is shown in Table 3.4. 2To better protect users, we have promptly provided samples of these zero-day malware to leading mobile anti-virus software vendors. They are now detectable by most mobile anti-virus software.

14 Malware Samples

Permission −Based Official App Marketplace Behavioral Footprints

Footprint−Based Infection from M1 Detection Engine Known Malware

App M2 Repository Alternative Heuristics−Based Infection from App Marketplaces M3 Detection Engine Zero−day Malware

M4 Heuristics

Representative App Marketplaces DroidRanger

Figure 3.1 The overall architecture of DroidRanger dented growth of mobile malware, we believe these results pose a clear call for better security protection in both oﬃcial and alternative marketplaces. The rest of this chapter is organized as follows: We ﬁrst describe the overall system design of DroidRanger in Section 3.2. We then present the system prototype and related evaluation in Section 3.3. After that, we discuss possible limitations and future improvements in Section 3.4. Finally, we summarize our work in Section 3.5.

3.2 Design

To systematically detect malicious apps in existing app marketplaces, we have three key design goals: accuracy, scalability, and efficiency. Accuracy is a natural requirement to effectively detect malicious apps in current marketplaces with low false positives and negatives. Scalability and efficiency are challenging as we need to accommodate the large number of apps that need to be scanned. Specifically, with our current collection of more than 200, 000 apps, if it takes 6 seconds to examine a single app, a full scanning of the collection for known malware will require more than two weeks to complete. In other words, the traditional approach of performing deep scanning (with content invariants as signatures) for each app may not be desired in this study. Therefore, in our design, we choose to take advantage of the unique information embodied in each app (i.e., various Android permissions in the app-specific manifest file) and develop

15 a scheme called permission-based behavioral footprinting for scalable and efficient malware detection. For unknown malware, we choose to devise a few heuristics that define suspicious behaviors from possibly malicious apps and then use them to effectively identify suspect apps for runtime monitoring. Figure 3.1 shows an overview of our approach. In essence, DroidRanger leverages a crawler to collect Android apps from existing app marketplaces and saves them into a local repository. For each collected app, DroidRanger extracts fundamental properties associated with each app (e.g., the requested permissions and author information) and organizes them along with the app itself in a central database for efficient indexing and lookup. After that, in order to detect potentially malicious apps, we take an approach with two different detection engines. The first detection engine (or footprint-based detection engine) is tailored to detect known malware. Specifically, each known malware will be first pre-processed or distilled into a so-called permission-based behavioral footprint. Each footprint essentially contains necessary Android permissions requested by the malware and succinctly summarizes the wrongdoings. These footprints are essentially the key to meet the scalability and efficiency requirements. The second detection engine (or heuristics-based detection engine) aims to uncover malware that has not been reported before. In particular, it recognizes suspicious behaviors from possibly malicious apps and detects certain Android features that may be misused. By doing so, we can identify suspicious apps and each will then be executed and monitored to verify whether it indeed exhibits any malicious behavior at runtime. If so, the app will then be manually confirmed and the associated behavioral footprint will be extracted and included in the first detection engine. In the following, we examine each detection engine in detail.

3.2.1 Detecting Known Android Malware

To meet the scalability and accuracy requirements, our first detection engine is divided into two steps: permission-based filtering and behavioral footprint matching. The first step aims to quickly exclude unrelated apps to obtain a more focused set of apps, which will then be used in the second step for detailed malware behavior matching. Permission-based filtering As mentioned earlier, a significant challenge in designing DroidRanger is how to handle hundreds of thousands of apps in a scalable and efficient way. To address it, we observe that each Android app has to explicitly declare the permissions it requires in its manifest file. Thus, we could use essential permissions for the malware’s functionalities to filter out unrelated apps (that do not declare these permissions). By doing so, we can possibly significantly reduce the number of apps that need to be processed in the second step. Therefore,

16 Table 3.1 The number of remaining apps after ﬁltering the repository with RECEIVE SMS/SEND SMS permissions

RECEIVE SMS Permission RECEIVE SMS SEND SMS & SEND SMS Apps 5, 214 8, 235 3, 204 Percentage 2.85% 4.50% 1.75% our system can remain efficient even though our second step may involve expensive or time- consuming methods for deep scanning or thorough analysis. For illustration, we use two functionalities that are often misused by Android malware: sending SMS messages and monitoring SMS messages. For instance, the Zsone malware [102] is designed to send SMS messages to certain premium numbers, which will cause financial loss to the infected users. To hide these SMS messages from users, the malware also monitors received SMS messages and removes billing-related notifications. In Android, to use these two functionalities, an app needs to request SEND SMS and RECEIVE SMS permissions, respectively. Therefore, to detect this type of malware, we can first scan the app repository with these two permissions. In Table 3.1, we show the number of apps after we apply the filtering based on these two permissions in our collection: 5, 214 apps request the RECEIVE SMS permission, which means 97.15% of apps do not need to be considered further for this type of malware. Similarly, filtering the repository with SEND SMS removes 95.50% of apps from consideration. Combining these two permissions together, only 1.75% apps remain. Our experience (Section 3.3.1) indicates that permission-based filtering is generally effective, even though the final results may depend on the popularity of the permissions of interest. In one case of our study, only 0.66% apps are needed to be processed in our second step. We stress that in the selection of permissions for filtering, it is important to choose only essential ones. Including non-essential permissions will unnecessarily exclude apps, which leads to false negatives. For instance, considering a trojanized app with bot functionalities, we may select the permissions required for its command and control channel, but not those required by optional payloads (that could be easily changed from one variant to another). In our study, we have experienced one case with respect to the the Pjapps [15] malware. In particular, the malware requires the INTERNET permission to support the communication with the remote bot server and the RECEIVE SMS permission to intercept or monitor incoming SMS messages. However, some variants may have the payload to add bookmarks to the built-in web browser (requiring WRITE HISTORY BOOKMARKS) and others do not. As such, we should only choose INTERNET and RECEIVE SMS as the essential ones, not WRITE HISTORY BOOKMARKS.

17 Behavioral footprint matching Our first-step screening is effective in significantly reducing the number of apps for examination. However, it may leave thousands of apps, which means manual analysis is still not feasible. In our second step, we initially attempt to deploy and run off-the-shelf mobile anti-virus software [67]. However, the results are not satisfactory. In fact, an example run of a leading mobile anti-virus software missed about 23.52% of infected apps from our study (Section 3.3.1)3. As our solution, instead of taking the traditional approach of extracting content invariants as malware signatures, we choose to take a behavior-based approach. Specifically, we manually analyze and distill essential malware behaviors into their behavioral footprints. Note that because the first step has significantly reduced the number of apps for further processing, we can afford in the second step semantic-rich, but potentially time-consuming methods to express, summarize, and match malware behaviors. In particular, our behavioral footprinting scheme accommodates multiple dimensions to describe malware behaviors.

• First, the app-specific manifest file provides semantic-rich information about the app and the information is readily accessible for our purposes. For example, if an app needs to listen to system-wide broadcast messages, the broadcast receivers can be statically contained in the manifest file or dynamically registered in the code. We can then express the following rule to match any app that monitors incoming SMS messages: an app contains a receiver that listens to android.provider.Telephony.SMS RECEIVED.

• Second, the app bytecode contains a wealth of semantic information, which can also be used in our behavioral footprints. Specifically, in DroidRanger, we choose to focus on those APIs defined in the Android framework. Particularly, we can express what APIs are called, and their sequences in a single rule. Moreover, by leveraging the call graph, we can associate API calls to a specific component in the rule. As an example, by extending the previous rule with a call to the abortBroadcast function, we can obtain a rule to capture any app that monitors incoming SMS messages and may potentially intercept received SMS messages. Furthermore, we can also utilize a data flow analysis algorithm [38] to detect function parameters with static or fixed inputs. This rule can be used to express malware behavior such as sending SMS messages to premium numbers.

• Third, we can also express malware behaviors based on the structural layout of the app. As an Android app is essentially a compressed archive, we can decompress it to reveal its

3One possible reason is that the mobile anti-virus software uses content invariants as malware signatures, which could lead to a high false negative rate when code is changed or obfuscated.

18 internal tree structure and then correspondingly express rules such as what packages are used by the app, what kind of class hierarchies they have, and where a speciﬁc resource is located.

To illustrate, we again use the Zsone [102] example, an SMS Trojan that sends short messages to premium numbers and removes billing-related notification messages from respective service providers. We can accordingly generate the following behavioral footprints to describe Zsone: (1) An app contains a receiver that listens to android.provider.Telephony.SMS RECEIVED and calls abortBroadcast; (2) An app sends SMS messages to certain specific premium numbers, including “10621900”, “106691819”, “10665123085”, “1066185829” and etc.; (3) An app intercepts SMS messages from certain numbers, including “10086”, “10000”, “10010”, and “1066134.” This behavioral footprint can then be efficiently applied to detect Zsone-infected apps in our collection. In practice, we found this scheme is rather effective and efficient, which leads to the discovery of 9 instances of Zsone-infected apps from the Google Play in our collection (Section 3.3.1).

3.2.2 Detecting Unknown Android Malware

Our first detection engine is designed to capture known malware. Next, we present the second detection engine to uncover unknown malware. Similar to the first one, our second detection engine also works in two steps: heuristics-based filtering and dynamic execution monitoring. The first step applies certain heuristics to identify potentially suspicious apps, which will then be confirmed in the second step. Heuristics-based filtering Unlike the first detection engine that can have known malware samples as templates for detection, our second step has to rely on certain heuristics to uncover zero-day malware. Although we can potentially employ different types of heuristics, we in this work focus on certain Android features that may be misused to load new code, either Java binary code or native machine code. The reasoning is straightforward: dynamic loading of new (untrusted) code can always open the doors for misuse and it becomes hard to predict what kind of code will be executed next. Accordingly, the first heuristic is related to the dynamic loading of Java binary code from a remote untrusted website. Typically, an Android app is self-contained in that its classes.dex file contains all the Dalvik bytecode for execution. However, the Dalvik VM provides the DexClassLoader class that can be used by an app to load classes from external files such as .apk or .jar (the standard archive of Java applications). If the dynamically-loaded code is fetched from a remote server, it becomes extremely hard to predict the app’s behavior and thus

19 Table 3.2 The number (and percentage of) apps with native code not in the default location

Apps with Native Code in Native Code in Native Code Assets Directory Res Directory 8272 (4.52%) 313 (0.17%) 195 (0.11%) indicates a potential threat to user privacy and security. Our measurement on the collected apps shows that DexClassLoader is used by 1055 apps (about 0.58%), and the vast majority of them are related to advertisement libraries, instead of the app itself. For example, one particular advertisement library, i.e., AdTOUCH [5], accounts for 40% of the uses of DexClassLoader. By considering the use of this feature by the app itself as suspicious, we further put the related apps under scrutiny, which essentially leads to the discovery of the zero-day Plankton spyware (Section 3.3.2). Our second heuristic is about the dynamic loading of native code locally. Most of the Android apps are programmed in Java. However, for performance or compatibility reasons, about 4.52% Android apps we studied still use native code. Note that though each app may run with a separate UID, the OS (Linux) kernel’s system call interface is directly exposed to the native code, making it possible for malicious apps to exploit vulnerabilities in OS kernel and privileged daemons to “root” the system. In Android, the default directory to store the native code is in the app-speciﬁc lib/armeabi subdirectory. As such, we consider it unusual if an app attempts to keep (or rather hide) native code in a directory other than the default one. Table 3.2 shows that about 4.52% of the total apps contain native code. In addition, 0.17% save native code in the assets directory and 0.11% put native code in the res/raw directory. This heuristic leads to the discovery of the zero-day DroidKungFu malware (Section 3.3.2). Dynamic execution monitoring Our heuristics eﬀectively identify new untrusted code running in the app. Our next step deploys a dynamic execution monitor to inspect its runtime behaviors, particularly those triggered by the new code. In particular, for the dynamically loaded Java code, our dynamic monitor records any calls to the Android framework APIs (particularly these related to Android permissions) and their arguments. The arguments can provide rich semantic information about an app’s behavior. For example, a call to the SmsManger.sendTextMessage function reveals both the destination number (is it a premium number?) and the content of the SMS message body (is it a message to subscribe a service that will cost money?). For the dynamically-loaded native code, our dynamic monitor collects system calls made by the native code. The collection is possible with a kernel module that hooks the system call table in the (Linux) kernel. In our prototype, we do not log all the system calls

20 Table 3.3 Statistics of collected apps from existing app marketplaces

the Google Alternative App Marketplaces Play Store M1 M2 M3 M4 153,002 17,229 14,943 10,385 8,481 Number of Apps (74.98%) (8.44%) (7.33%) (5.09%) (4.16%) 153,002 (74.98%) 51,038 (25.02%) Total Apps 204,040 but instead focus on those used by existing Android root exploits and/or made with the root privilege (with the assumption that malware will use them to subvert the system integrity after gaining the root privilege). For instance, we are interested in the sys mount system call because it can be used to remount the (normally read-only) Android system partition for modiﬁcation. After collecting the logs, we then analyze them to look for signs of suspicious runtime behaviors (e.g., sending SMS messages to premium numbers, executing certain system calls with root privilege and etc.). If so, we will further manually validate whether the app is indeed a zero-day malware. If yes, we will then extract the corresponding behavioral footprint and include it in the ﬁrst detection engine to detect other samples infected by this malware.

3.3 Evaluation

In this section, we present our evaluation results by applying our system to the collected apps from existing app marketplaces. Speciﬁcally, we crawled ﬁve representative marketplaces, including the Google Play (maintained by Google), eoeMarket [39] , alcatelclub [6], gfan [48], and mmoovv [72] 4. The collection was made in a two-month period during May and June 2011 and the number of apps from each marketplace is shown in Table 3.3. In total, we collected 204, 040 free apps. Among them, ∼ 75% of apps (153, 002) are collected from the Google Play and the rest 25% (51, 038) come from the four alternative markets (with each having about tens of thousands of apps). Due to the fact that an app may be included in multiple markets, there are total 182, 823 distinct apps5.

4For simplicity, we use M1, M2, M3, and M4 to denote these four alternative marketplaces in the rest of this chapter. 5In this study, we consider apps with diﬀerent SHA1 values are distinct.

21 Table 3.4 Ten known malware families used in this study

†: ﬁrst reported in the Google Play Reported Malware MD5 Comments Time fa6e905d4be3b09541106e1cb4052943 Geinimi [95] 12/2010 Trojan with bot-like capabilities b391d30ec53a08c20552203f58ca712c b3b38812cc01aa24df68bac4de517e23 ADRD [96] 02/2011 Trojan with bot-like capabilities a3fec4efca307adab4888d20d786a2a4 cec4c470a6dbac597064c6f566101028 Pjapps [15] 02/2011 Trojan with bot-like capabilities c05d4ff1a80f18ba9d8a86afd88bc05d ea97576befac2b142144ce30c2326ed6 Bgserv [14] 03/2011 Trojan with bot-like capabilities 1d696b87e665498b878bf92ce25440db 63f26345ba76ef5e033ef6e5ccecd30d Root exploits with Exploid, DroidDream† [94] 03/2011 763a1ab4e4a21373a24a921227a6f7a4 Rageagainstthecage f3b6eb64adef922096ff8b8618f3c1a9 zHash† [101] 03/2011 Root exploit with Exploid 5beae5543a3f085080c26de48a811da6 b2d359952bce1823d29e182dacac159c Root exploit with BaseBridge [13] 05/2011 d9814e6ec16be5b6174b518c186647b5 Rageagainstthecage DroidDream 3ae28cbf5a92e8e7a06db4b9ab0a55ab Trojan with information [113] 05/2011 Light† 5e4fd0a680ffc8d84d16b8c0e5404140 stealing capabilities d204007a13994cb1ad68d8d2b89cc9a8 Trojan that sends Zsone† [102] 05/2011 a673481ff15028e05f6fe778a773e0f9 premium-rate SMS messages a3c0aacb35c86b4468e85bfb9e226955 Trojan that targets jSMSHider [97] 06/2011 389b416fb0f505d661716b8da02f92a2 custom ﬁrmware devices

3.3.1 Detecting New Samples of Known Malware

To evaluate the effectiveness of our first detection engine, we obtained and analyzed known Android malware samples from 10 different families. Table 3.4 lists these ten malware families, which represent most Android malware reported in the first half of year 2011. For each family, we then extract the corresponding behavioral footprints from two samples (their MD5 values are also included in the table). Among these malware, three of them embed at least one of the following root exploits, i.e., Rageagainstthecage [86], Zimperlich [143], or Exploid [40]. Specifically, Rageagainstthecage takes advantage of a vulnerability in adbd, a privileged daemon running as root; Zimperlich exploits a similar bug but in the privileged zygote daemon; while Exploid makes use of the vulnerable udev (init) daemon (CVE-2009-1185) in Android. Among these exploits, Exploid needs the triggering of certain udev events such as turning on or off the WIFI interface, which requires the CHANGE WIFI STATE permission. Accordingly, our detection engine recognizes such need and uses it to prune the collected apps for Exploid-specific root exploits.

22 Table 3.5 Essential permissions of 10 known malware families

Malware Essential Permissions Apps INTERNET, ACCESS NETWORK STATE ADRD 10, 379 (5.68%) RECEIVE BOOT COMPLETED Bgserv INTERNET, RECEIVE SMS, SEND SMS 2, 880 (1.58%) DroidDream CHANGE WIFI STATE 4, 096 (2.24%) DroidDreamLight INTERNET, READ PHONE STATE 71, 095 (38.89%) Geinimi INTERNET, SEND SMS 7, 620 (4.17%) jSMSHider INSTALL PACKAGES 1, 210 (0.66%) BaseBridge NATIVE CODE 8, 272 (4.52%) Pjapps INTERNET, RECEIVE SMS 4, 637 (2.54%) Zsone RECEIVE SMS, SEND SMS 3, 204 (1.75%) zHash CHANGE WIFI STATE 4, 096 (2.24%)

Effectiveness of permission-based filtering Based on the known Android malware samples, our first step is to extract the essential permissions required by the malware to perform its functionalities. In Table 3.5, we list the essential permissions for each malware family and also report the number of apps that survived the permission-based filter. From the table, the proposed permission-based filtering is rather effective for most of these malware families. Specif- ically, eight of them have less than 6% apps left after applying the essential permissions. Among the two exceptions, DroidDreamLight requires INTERNET and READ PHONE STATE permissions which are common in existing apps. In this particular case, we also observe it needs to register for a broadcast receiver for android.intent.action.PHONE STATE. Therefore, we also leverage it as a pre-condition for our behavioral footprint matching, which significantly reduces to 0.64% of apps (or 1175) for the second step. The another exception, i.e., BaseBridge, does not require any permission, but the fact that contains the native code to launch the Rageagainstthecage immediately reduces to the 4.52% of apps (with native code) in our collection. It is worth mentioning the essential permission of a particular malware, i.e., jSMSHider. It is special in that it requires INSTALL PACKAGES, a signatureOrSystem permission. This type of permission by definition can only be granted to an app either signed by the same signing key as the system firmware or installed in the privileged /system/app directory. In other words, it will never be granted to third-party apps. jSMSHider is unique by targeting the popular third-party custom firmware whose signing key is (inappropriately) publicly accessible. In other words, by signing the infected app with it, jSMSHider is able to gain this signatureOrSystem permission to install a package. As a result, we selected INSTALL PACKAGES as the essential permission for the jSMSHider malware.

23 Table 3.6 The number of infected apps by 10 known malware families on 5 studied marketplaces

the Google Alternative Marketplaces Malware Total Distinct Play Store M1 M2 M3 M4 ADRD 0 1 1 4 3 9 8 BaseBridge 0 2 2 0 2 6 4 Bgserv 0 0 0 0 1 1 1 DroidDream 0 6 6 0 0 12 6 DroidDreamLight 12 0 0 0 0 12 12 Geinimi 0 26 26 2 10 64 37 jSMSHider 0 3 3 0 6 12 9 Pjapps 0 12 9 14 8 43 31 zHash 0 1 1 0 1 3 2 Zsone 9 0 0 0 0 9 9 Total 21 51 48 20 31 171 119

Effectiveness of behavioral footprint matching After pruning the apps with essential permissions, our second step examines the resulting apps for ones that match known malware behaviors. Our experiments show that the detection of known malware (of 10 families) among these 204, 040 apps only took about four and a half hours to complete. Our scanning results are shown in Table 3.6. In particular, we detected 171 malicious apps in our collection with 21 of them from the Google Play and 150 from the other four alternative marketplaces. Similarly, due to the fact that one sample may be submitted to multiple marketplaces, 119 of these 171 infected apps are unique. Based on the detection results in Table 3.6, it is evident that the malware infection in alternative marketplaces is more serious than the infection in the Google Play. Specifically, the number (150) of infected apps in these four alternative marketplaces is more than 7 times of that in the Google Play (21) even though the total number of apps we collected from the former is only one third of the latter. Moreover, we also found that the Geinimi malware, which was publicly reported in November, 2010, is still spreading in alternative marketplaces. This is in sharp contrast to the timely removal of malware from the Google Play. In this study, we also attempted to measure the effectiveness of existing mobile anti-virus software. Especially, we downloaded and installed the free version of Lookout Security & An- tivirus, one of the leading mobile security software from the Google Play. We first tested it in the first week of August 2011 and then tested it again in the first week of November6 to scan the samples reported by our system. In our experiments, we installed those malware samples

6The version numbers are version 6.3 (release 8472) and version 6.11 (26cf47e) respectively.

24 Table 3.7 The missed known malware families by Lookout Security & Antivirus software

T, D, and M represent the total, detected, and missed number of samples, respectively. ADRD Bgserv jSMSHider BaseBridge Pjapps T D M T D M T D M T D M T D M version 6.3 (r8472) 8 3 5 1 0 1 9 6 3 4 1 3 31 15 16 version 6.11 (26cf47e) 8 3 5 1 0 1 9 9 0 4 4 0 31 31 0 one by one on a Nexus One phone (running Android version 2.3.3) with the Lookout Security & Antivirus software. The scanning results are shown in Table 3.7. From the table, none of these two versions can detect all the samples. In particular, among these 119 distinct malware samples, the earlier version (6.3) reports 91 as malware and 28 sample as safe, leading to a high false negative rate 23.52%. To verify that these 28 samples are indeed malicious, we have manually examined these samples and confirmed each single of them. The recent version (6.11) performs better by reporting 113 as malware and 6 samples as safe with a reduced false negative rate 5.04%. We believe the improvement of scanning results is due to the active update of malware signatures. False negative measurement Our previous experiments demonstrate the effectiveness of our scheme (especially in terms of false positives) for known malware detection. Next, we aim to measure the false negatives of our system. To do that, we first download (in the first week of August, 2011) the malware samples from the contagio dump [28], which seems to be the only publicly available repository of mobile malware samples. Within the downloaded data set, there are 27 samples falling in the 10 known families which we have the related behavioral footprints. Because our scheme requires known malware samples for behavioral footprint extraction, we take cautions in eliminating those duplicate samples in the contagio dump with the same SHA1 values used in footprint extraction. As a result, there are 24 distinct samples in total for our measurement. Though the data set is not sufficient large, this seems to be the only available source for our study. Based on these 24 samples, our system detected 23 of them, implying a false negative rate of 4.2%. A detailed analysis of the missing sample shows that it is the payload (com.android.providers .downloadsmanager) of the DroidDream malware, not the malware itself. This payload is also a standalone app and we do not have the corresponding behavioral footprint, which explains why our system missed it. Meanwhile, we also find that the malware repository has mis-categorized one particular sample PMSW V1.8 .apk (md5: 5895bcd066abf6100a37a25c0c1290a5). The sample, considered to be a DroidDream malware, is actually an ADRD malware.

25 Table 3.8 Two zero-day malware families detected by DroidRanger

the Google Alternative Markets Malware Total Distinct Play Store M1 M2 M3 M4 Plankton 11 0 0 0 0 11 11 DroidKungFu 0 9 10 1 9 29 18 Total 11 9 10 1 9 40 29

3.3.2 Detecting Zero-day Malware

Next, we present the evaluation results for zero-day malware detection. As mentioned earlier, we have developed heuristics to identify suspicious apps that dynamically load untrusted code for execution. These heuristics effectively lead to the discovery of two zero-day malware: Plankton and DroidKungFu. Table 3.8 shows the number of detected zero-day malware samples from each marketplace. In this section, we present in more detail on how we discovered these two malware and what are their malicious behaviors. Plankton In the second detection engine, our first heuristic is to capture dynamic loading of untrusted code from remote websites. With that, we perform a query on the collected apps and found 1, 055 apps that invoked the DexClassLoader support for Java class loading. A further inspection shows that most of such uses are actually by advertisement libraries. After a simple white-listing of advertisement libraries, we run the remaining 240 apps with a dynamic execution monitor (Section 3.2.2). With a dynamic monitor, we can not only intercept the code-loading behavior, but also obtain the jar/apk files that are being actually loaded. In this particular case, when running a suspect app named Angry Birds Cheater (com.crazyapps.angry.birds.cheater.trainer.helper) in our dynamic monitor, our logs show the attempt to load one jar file named “plankton - v0.0.4.jar,” which is downloaded from a remote website. A more in-depth analysis shows that before downloading this jar file, the app transports the list of permissions granted to the app over to a remote server. This would presumably allow the remote server to customize the dynamically loaded binary based on the granted app’s permissions. For the downloaded plankton v0.0.4.jar file, it turns out that it contains a number of bot-related functionalities or commands that can be remotely invoked. In Figure 3.2, we show the list of commands supported by this spyware. Specifically, the /bookmarks command manipulates the browser bookmarks, and the /history command leaks the user browsing history. It also has a /dumplog command that can dump the runtime logs from logcat. Earlier reports [60] show that highly sensitive private information may exist as plain text in the runtime log.

26 public enum Commands { ... static { ACTIVATION = new Commands("ACTIVATION", 1, "Activation", "/activate"); HOMEPAGE = new Commands("HOMEPAGE", 2, "Homepage", "/homepage"); COMMANDS_STATUS = new Commands("COMMANDS_STATUS", 3, "CommandsStatus", "/commandstatus"); BOOKMARKS = new Commands("BOOKMARKS", 4, "Bookmarks", "/bookmarks"); SHORTCUTS = new Commands("SHORTCUTS", 5, "Shortcuts", "/shortcuts"); HISTORY = new Commands("HISTORY", 6, "History", "/history"); TERMINATE = new Commands("TERMINATE", 7, "Terminate", "/terminate"); STATUS = new Commands("STATUS", 8, "Status", "/status"); DUMP_LOG = new Commands("DUMP_LOG", 9, "DumpLog", "/dumplog"); UNEXP_EXCEPTION = new Commands("UNEXP_EXCEPTION", 10, "UnexpectedException", "/unexpectedexception"); UPGRADE = new Commands("UPGRADE", 11, "Upgrade", "/installation"); INSTALLATION = new Commands("INSTALLATION", 12, "Installation", "/installation");

arrayOfCommands[0] = COMMANDS; arrayOfCommands[1] = ACTIVATION; arrayOfCommands[2] = HOMEPAGE; arrayOfCommands[3] = COMMANDS_STATUS; arrayOfCommands[4] = BOOKMARKS; arrayOfCommands[5] = SHORTCUTS; arrayOfCommands[6] = HISTORY; arrayOfCommands[7] = TERMINATE; arrayOfCommands[8] = STATUS; arrayOfCommands[9] = DUMP_LOG; arrayOfCommands[10] = UNEXPECTED_EXCEPTION; arrayOfCommands[11] = UPGRADE; arrayOfCommands[12] = INSTALLATION; } }

Figure 3.2 The list of commands supported in Plankton

After we identified the Plankton malware, we generated its behavioral footprint and applied it to detect other incidents in our collection. As a result, we detect 10 more Plankton samples; all of them could be downloaded at that time from the Google Play. We then reported these 11 apps to Google, which promptly removed them from the Google Play on the same day. DroidKungFu Our second heuristic aims to detect suspicious apps that load native code in an unusual way (e.g., from non-standard directories). In fact, among 8, 272 apps that contain native code, 508 of them keep native code in non-standard directories. As such, we monitored the runtime behaviors of these apps with our dynamic monitor. When analyzing the log, we find some particular apps that attempted to remount the system partition (with the sys mount syscall) to make it writable. This is highly suspicious because remounting system partition can only be executed by users with the root privilege. For third-party apps, this almost certainly means that the app has successfully launched a root exploit. Therefore, we further analyze these apps, which lead to the discovery of DroidKungFu malware. The malware contains both Rageagainstthecage and Exploid root exploits in an encrypted form. When DroidKungFu runs, it will first decrypt and launch the root exploits. If successful, the malware will essentially elevate its privilege to root so that it can arbitrarily access and

27 Table 3.9 The total number of malware samples detected by DroidRanger

the Google Alternative Markets Malware Total Distinct Play Store M1 M2 M3 M4 Total (Known) 21 51 48 20 31 171 119 Total (Zero-day) 11 9 10 1 9 40 29 32 60 58 21 40 Total 211 148 (0.02%) (0.35%) (0.39%) (0.20%) (0.47%) modify any resources on the phone, including the installation and removal of another app. Our study shows that one particular app installed by DroidKungFu pretends to be the legitimate Google Search app by showing an identical icon. This app actually acts as a bot client that will connect to a remote server to retrieve and execute commands.

3.3.3 Summary of Detected Malware

Overall, our system detected 211 malicious or infected apps among the collected 204, 040 apps from ﬁve studied marketplaces. The detailed breakdown is shown in Table 3.9: among these 211 apps, 32 of them are from the Google Play (∼ 0.02% infection rate) and 179 come from the other four alternative marketplaces (0.20%-0.47% infection rates). Due to the relative lack of regulation in alternative marketplaces, their infection rate is more than an order of magnitude higher than the Google Play. Considering the recent trend in observing an unprecedented growth of mobile malware, we believe a rigorous vetting process needs to be in place for both oﬃcial and alternative marketplaces.

3.4 Discussion

Our scanning results show a relatively low malware infection rate on studied app marketplaces (0.02% on the Google Play and 0.20% to 0.47% on other alternative marketplaces). Such infection rate is certainly less than that of malicious web contents reported earlier in [74]. However, due to the centralized role they played in the smartphone app ecosystem, such infection rate, though low, can still compromise a tremendous number of smartphones and cause lots of dam- ages. Using the DroidDream malware as the example, it is reported that this particular malware infected more than 260, 000 users within 48 hours before Google removed them from the app marketplace [3]. Also, due to the relative lack of regulation in alternative marketplaces, even though a malware may be removed from the Google Play, it can continue to exist in alternative marketplaces. With the same DroidDream example, we found its presence in alternative

28 marketplaces three months later after they were removed from the Google Play. Moreover, we notice that some malware have embedded the root exploits which allow them to obtain full access on compromised devices. In fact, among the 10 known malware families, four of them, i.e., BaseBridge, DroidDream, DroidKungFu, and zHash, have at least one root exploit. Last but not least, zero-day malware exist in both official and alternative marketplaces and they may be able to bypass most existing, if not all, up-to-date mobile anti-virus software. With that, there is a clear need to instantiate a rigorous vetting or policing process in both official and alternative app marketplaces, which is currently lacking. In the same spirit, we argue the current model of passively waiting for the feedback or ratings from users and the community may not work as smoothly as we expect. In fact, to foster a hygienic mobile app ecosystem, there is a need for a vetting process that includes DroidRanger-like systems to examine uploaded apps and better protect mobile users. From another perspective, our current prototype is still limited in the coverage of apps and marketplaces. For example, though the collected pool of apps may be useful to demonstrate the effectiveness of our current prototype, they are all free apps. A recent report from Androlib [33] shows that 36.2% of existing apps are paid ones. We have the reason to believe that paid apps could provide unique differences that may warrant necessary re-design or adaption of our system. Also, our current study only focuses on five different app marketplaces. Though our findings may not be directly applicable to other marketplaces including iOS-related app stores, the principles or key methodologies used in this study can still be applied. Finally, we point out that our current study only explored two basic heuristics to uncover zero-day malware. There exist many other heuristics that could be equally effective. For example, a heuristic can be developed to capture apps that involve background sending of unauthorized SMS messages to certain premium-rated numbers. Another heuristic can also be designed to detect bot-like behavior that is remotely controlled by SMS messages. The exploration of these heuristics to capture additional zero-day malware remains an interesting future work.

3.5 Summary

In the chapter, we have presented a systematic study to detect malicious apps on both official and alternative app marketplaces. Our study involves a comprehensive crawling of five representative app marketplaces in May and June 2011, which results in a collection of 204, 040 Android apps. To scalably and efficiently detect potential infection from both known and unknown malware, we have accordingly proposed two different schemes, i.e., permission-based behavioral footprinting and heuristics-based filtering. We have implemented both schemes in

29 DroidRanger and the evaluation results of successfully detecting 211 malicious apps and un- covering two zero-day malware in both official and alternative marketplaces demonstrate the feasibility and effectiveness of our approach. From another perspective, our results also call for the need of a rigorous vetting process to better police both official and alternative marketplaces.

30 Chapter 4

Dissecting Android Malware: Characterization and Evolution

4.1 Introduction

In previous chapter, we introduced a system called DroidRanger that detected the malicious Android apps in official and alternative app marketplaces. Our system successfully detected 211 malicious apps and uncovered two zero-day malware families in both official and alternative marketplaces. From another perspective, it has been highlighted [77] that “among all mobile malware, the share of Android-based malware is higher than 46% and still growing rapidly.” According to the latest report from Lookout, in year 2014 there was an astounding 75% increase in Android mobile malware encounter rates in the United States compared to year 2013 [2]. Given the rapid growth of Android malware, there is a pressing need to effectively mitigate or defend against them. However, without an insightful understanding of them, it is hard to imagine that an effective mitigation solution can be practically developed. To make matters worse, the research community at large is still constrained by the lack of a comprehensive mobile malware dataset to start with. The goals and contributions of this work are three-fold. First, we fulfil the need by pre- senting the first large collection of 1260 Android malware samples1 in 49 different malware families, which covers the majority of existing Android malware at that time. The dataset is accumulated from more than one year effort in collecting related malware samples, including manual or automated crawling from a variety of Android Markets. To better mitigate mobile malware threats, we have released the entire dataset to the research community at

1In this study, we consider the samples with diﬀerent SHA1 values are distinct.

31 http://malgenomeproject.org/.2 Until now, we have shared the dataset with more than 450 universities, research labs and companies all over the world. Second, based on the collected malware samples, we perform a timeline analysis of their discovery and thoroughly characterize them based on their detailed behavior break-down, including the installation, activation, and payloads. The timeline analysis is instrumental to revealing major outbreaks of certain Android malware in the wild while the detailed breakdown and characterization of existing Android malware is helpful to better understand them and shed light on possible defenses. Specifically, in our 1260 malware samples, we find that 1083 of them (or 86.0%) are repackaged versions of legitimate applications with malicious payloads, which indicates the policing need of detecting repackaged applications in the current Android Markets. Also, we observe that more recent Android malware families are adopting update attacks and drive-by downloads to infect users, which are more stealthy and difficult to detect. Further, when analyzing the carried payloads, we notice a number of alarming statistics: (1) Around one third (36.7%) of the collected malware samples leverage root-level exploits to fully compromise the Android security, posing the highest level of threats to users’ security and privacy; (2) More than 90% turn the compromised phones into a botnet controlled through network or short messages. (3) Among the 49 malware families, 28 of them (with 571 or 45.3% samples) have the built-in support of sending out background short messages (to premium-rate numbers) or making phone calls without user awareness. (4) Last but not least, 27 malware families (with 644 or 51.1% samples) are harvesting user’s information, including user accounts and short messages stored on the phones. Third, we perform an evolution-based study of representative Android malware, which shows that they are rapidly evolving and existing anti-malware solutions are seriously lagging behind. For example, it is not uncommon for Android malware to have encrypted root exploits or obfuscated command and control (C&C) servers. The adoption of various sophisticated techniques greatly raises the bar for their detection. In fact, to evaluate the effectiveness of existing mobile anti-virus software, we tested our dataset with four representative ones, i.e., AVG Antivirus Free, Lookout Security & Antivirus, Norton Mobile Security Lite, and Trend Micro Mobile Security Personal Edition, all downloaded from the official Android Market (in the first week of November, 2011). Sadly, wile the best case was able to detect 1, 003 (or 79.6%) samples in our dataset, the worst case can only detect 254 (20.2%) samples. Furthermore, our analysis shows that malware authors are quickly learning from each other to create hybrid threats. For

2To prevent our dataset from being misused, we may require verifying user identity or request necessary justiﬁcation before the dataset can be downloaded. Please visit the project website for detailed information.

32 10 1400 1260 In Android Market In Both Markets 1200 AnserverBot 8 In Alternative Market 2010 2011 2010 2011 1000

6 800 678 600 DroidKungFu 4 527 (including its variants) 400 403 2 200 209 115 66 66 18 23 33 0 0 13 13 13 14 The Cumulative Number of New Malware Samples The Number of New Android Malware Families 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 (a) The Monthly Breakdown of New Android (b) The Cumulative Growth of New Malware Malware Families Samples in Our Collection

Figure 4.1 The Android malware growth in 2010-2011

example, one recent Android malware, i.e., AnserverBot [16] (reported in September 2011), is clearly inspired from Plankton [100] (reported in June 2011) to have the dynamic capability of fetching and executing payload at runtime, posing signiﬁcant challenges for the development of next-generation anti-mobile-malware solutions. The rest of this chapter is organized as follows: Section 4.2 presents a timeline analysis of existing Android malware. Section 4.3 characterizes our samples and shows a detailed breakdown of their infection behavior. After that, Section 4.4 presents an evolution study of representative Android malware and Section 4.5 shows the detection results with four representative mobile anti-virus software. Section 4.6 discusses possible ways for future improvement. Lastly, we summarize this chapter in Section 4.7.

4.2 Malware Timeline

In Table 4.1, we show the list of 49 Android malware families in our dataset along with the time when each particular malware family is discovered. We obtain the list by carefully examining the related security announcements, threat reports, and blog contents from existing mobile anti-virus companies and active researchers [19, 46, 67, 76, 103, 110, 112] as exhaustively as possible and diligently requesting malware samples from them or actively crawling from existing official and alternative Android Markets. As of this writing, our collection is believed to reflect the state of the art of Android malware. Specifically, if we take a look at the Android malware history [79] from the very first Android malware FakePlayer in August 2010 to recent ones in the end of October 2011, it spans slightly more than one year with around 52 Android malware families reported. Our dataset has 1260 samples in 49 different malware families, indicating a very decent coverage of existing Android malware.

33 Table 4.1 The timeline of 49 Android malware in our collection O†: oﬃcial Android Market; A‡: Alternative Android Markets Markets Discovered Malware Samples O† A‡ Month √ FakePlayer 6 2010-08 √ GPSSMSSpy 6 2010-08 √ TapSnake 2 2010-08 √ SMSReplicator 1 2010-11 √ Geinimi 69 2010-12 √ ADRD 22 2011-02 √ Pjapps 58 2011-02 √ BgServ 9 2011-03 √ √ DroidDream 16 2011-03 √ Walkinwat 1 2011-03 √ √ zHash 11 2011-03 √ √ DroidDreamLight 46 2011-05 √ Endofday 1 2011-05 √ √ Zsone 12 2011-05 √ BaseBridge 122 2011-06 √ DroidKungFu1 34 2011-06 √ GGTracker 1 2011-06 √ jSMSHider 16 2011-06 √ Plankton 11 2011-06 √ √ YZHC 22 2011-06 √ Crusewin 2 2011-07 √ DroidKungFu2 30 2011-07 √ GamblerSMS 1 2011-07 √ GoldDream 47 2011-07 √ HippoSMS 4 2011-07 √ Lovetrap 1 2011-07 √ Nickyspy 2 2011-07 √ SndApps 10 2011-07 √ √ Zitmo 1 2011-07 √ CoinPirate 1 2011-08 √ DogWars 1 2011-08 √ DroidKungFu3 309 2011-08 √ GingerMaster 4 2011-08 √ NickyBot 1 2011-08 √ RogueSPPush 9 2011-08 √ AnserverBot 187 2011-09 √ √ Asroot 8 2011-09 √ DroidCoupon 1 2011-09 √ DroidDeluxe 1 2011-09 √ Gone60 9 2011-09 √ Spitmo 1 2011-09 √ BeanBot 8 2011-10 √ √ DroidKungFu4 96 2011-10 √ DroidKungFuSapp 3 2011-10 √ √ DroidKungFuUpdate 1 2011-10 √ FakeNetﬂix 1 2011-10 √ Jifake 1 2011-10 √ KMin 52 2011-10 √ RogueLemon 2 2011-10 Total 1260 14 44

34 For each malware family, we also report in the table the number of samples in our collection and differentiate the sources where the malware was discovered, i.e., from either the official or alternative Android Markets. To eliminate possible false positive in our dataset, we run our collection through existing mobile anti-virus software for confirmation (Section 4.5). If there is any miss from existing mobile anti-virus security software, we will manually verify the sample and confirm it is indeed a malware. To better illustrate the malware growth, we show in Figures 4.1a and 4.1b the monthly breakdown of new Android malware families and the cumulative monthly growth of malware samples in our dataset. Consistent with others [77] [69], starting summer 2011, the Android malware has indeed increased dramatically, reflected in the rapid emergence of new malware families as well as different variants of the same type. In fact, the number of new Android malware in July 2011 alone already exceeds the total number in the whole year of 2010. Figure 4.1b further reveals two major Android malware outbreaks, including DroidKungFu (starting June, 2011) and AnserverBot (starting September, 2011). Among these 1260 samples in our collection, 37.5% of them are related to DroidKungFu [98] and its variants; 14.8% are AnserverBot [16]. Both of them are still actively evolving to evade the detection from existing anti-virus software – a subject we will dive into in Section 4.4.

4.3 Malware Characterization

In this section, we present a systematic characterization of existing Android malware, ranging from their installation, activation, to the carried malicious payloads.

4.3.1 Malware Installation

By manually analyzing malware samples in our collection, we categorize existing ways Android malware use to install onto user phones and generalize them into three main social engineering- based techniques, i.e., repackaging, update attack, and drive-by download. These techniques are not mutually exclusive as different variants of the same type may use different techniques to entice users for downloading. 1) Repackaging Repackaging is one of the most common techniques malware authors use to piggyback malicious payloads into popular applications (or simply apps). In essence, malware authors may locate and download popular apps, disassemble them, enclose malicious payloads, and then re-assemble and submit the new apps to official and/or alternative Android Markets. Users could be vulnerable by being enticed to download and install these infected apps.

35 Table 4.2 An overview of existing Android malware - Part I: installation and activation Installation Activation Drive-by Repackaging Update Standalone BOOT SMS NET CALL USB PKG BATT SYS MAIN Download √ √ √ √ ADRD √ √ √ √ √ √ √ √ AnserverBot √ Asroot √ √ √ √ √ √ √ BaseBridge √ √ √ BeanBot √ √ √ √ BgServ √ √ √ CoinPirate √ √ √ Crusewin √ DogWars √ √ √ √ √ DroidCoupon √ DroidDeluxe √ √ DroidDream √ √ √ DroidDreamLight √ √ √ √ DroidKungFu1 √ √ √ √ DroidKungFu2 √ √ √ √ DroidKungFu3 √ √ √ √ DroidKungFu4 √ √ √ √ DroidKungFuSapp √ √ DroidKungFuUpdate √ √ √ Endofday √ FakeNetﬂix √ FakePlayer √ √ GamblerSMS √ √ √ Geinimi √ √ √ √ √ GGTracker √ √ GingerMaster √ √ √ √ √ GoldDream √ Gone60 √ √ GPSSMSSpy √ √ √ √ HippoSMS √ √ Jifake √ √ √ jSMSHider √ √ KMin √ √ √ Lovetrap √ √ √ NickyBot √ √ Nickyspy √ √ √ √ Pjapps √ √ Plankton √ √ RogueLemon √ √ RogueSPPush √ √ SMSReplicator √ √ SndApps √ √ √ √ Spitmo √ √ TapSnake √ Walkinwat √ √ YZHC √ √ zHash √ √ √ Zitmo √ √ √ Zsone number of families 25 4 4 25 29 21 4 6 1 2 8 8 5 number of samples 1083 85 4 177 1050 398 288 112 187 17 725 782 56

To quantify the use of repackaging technique among our collection, we take the following approach: if a sample shares the same package name with an app in the official Android Market, we then download the official app (if free) and manually compare the difference, which typically

36 contains the malicious payload added by malware authors. If the original app is not available, we choose to disassemble the malware sample and manually determine whether the malicious payload is a natural part of the main functionality of the host app. If not, it is considered as repackaged app. In total, among the 1260 malware samples, 1083 of them (or 86.0%) are repackaged. By further classifying them based on each individual family (Table 4.2), we find that within the total 49 families in our collection, 25 of them infect users by these repackaged apps while 25 of them are standalone apps where most of them are designed to be spyware in the first place. One malware family, i.e., GoldDream, utilizes both for its infection. Among the 1083 repackaged apps, we find that malware authors have chosen a variety of apps for repackaging, including paid apps, popular game apps, powerful utility apps (including security updates), as well as porn-related apps. For instance, one AnserverBot malware sample (SHA1: ef140ab1ad04bd9e52c8c5f2fb6440f3a9ebe8ea) repackaged a paid app com.camelgames.mxmotor available on the official Android Market. Another BgServ [14] malware sample (SHA1:bc2dedad05 07a916604f86167a9fa306939e2080) repackaged the security tool released by Google to remove droiddream from infected phones. Also, possibly due to the attempt to hide piggybacked malicious payloads, malware authors tend to use the class-file names which look legitimate and benign. For example, AnserverBot malware uses a package name com.sec.android.provider.drm for its payload, which looks like a module that provides legitimate DRM functionality. The first version of DroidKungFu chooses to use com.google.ssearch to disguise as the Google search module and its follow-up versions use com.google.update to pretend to be an official Google update. It is interesting to note that one malware family – jsmshider – uses a publicly available private key (serial number: b3998086d056cffa) that is distributed in the Android Open Source Project (AOSP). The current Android security model allows the apps signed with the same platform key of the phone firmware to request the permissions which are otherwise not available to normal third-party apps. One such permission includes the installation of additional apps without user intervention. Unfortunately, a few (earlier) popular custom firmware images were signed by the default key distributed in AOSP. As a result, the jSMSHider-infected apps may obtain privileged permissions to perform dangerous operations without user’s awareness. 2) Update Attack The first technique typically piggybacks the entire malicious payloads into host apps, which could potentially expose their presence. The second technique makes it difficult for detection. Specifically, it may still repackage popular apps. But instead of enclosing the payload as a whole, it only includes an update component that will fetch or download

37 (a) The displayed update (b) Installation of a new dialogue version

Figure 4.2 An update attack from BaseBridge the malicious payloads at runtime. As a result, a static scanning of host apps may fail to capture the malicious payloads. In our dataset, there are four malware families, i.e., BaseBridge, DroidKungFuUpdate, AnserverBot, and Plankton, that adopt this attack (Table 4.2). The BaseBridge malware has a number of variants. While some embed root exploits that allow for silent installation of additional apps without user intervention, we here focus on other variants that use the update attacks without root exploits. Specifically, when a BaseBridge- infected app runs, it will check whether an update dialogue needs to be displayed. If yes, by essentially saying that a new version is available, the user will be offered to install the updated version (Figure 4.2a). (The new version is actually stored in the host app as a resource or asset file.) If the user accepts, an “updated” version with the malicious payload will then be installed (Figure 4.2b). Because the malicious payload is in the “updated” app, not the original app itself, it is more stealthy than the first technique that directly includes the entire malicious payload in the first place. The DroidKungFuUpdate malware is similar to BaseBridge. But instead of carrying or enclosing the “updated” version inside the original app, it chooses to remotely download a new version from network. Moreover, it takes a stealthy route by notifying the users through a third-party library [118] that provides the (legitimate) notification functionality. (Note the functionality is similar to the automatic notification from the Google’s Cloud to Device Messaging framework.) In Figure 4.3, we show the captured network traffic initiated from the original host app to up-

38 Table 4.3 The (abbreviated) Android events/actions Of interest to existing malware

Abbreviation Events Abbreviation Events BOOT SMS SMS RECEIVED BOOT COMPLETED (Boot Completed) (SMS/MMS) WAP PUSH RECEIVED CALL PHONE STATE USB UMS CONNECTED (Phone Events) NEW OUTGOING CALL (USB Storage) UMS DISCONNECTED PACKAGE ADDED ACTION POWER CONNECTED PACKAGE REMOVED ACTION POWER DISCONNECTED PKG PACKAGE CHANGED BATT BATTERY LOW (Package) PACKAGE REPLACED (Power/Battery) BATTERY OKAY PACKAGE RESTARTED BATTERY CHANGED ACTION PACKAGE INSTALL NET CONNECTIVITY CHANGE MAIN ACTION MAIN (Network) PICK WIFI WORK (Main Activity) USER PRESENT SYS INPUT METHOD CHANGED (System Events) SIG STR SIM FULL

date itself. Once downloaded, the “updated” version turns out to be the DroidKungFu3 malware. As pointed out in Table 4.1, the DroidKungFuUpdate malware was available on both official and alternative Android Markets. The previous two update attacks require user approval to download and install new versions. The next two malware, i.e., AnserverBot and Plankton, advance the update attack by stealthily upgrading certain components in the host apps not the entire app. As a result, it does not require user approval. In particular, Plankton directly fetches and runs a jar file maintained in a remote server while AnserverBot retrieves a public (encrypted) blog entry, which contains the actual payloads for update! In Figure 4.4, we show the actual network traffic to download AnserverBot payload from the remote command and control (C&C) server. Apparently, the stealthy nature of these update attacks poses significant challenges for their detection (Table 4.7 – Section 4.5). 3) Drive-by Download The third technique applies the traditional drive-by download attacks to mobile space. Though they are not directly exploiting mobile browser vulnerabilities, they are essentially enticing users to download “interesting” or “feature-rich” apps. In our collection, we have four such malware families, i.e., GGTracker [49], Jifake [70], Spitmo [43] and ZitMo [127]. The last two are designed to steal user’s sensitive banking information. The GGTracker malware starts from its in-app advertisements. In particular, when a user clicks a special advertisement link, it will redirect the user to a malicious website, which claims to be analyzing the battery usage of user’s phone and will redirect the user to one fake Android Market to download an app claimed to improve battery efficiency. Unfortunately, the downloaded app is not one that focuses on improving the efficiency of battery, but a malware that will subscribe to a premium-rate service without user’s knowledge.

39 GET /appfile/acc9772306c1a84abd02e9e7398a2cce/FinanceAccount.apk HTTP/1.1 Host: 219.234.85.214 Connection: Keep-Alive User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Accept-Ranges: bytes ETag: W/"377865-1315359197000" Last-Modified: Wed, 07 Sep 2011 01:33:17 GMT Content-Type: application/vnd.android.package-archive Content-Length: 377865 Date: Tue, 25 Oct 2011 02:07:45 GMT

PK...... \$?...... META-INF/MANIFEST.MF.Y[s...}..... [email protected].. r.%.U>...r...... N.O’UI.C...,....W...... w./ ...... /...K....OoP..#../...... ".-,..~.S..._.|...... o..1..k...... ]<.Y..,-...,l7zh...... %....g..7r...... ^.BA41.L......

Figure 4.3 An update attack from DroidKungFuUpdate

GET /s/blog_8440ab780100t0nf.html HTTP/1.1 User-Agent: Dalvik/1.2.0 (Linux; U; Android 2.2.1; generic Build/MASTER) Host: blog.sina.com.cn Connection: Keep-Alive

HTTP/1.1 200 OK Server: nginx/0.7.62 Date: Wed, 21 Sep 2011 01:44:16 GMT ... v_____:yjEJTTlSvSSVSGRp9NASSSSSSSSSSSSSSSSkSSSS7WB5 rthyOV3JeJ4q96sSrc5Os7g6Wsz8hJn99P6O6UaRgkSZsu ...

Figure 4.4 An update attack from AnserverBot

Similarly, the Jifake malware is downloaded when users are redirected to the malicious website. However, it is not using in-app advertisements to attract and redirect users. Instead, it uses a malicious QR code [85], which when scanned will redirect the user to another URL containing the Jifake malware. This malware itself is the repackaged mobile ICQ client, which sends several SMS messages to a premium-rate number. While QR code-based malware propa- gation has been warned earlier [114], this is the ﬁrst time that this attack actually occurred in the wild. The last two Spitmo and ZitMo are ported versions of nefarious PC malware, i.e., SpyEye and Zeus. They work in a similar manner: when a user is doing online banking with a comprised PC, the user will be redirected to download a particular smartphone app, which is claimed to better protect online banking activities. However, the downloaded app is actually a malware, which can collect and send mTANs or SMS messages to a remote server. These two malware families rely on the comprised desktop browsers to launch the attack. Though it may seem hard to infect real users, the fact that they can steal sensitive bank information raises serious alerts to users. 4) Others We have so far presented three main social engineering-based techniques that have been used in existing Android malware. Next, we examine the rest samples that do not fall in the above three categories. In particular, our dataset has 177 standalone apps. We therefore look into those standalone apps and organize them into the following four groups.

40 The first group is considered spyware as claimed by themselves – they intend to be installed to victim’s phones on purpose. That probably explains why attackers have no motivations or the need to lure victim for installation. GPSSMSSpy is an example that listens to SMS-based commands to record and upload the victim’s current location. The second group includes those fake apps that masquerade as the legitimate apps but stealthily perform malicious actions, such as stealing users’ credentials or sending background SMS messages. FakeNetflix is an example that steals a user’s Netflix account and password. Note that it is not a repackaged version of Netflix app but instead disguises to be the Netflix app with the same user interface. FakePlayer is another example that masquerades as a movie player but does not provide the advertised functionality at all. All it does is to send SMS messages to premium-rate numbers without user awareness. The third group contains apps that also intentionally include malicious functionality (e.g., sending unauthorized SMS messages or subscribing to some value-added service automatically). But the difference from the second group is that they are not fake ones. Instead, they can provide the functionality they claimed. But unknown to users, they also include certain malicious functionality. For example, one RogueSPPush sample is an astrology app. But it will automatically subscribe to premium-rate services by intentionally hiding confirmation SMS messages. The last group includes those apps that rely on the root privilege to function well. How- ever, without asking the user to grant the root privilege to these apps, they leverage known root exploits to escape from the built-in security sandbox. Though these apps may not clearly demonstrate malicious intents, the fact of using root exploits without user permission seems cross the line. Examples in this group include Asroot and DroidDeluxe.

4.3.2 Activation

Next, we examine the system-wide Android events of interest to existing Android malware. By registering for the related system-wide events, an Android malware can rely on the built-in support of automated event notification and callbacks on Android to flexibly trigger or launch its payloads. For simplicity, we abbreviate some frequently-used Android events in Table 4.3. For each malware family in our dataset, we also report related events in Table 4.2. Among all available system events, BOOT COMPLETED is the most interested one to existing Android malware. This is not surprising as this particular event will be triggered when the system finishes its booting process – a perfect timing for malware to kick off its background services. In our dataset, 29 (with 83.3% of the samples) malware families listen to this event. For instance, Geinimi (SHA1: 179e1c69ceaf2a98fdca1817a3f3f1fa28236b13) listens to this event

41 Table 4.4 The list of platform-level root exploits and their uses in existing Android malware

Vulnerable Root Release Malware with the Exploit Program Exploit Date Linux kernel Asroot[18] 2009/08/16 Asroot init DroidDream, zHash Exploid[40] 2010/07/15 (<= 2.2) DroidKungFu[1235] DroidDream, BaseBridge adbd (<= 2.2.1) RATC [35] 2010/08/21 DroidKungFu[1235] zygote(<= 2.2.1) Zimperlich [143] 2011/02/24 DroidDeluxe DroidCoupon ashmem KillingInThe 2011/01/06 - (<= 2.2.1) NameOf [4] vold GingerBreak [126] 2011/04/21 GingerMaster (<= 2.3.3) libsysutils zergRush [92] 2011/10/10 - (<= 2.3.6) to bootstrap the background service – com.geinimi.AdService. The SMS RECEIVED comes second with 21 malware families interested in it. This is also rea- sonable as many malware will be keen in intercepting or responding incoming SMS messages. As an example, zSone listens to this SMS RECEIVED event and intercepts or removes all SMS message from particular originating numbers such as “10086” and “10010.” During our analysis, we also find that certain malware registers for a variety of events. For example, AnserverBot registers for callbacks from 10 different events while BaseBridge is interested in 9 different events. The registration of a large number of events is expected to allow the malware to reliably or quickly launch the carried payloads. In addition, we also observe some malware samples directly hijack the entry activity of the host apps, which will be triggered when the user clicks the app icon on the home screen or an intent with action ACTION MAIN is received by the app. The hijacking of the entry activity allows the malware to immediately bootstrap its service before starting the host app’s primary activity. For example, DroidDream (SHA1: fdf6509b4911485b3f4783a72fde5c27aa9548c7) replaces the original entry activity with its own com.android.root.main so that it can gain control even before the original activity com.codingcaveman.SoloTrial.SplashActivity is launched. Some malware may also hijack certain UI interaction events (e.g., button clicking). An example is the zSone malware (SHA1: 00d6e661f90663eeffc10f64441b17079ea6f819) that invokes its own SMS sending code inside the onClick() function of the host app.

4.3.3 Malicious Payloads

As existing Android malware can be largely characterized by their carried payloads, we also sur- vey our dataset and partition the payload functionalities into four diﬀerent categories: privilege

42 escalation, remote control, financial charges, and personal information stealing. 1) Privilege Escalation The Android platform is a complicated system that consists of not only the Linux kernel, but also the entire Android framework with more than 90 open- source libraries included, such as WebKit, SQLite, and OpenSSL. The complexity naturally introduces software vulnerabilities that can be potentially exploited for privilege escalation. In Table 4.4, we show the list of known Android platform-level vulnerabilities that can be exploited for privilege exploitations. Inside the table, we also show the list of Android malware that actively exploit these vulnerabilities to facilitate the execution of their payloads (E1, E2, E3, E4 in Table 4.4 denote Exploid, RATC/Zimperlich, GingerBreak and Asroot, respectively). Overall, there are a small number of platform-level vulnerabilities that are being actively exploited in the wild. The top three exploits are exploid, RATC (or RageAgainstTheCage), and Zimperlich. We point out that if the RATC exploit is launched within a running app, it is effectively exploiting the bug in the zygote daemon, not the intended adbd daemon, thus behavoring as the Zimperlich exploit. Considering the similar nature of these two vulnerabilities, we use RATC to represent both of them. From our analysis, one alarming result is that among 1260 samples in our dataset, 463 of them (36.7%) embed at least one root exploit (Table 4.5). In terms of the popularity of each individual exploit, there are 389, 440, 4, and 8 samples that contain exploid, RATC, GingerBreak, and asroot, respectively. Also, it is not uncommon for a malware to have two or more root exploits to maximize its chances for successful exploitations on multiple platform versions. (In our dataset, there are 378 samples with more than one root exploit.) A further investigation on how these exploits are actually used shows that many earlier malware simply copy verbatim the publicly available root exploits without any modification, even without removing the original debug output strings or changing the file names of associated root exploits. For example, DroidDream contains the exploid file name exactly the same as the publicly available one. However, things have been changed recently. For example, DroidKungFu does not directly embed these root exploits. Instead it first encrypts these root exploits and then stores them as a resource or asset file. At runtime, it dynamically uncovers these encrypted root exploits and then executes them properly, which makes their detection very challenging. In fact, when the first version of DroidKungFu was discovered, it has been reported that no single existing mobile anti-virus software at that time was able to detect it, which demonstrated the “effectiveness” of this approach. Moreover, other recent malware such as DroidCoupon and GingerMaster apparently obfuscate the file names of the associated root exploits (e.g., by pretending as picture files with png suffix). We believe these changes reflect the evolving nature of

43 Table 4.5 An overview of existing Android malware - Part II: malicious payloads Privilege Escalation Remote Control Financial Charges Personal Information Stealing Phone Block Phone User E1 E2 E3 E4 Encrypted NET SMS SMS SMS Call SMS Number Account √ ADRD √ √ AnserverBot † √ Asroot √ √ √ √ √ BaseBridge † √ √ √ √ √ BeanBot † √ √ √ √ BgServ † √ √ √ √ CoinPirate † √ √ √ √ Crusewin √ DogWars √ √ DroidCoupon √ DroidDeluxe √ √ √ DroidDream √ √ DroidDreamLight √ √ √ √ √ DroidKungFu1 √ √ √ √ √ DroidKungFu2 √ √ √ √ √ DroidKungFu3 √ DroidKungFu4 √ √ √ √ √ DroidKungFu5 DroidKungFuUpdate √ √ √ Endofday √ FakeNetﬂix √ FakePlayer ‡ √ GamblerSMS √ √ √ √ √ √ Geinimi † √ √ √ √ GGTracker ‡ √ √ √ GingerMaster √ √ √ √ √ GoldDream † √ Gone60 √ GPSSMSSpy √ √ HippoSMS ‡ √ Jifake ‡ √ √ √ √ jSMSHider † √ √ √ KMin † √ √ Lovetrap † √ √ √ NickyBot √ √ √ Nickyspy √ √ √ √ Pjapps † √ Plankton √ √ √ √ RogueLemon † √ √ RogueSPPush ‡ √ √ SMSReplicator √ SndApps √ √ √ √ √ Spitmo † TapSnake √ Walkinwat √ √ √ √ YZHC ‡ √ zHash √ Zitmo √ √ Zsone ‡ number of families 6 8 1 1 4 27 1 4 28 17 13 15 3 number of samples 389 440 4 8 363 1171 1 246 571 315 138 563 43

44 malware development and the ongoing arms race for malware defense (Section 4.4). 2) Remote Control During our analysis to examine the remote control functionality among the malware payloads, we are surprised to note that 1, 172 samples (93.0%) turn the infected phones into bots for remote control. Specifically, there are 1, 171 samples that use the HTTP-based web traffic to receive bot commands from their C&C servers. We also observe that some malware families attempt to be stealthy by encrypting the URLs of remote C&C servers as well as their communication with C&C servers. For example, Pjapps uses its own encoding scheme to encrypt the C&C server addresses. One of its samples (SH1: 663e8eb52c7b4a14e2873b1551748587018661b3) encodes its C&C server mobilemeego91.com into 2maodb3ialke8mdeme3gkos9g1icaofm. DroidKungFu3 employs the standard AES encryption scheme and uses the key Fuck sExy-aLl!Pw to hide its C&C servers. Geinimi similarly applies DES encryption scheme (with the key 0x0102030405060708) to encrypt its communication to the remote C&C server. During our study, we also find that most C&C servers are registered in domains controlled by attackers themselves. However, we also identify cases where the C&C servers are hosted in public clouds. For instance, the Plankton spyware dynamically fetches and runs its payload from a server hosted on the Amazon cloud. Most recently, attackers are even turning to public blog servers as their C&C servers. AnserverBot is one example that uses two popular public blog services, i.e., Sina and Baidu, as its C&C servers to retrieve the latest payloads and new C&C URLs (Section 4.4). 3) Financial Charge Beside privilege escalation and remote control, we also look into the motivations behind malware infection. In particular, we study whether malware will intentionally cause financial charges to infected users. One profitable way for attackers is to surreptitiously subscribe to (attacker-controlled) premium-rate services, such as by sending SMS messages. On Android, there is a permission- guarded function sendTextMessage that allows for sending an SMS message in the background without user’s awareness. We are able to confirm this type of attacks targeting users in Rus- sia, United States, and China. The very first Android malware FakePlayer sends SMS message “798657” to multiple premium-rate numbers in Russia. GGTracker automatically signs up the infected user to premium services in US without user’s knowledge. zSone sends SMS messages to premium-rate numbers in China without user’s consent. In total, there are 55 samples (4.4%) falling in 7 different families (tagged with ‡ in Table 4.5) that send SMS messages to the premium-rate numbers hardcoded in the infected apps. Moreover, some malware choose not to hard-code premium-rate numbers. Instead, they

45 leverage the flexible remote control to push down the numbers at runtime. In our dataset, there are 13 such malware families (tagged with † in Table 4.5). Apparently, these malware families are more stealthy than earlier ones because the destination number will not be known by simply analyzing the infected apps. In our analysis, we also observe that by automatically subscribing to premium-rate services, these malware families need to reply to certain SMS messages. This may due to the second- confirmation policy required in some countries such as China. Specifically, to sign up a premium- rate service, the user must reply to a confirming SMS message sent from the service provider to finalize or activate the service subscription. To avoid users from being notified, they will take care of replying to these confirming messages by themselves. As an example, RogueSPPush will automatically reply “Y” to such incoming messages in the background; GGTracker will reply “YES” to one premium number, 99735, to active the subscribed service. Similarly, to prevent users from knowing subsequent billing-related messages, they choose to filter these SMS messages as well. This behavior is present in a number of malware, including zSone, RogueSPPush, and GGTracker. Besides these premium-rate numbers, some malware also leverage the same functionality by sending SMS messages to other phone numbers. Though less serious than previous ones, they still result in certain financial charges especially when the user does not have an unlimited messaging plan. For example, DogWars sends SMS messages to all the contacts in the phone without user’s awareness. Other malware may also make background phone calls. With the same remote control capability, the destination number can be provided from a remote C&C server, as shown in Geinimi. 4) Information Collection In addition to the above payloads, we also find that malware are actively harvesting various information on the infected phones, including SMS messages, phone numbers as well as user accounts. In particular, there are 13 malware families (138 samples) in our dataset that collect SMS messages, 15 families (563 samples) gather phone numbers, and 3 families (43 samples) obtain and upload the information about user accounts. For example, SndApps collects users’ email addresses and sends them to a remote server. FakeNetflix gathers users’ Netflix accounts by providing a fake but seeming identical Netflix UI. We consider the collection of users’ SMS messages is a highly suspicious behavior. The user credential may be included in SMS messages. For example, both Zitmo (the Zeus version on Android) and Spitmo (the SpyEpy version on Android) attempt to intercept SMS verification messages and then upload them to a remote server. If successful, the attacker may use them to generate fraudulent transactions on behalf of infected users.

46 0 200 400 600 800 1000 1200 0 200 400 600 800 1000 1200

INTERNET 1232 INTERNET 1122

READ_PHONE_STATE 1179 ACCESS_NETWORK_STATE 913

ACCESS_NETWORK_STATE 1023 WRITE_EXTERNAL_STORAGE 488

WRITE_EXTERNAL_STORAGE 847 READ_PHONE_STATE 433

ACCESS_WIFI_STATE 804 VIBRATE 287

READ_SMS 790 ACCESS_FINE_LOCATION 285

RECEIVE_BOOT_COMPLETED 688 ACCESS_COARSE_LOCATION 263

WRITE_SMS 658 WAKE_LOCK 218

SEND_SMS 553 RECEIVE_BOOT_COMPLETED 137

RECEIVE_SMS 499 ACCESS_WIFI_STATE 134

VIBRATE 483 CALL_PHONE 114

ACCESS_COARSE_LOCATION 480 CAMERA 73

READ_CONTACTS 457 READ_CONTACTS 71

ACCESS_FINE_LOCATION 432 GET_TASKS 60

WAKE_LOCK 425 GET_ACCOUNTS 54

CALL_PHONE 424 SET_WALLPAPER 49

CHANGE_WIFI_STATE 398 SEND_SMS 43

WRITE_CONTACTS 374 WRITE_SETTINGS 39

WRITE_APN_SETTINGS 349 CHANGE_WIFI_STATE 34

RESTART_PACKAGES 333 RESTART_PACKAGES 33

(a) Top 20 permissions requested by 1260 (b) Top 20 permissions requested by 1260 top malware samples free (benign) apps

Figure 4.5 The comparison of top 20 requested permissions by malicious and benign apps

4.3.4 Permission Uses

For Android apps without root exploits, their capabilities are strictly constrained by the permissions users grant to them. Therefore, it will be interesting to compare top permissions requested by these malicious apps in the dataset with top permissions requested by benign ones. To this end, we have randomly chosen 1260 top free apps downloaded from the official Android Market in the first week of October, 2011. The results are shown in Figure 4.5. Based on the comparison, INTERNET, READ PHONE STATE, ACCESS NETWORK STATE, and WRITE - EXTERNAL STORAGE permissions are widely requested in both malicious and benign apps. The first two are typically needed to allow for the embedded ad libraries to function properly. But malicious apps clearly tend to request more frequently on the SMS-related permissions, such as READ SMS, WRITE SMS, RECEIVE SMS, and SEND SMS. Specifically, there are 790 samples (62.7%) in our dataset that request the READ SMS permission, while less than 33 benign apps (or 2.6%) request this permission. These results are consistent with the fact that 28 malware families in our dataset (or 45.3% of the samples) that have the SMS-related malicious functionality. Also, we observe 688 malware samples request the RECEIVE BOOT COMPLETED permission. This number is five times of that in benign apps (137 samples). This could be due to the fact that malware is more likely to run background services without user’s intervention. Note that there are 398 malware samples requesting CHANGE WIFI STATE permission, which is an order of

47 Table 4.6 The overview of six DroidKungFu malware families Root Exploits C&C Malicious Embedded Discovered # Exploid RATC Encrypted In Native In Java Encrypted Number Component Apk Month √ √ √ √ DroidKungFu1 1 com.google.ssearch plaintext 34 2011-06 √ √ √ √ DroidKungFu2 3 com.eguan.state none 30 2011-07 √ √ √ √ √ DroidKungFu3 3 com.google.update encrypted 309 2011-08 √ √ DroidKungFu4 3 com.safesys none 96 2011-10 √ √ √ √ DroidKungFuSapp 1 com.mjdc.sapp none 3 2011-10 DroidKungFuUpdate ------none 1 2011-10

magnitude higher than that in benign apps (34 samples). That is mainly because the Exploid root exploit requires certain hot plug events such as changing the WIFI state, which is related to this permission. Finally, we notice that malicious apps tend to request more permissions than benign ones. In our dataset, the average number of permissions requested by malicious apps is 11 while the average number requested by benign apps is 4. Among the top 20 permissions, 9 of them are requested by malicious apps on average while 3 of them on average are requested by benign apps.

4.4 Malware Evolution

As mentioned earlier, since summer of 2011, we have observed rapid growth of Android malware. In this section, we dive into representative samples and present a more in-depth analysis of their evolution. Speciﬁcally, we choose DroidKungFu (including its variants) and AnserverBot for illustration as they reﬂect the current trend of Android malware growth.

4.4.1 DroidKungFu

The ﬁrst version of DroidKungFu (or DroidKungFu1) malware was detected by our research team [99] in June 2011. It was considered one of the most sophisticated Android malware at that time. Later on, we further detected the second version DroidKungFu2 and the third version DroidKungFu3 in July and August, respectively. The fourth version DroidKungFu4 was detected by other researchers in October 2011 [65]. Shortly after that, we also came across the ﬁfth version DroidKungFuSapp, which is still a new variant not being detected yet by existing mobile anti-virus software (Section 4.5). In the meantime, there is another variant called DroidKungFuUpdate [36] that utilizes the update attack (Section 4.3). In Table 4.6, we summarize these six DroidKungFu variants. In total there are 473 DroidKungFu malware samples in our dataset. The emergence of these DroidKungFu variants clearly demonstrates the current rapid development of Android malware. In the following, we zoom in various aspects of DroidKungFu

48 malware. 1) Root Exploits Among these six variants, four of them contain encrypted root exploits. Some of these encrypted files are located under the directory “assets”, which look like normal data files. To the best of our knowledge, DroidKungFu is the first time we have observed in Android malware to include encrypted root exploits. The use of encryption is helpful for DroidKungFu to evade detection. And different variants tend to use different encryption keys to better protect themselves. For example, the key used in DroidKungFu1 is Fuck sExy-aLl!Pw, which has been changed to Stak yExy-eLt!Pw in DroidKungFu4. It is interesting to notice that in DroidKungFu1, the file name with the encrypted root exploit is “ratc” – the acronym of RageAgainstTheCage. In DroidKungFu2 and DroidKungFu3, this file name with the same root exploit has been changed to “myicon”, pretending to be an icon file. 2) C&C Servers All DroidKungFu variants have a payload that communicates with remote C&C servers and receives the commands from them. Our investigation shows that the malware keeps changing the ways to store the C&C server addresses. For example, in DroidKungFu1, the C&C server is saved in plain-text in a Java class file. In DroidKungFu2, this C&C server address is moved to a native program in plaintext. Also, remote C&C servers have been increased from 1 to 3. In DroidKungFu3, it encrypts the C&C server addresses in a Java class file. In DroidKungFu4, it moves the C&C address back to a native program as DroidKungFu2 but in cipertext. In DroidKungFuSapp, we observe using a new C&C server and a different home-made encryption scheme. 3) Shadow Payloads DroidKungFu also carries with itself an embedded app, which will be stealthily installed once the root exploit is successfully launched. As a result, the embedded app will be installed without user’s awareness. An examination of this embedded app code shows that it is almost identical to the malicious payload DroidKungFu adds to the repackaged app. The installation of this embedded app will ensure that even the repackaged app has been removed, it can continue to be functional. Moreover, in DroidKungFu1, the embedded app will show a fake Google Search icon while in DroidKungFu2, the embedded app is encrypted and will not display any icon on the phone. 4) Obfuscation, JNI, and Others As briefly mentioned earlier, DroidKungFu heavily makes use of encryption to hide its existence. Geinimi is an earlier malware that encrypts the constant strings to make it hard to analyze. DroidKungFu instead encrypts not only those constant strings and C&C servers, but also those native payloads and the embedded app file. Moreover, it rapidly changes different keys for the encryption, aggressively obfuscates the class

49 name in the malicious payload, and exploits JNI interfaces to increase the difficulty for analysis and detection. For example, both DroidKungFu2 and DroidKungFu4 uses a native program (through JNI) to communicate with and fetch bot commands from remote servers. The latest version, i.e., DroidKungFuUpdate, employs the update attack. With its stealthiness, it managed into the official Android Market for users to download, reflecting the evolution trend of Android malware to be more stealthy in their design and infection.

4.4.2 AnserverBot

AnserverBot was discovered in September 2011. This malware piggybacks on legitimate apps and is being actively distributed among a few third-party Android Markets in China. The malware is considered one of the most sophisticated Android malware as it aggressively exploits several sophisticated techniques to evade detection and analysis, which has not been seen before. Our full investigation of this malware took more than one week to complete. After the detailed analysis [8], we believe this malware evolves from earlier BaseBridge malware. In the following, we will highlight key techniques employed by AnserverBot. Our current dataset has 187 AnserverBot samples. 1) Anti-Analysis Though AnserverBot repackages existing apps for infection, it aims to protect itself by actively detecting whether the repackaged app has been tampered with or not. More specifically, when it runs, it will check the signature or the integrity of the current (repackaged) app before unfolding its payloads. This mechanism is in place to thwart possible reverse engineering efforts. Moreover, AnserverBot aggressively obfuscates its internal classes, methods, and fields to make them humanly unreadable. Also, it intentionally partitions the main payload into three related apps: one is the host app and the other twos are embedded apps. The two embedded apps share the same name com.sec.android.touchScreen.server but with different functionality. One such app will be installed through the update attack while the other will be dynamically loaded without being actually installed (similar to Plankton). The functionality partitioning and coordination, as well as aggressive obfuscation, make its analysis very challenging. We have the reason to believe that AnserverBot is inspired by the dynamic loading mechanism from Plankton. In particular, the dynamic mechanisms to retrieve and load remote code is not available in earlier BaseBridge malware. In other words, it exploits the class loading feature in Dalvik virtual machine to load and execute the malicious payload at run time. By employ- ing this dynamic loading behavior, AnserverBot can greatly protect itself from being detected by existing anti-virus software (Section 4.5). Moreover, with such dynamic capability in place,

50 malware authors can instantly upgrade the payloads while still taking advantage of current infection base. 2) Security Software Detection Another related self-protection feature used in AnserverBot is that it can detect the presence of certain mobile anti-virus software. In particular, it contains the encrypted names of three mobile anti-virus software, i.e., com.qihoo360.mobilesafe, com.tencent.qqpimsecure and com.lbe.security, and attempts to match them with those installed apps on the phone. If any of the three anti-virus software is detected, AnserverBot will attempt to stop it by calling the restartPackage method and displaying a dialog window informing the user that the particular app is stopped unexpectedly. 3) C&C Servers One interesting aspect of AnserverBot is its C&C servers. In particular, it supports two types of C&C servers. The first one is similar to traditional C&C servers from which to receive the command. The second one instead is used to upgrade its payload and/or the new address of the first type C&C server. Surprisingly, the second type is based on (encrypted) blog contents, which are maintained by popular blog service providers (i.e., Sina and Baidu). In other words, AnserverBot connects to the public blog site to fetch the (encrypted) current C&C server and the new (encrypted) payload. This functionality can ensure that even if the first type C&C server is offline, the new C&C server can still be pushed to the malware through this public blog, which is still active as of this writing.

4.5 Malware Detection

The rapid growth and evolution of recent Android malware pose significant challenges for their detection. In this section, we attempt to measure the effectiveness of existing mobile anti- virus software. To this end, we choose four representative mobile anti-virus software, i.e., AVG Antivirus Free v2.9 (or AVG), Lookout Security & Antivirus v6.9 (or Lookout), Norton Mobile Security Lite v2.5.0.379 (Norton), and TrendMicro Mobile Security Personal Edition v2.0.0.1294 (TrendMicro) and download them from the official Android Market in the first week of November 2011. We install each of them on a separate Nexus One phone running Android version 2.3.7. Before running the security app, we always update it with the latest virus database. In the test, we apply the default setting and enable the real-time protection. After that, we create a script that iterates each app in our dataset and then installs it on the phone. We will wait for 30 seconds for the detection result before trying the next app. If detected, these anti-virus software will pop up an alert window, which will be recorded by our script. After the first iteration, we

51 Table 4.7 Detection results from four representative mobile anti-virus software

Trend AVG Lookout Norton # Micro # % # % # % # % ADRD 22 22 100.0 13 59.0 5 22.7 11 50.0 AnserverBot 187 165 88.2 89 47.5 2 1.0 57 30.4 Asroot 8 3 37.5 0 0.0 0 0.0 6 75.0 BaseBridge 122 110 90.1 112 91.8 40 32.7 119 97.5 BeanBot 8 0 0.0 0 0.0 0 0.0 0 0.0 Bgserv 9 9 100.0 1 11.1 2 22.2 9 100.0 CoinPirate 1 0 0.0 0 0.0 0 0.0 0 0.0 CruseWin 2 0 0.0 2 100.0 2 100.0 2 100.0 DogWars 1 1 100.0 1 100.0 1 100.0 1 100.0 DroidCoupon 1 0 0.0 0 0.0 0 0.0 0 0.0 DroidDeluxe 1 1 100.0 1 100.0 0 0.0 1 100.0 DroidDream 16 11 68.7 16 100.0 9 56.2 16 100.0 DroidDreamLight 46 14 30.4 45 97.8 11 23.9 46 100.0 DroidKungFu1 34 34 100.0 34 100.0 2 5.8 33 97.0 DroidKungFu2 30 30 100.0 30 100.0 1 3.3 30 100.0 DroidKungFu3 309 0 0.0 307 99.3 1 0.3 305 98.7 DroidKungFu4 96 4 4.1 96 100.0 2 2.0 12 12.5 DroidKungFuSapp 3 0 0.0 0 0.0 0 0.0 0 0.0 DroidKungFuUpdate 1 0 0.0 1 100.0 0 0.0 0 0.0 Endofday 1 1 100.0 1 100.0 1 100.0 1 100.0 FakeNetﬂix 1 0 0.0 1 100.0 1 100.0 1 100.0 FakePlayer 6 6 100.0 6 100.0 6 100.0 6 100.0 GamblerSMS 1 0 0.0 0 0.0 0 0.0 1 100.0 Geinimi 69 69 100.0 69 100.0 38 55.0 67 97.1 GGTracker 1 1 100.0 1 100.0 1 100.0 1 100.0 GingerMaster 4 4 100.0 4 100.0 4 100.0 4 100.0 GoldDream 47 29 61.7 40 85.1 19 40.4 47 100.0 Gone60 9 9 100.0 9 100.0 4 44.4 7 77.7 GPSSMSSpy 6 0 0.0 6 100.0 2 33.3 3 50.0 HippoSMS 4 0 0.0 2 50.0 2 50.0 2 50.0 Jifake 1 0 0.0 1 100.0 0 0.0 1 100.0 jSMSHider 16 11 68.7 16 100.0 13 81.2 16 100.0 KMin 52 52 100.0 0 0.0 40 76.9 52 100.0 LoveTrap 1 0 0.0 1 100.0 1 100.0 1 100.0 NickyBot 1 0 0.0 0 0.0 0 0.0 0 0.0 NickySpy 2 2 100.0 2 100.0 2 100.0 2 100.0 Pjapps 58 44 75.8 57 98.2 26 44.8 50 86.2 Plankton 11 11 100.0 0 0.0 1 9.0 6 54.5 RogueLemon 2 0 0.0 0 0.0 0 0.0 0 0.0 RogueSPPush 9 9 100.0 3 33.3 0 0.0 8 88.8 SMSReplicator 1 1 100.0 1 100.0 1 100.0 1 100.0 SndApps 10 10 100.0 6 60.0 0 0.0 4 40.0 Spitmo 1 1 100.0 1 100.0 1 100.0 1 100.0 Tapsnake 2 0 0.0 2 100.0 1 50.0 1 50.0 Walkinwat 1 0 0.0 1 100.0 1 100.0 1 100.0 YZHC 22 1 4.5 1 4.5 3 13.6 10 45.4 zHash 11 11 100.0 11 100.0 2 18.1 11 100.0 Zitmo 1 1 100.0 1 100.0 1 100.0 1 100.0 Zsone 12 12 100.0 12 100.0 5 41.6 12 100.0 Detected Samples 689 1003 254 966 (out of 1260) (54.7%) (79.6%) (20.2%) (76.7%)

52 further enable the second-round scanning of those samples that are not detected in the first round. In the second round, we will wait for 60 seconds to make sure that there is enough time for these security software to scan the malware. The scanning results are shown in Table 4.7. In the table, the first two columns list the malware family and the number of the samples in this malware family. The rest columns show the number of samples as well as the percentage being detected by the corresponding security software. At the end of the table, we show the number of detected samples for each anti- virus software and its corresponding detection rate. The results are not encouraging: Lookout detected 1003 malware samples in 39 families; TrendMicro detected 966 samples in 42 families; AVG detected 689 samples in 32 families; and Norton detected the least samples (254) in 36 families. Apparently, these security software take different approaches in their design and implementation, which lead to different detection ratio even for the same malware family. For example, AVG detects all ADRD samples in our dataset, while Lookout detects 59.0% of them. Also, Lookout detects most of DroidKungFu3 samples and all DroidKungFu4 samples while AVG can detect none of them (0.0%) or few of them (4.1%). There are some malware families that completely fail these four mobile security software. Examples are BeanBot, CoinPirate, DroidCoupon, DroidKungFuSapp, NickyBot and RogueLemon. One reason is that they are relatively new (discovered from August to October 2011). Therefore, existing mobile anti-virus companies may not get a chance to obtain a copy of these samples or extract their signatures. From another perspective, this does imply that they are still taking traditional approaches to have a signature database that represents known malware samples. As a result, if the sample is not available, it is very likely that it will not be detected.

4.6 Discussion

Our characterization of existing Android malware and an evolution-based study of representative ones clearly reveal a serious threat we are facing today. Unfortunately, existing popular mobile security software still lag behind and it becomes imperative to explore possible solutions to make a diﬀerence. First, our characterization shows that most existing Android malware (86.0%) repackage other legitimate (popular) apps, which indicates that we might be able to eﬀectively mitigate the threat by policing existing Android Markets for repackaging detection. However, the challenges lie in the large volume of new apps created on a daily basis as well as the accuracy needed for repackaging detection. In addition, the popularity of alternative Android Markets will also add

53 significant challenges. Though there is no clear solution in sight, we do argue for a joint effort involving all parties in the ecosystem to spot and discourage repackaged apps. Second, our characterization also indicates that more than one third (36.7%) of Android malware enclose platform-level exploits to escalate their privilege. Unfortunately, the open An- droid platform has the well-known “fragmentation” problem, which leads to a long vulnerable time window of current mobile devices before a patch can be actually deployed. Worse, the current platform still lacks many desirable security features. ASLR was not added until very recently in Android 4.0. Other security features such as TrustZone and eXecute-Never need to be gradually rolled out to raise the bar for exploitation. Moreover, our analysis reveals that the dynamic loading ability of both native code and Dalvik code are being actively abused by existing malware (e.g., DroidKungFu and AnserverBot). There is a need to develop effective solutions to prevent them from being abused while still allowing legitimate uses to proceed. Third, our characterization shows that existing malware (45.3%) tend to subscribe to premium-rate services with background SMS messages. Related to that, most existing malware intercept incoming SMS messages (e.g., to block billing information or sidestep the second- confirmation requirement). This problem might be rooted in the lack of fine-grain control of related APIs (e.g., sendTextMessage). Specifically, the coarse-grained Android permission model can be possibly expanded to include additional context information to better facilitate users to make sound and informed decisions. Fourth, the detection results of existing mobile security software are rather disappointing, which does raise a challenging question on the best model for mobile malware detection. Specif- ically, the unique runtime environments with limited resources and battery could preclude the deployment of sophisticated detection techniques. Also, the traditional content-signature-based approaches have been demonstrated not promising at all. From another perspective, the presence of centralized marketplaces (including alternative ones) does provide unique advantages in blocking mobile malware from entering the marketplaces in the first place. Last but not least, during the process of collecting malware samples into our current dataset, we felt confusions from disorganized or confusing naming schemes. For example, BaseBridge has another name AdSMS (by different anti-virus companies); ADRD is the alias of Hongtoutou; and LeNa is actually a DroidKungFu variant. One possible solution may follow the common naming conventions used in desktop space, which calls for the cooperation from different vendors.

54 4.7 Summary

In this chapter, we present a systematic characterization of existing Android malware. The characterization is made possible with our more than one-year effort in collecting 1260 Android malware samples in 49 different families, which covers the majority of existing Android malware, ranging from its debut in August 2010 to recent ones in October 2011. By characterizing these malware samples from various aspects, our results show that (1) 86.0% of them repackage legitimate apps to include malicious payloads; (2) 36.7% contain platform-level exploits to escalate privilege; (3) 93.0% exhibit the bot-like capability. A further in-depth evolution analysis of representative Android malware shows the rapid development and increased sophistication, posing significant challenges for their detection. Sadly, the evaluation with four existing mobile anti- virus software shows that the best case detects 79.6% of them while the worst case detects only 20.2%. These results call for the need to better develop next-generation anti-mobile-malware solutions.

55 Chapter 5

Sandboxing Third-party Android Apps with Hybrid User-level Sandboxes

5.1 Introduction

In previous chapters, we have presented the study to understand the overall health of app marketplaces, followed with the study of characterization and evolution of Android malware. These studies showed that malicious apps have posed serious threats to users and the current anti-virus apps were not effective. Moreover, besides malicious apps, there are some benign and popular apps which could leak private information without user consent or awareness [37, 125]. Because of this, there is a pressing need to strictly confine these apps, especially their access to sensitive data and system-wide operations. However, Android’s existing permission system lacks flexibility for this purpose. An user has to grant all the permissions requested by an app in order to install it, and cannot make any adjustment to those permissions after installation 1. To address this limitation, researchers have proposed a number of systems to enable fine- grained control of Android apps. For instance, some systems changed the Android framework and the kernel to allow fine-tuning of the apps’ permissions [21, 24, 26, 58, 59, 75, 93, 119, 138] at runtime. TISSA introduced the concept of privacy mode and allowed users to fake the private data, e.g., current location, to each third-party app. Framework enhancement appears to be a natural solution. However, the requirement to update key Android components could strongly

1There is a hidden feature called AppOps [58] in Android version 4.3 to let users disable the access to sensitive resources at runtime. However this feature has been removed since version 4.4.2

56 impair their practical deployment due to the deep fragmentation of the Android platform [120]. Because of this, other researchers leveraged the bytecode rewriting [20, 30, 31, 61] or native code interposing [121] to add a reference monitor to control the app’s access to sensitive APIs. These systems do not need to change the Android framework, thus are immune to the Android fragmentation. However, dynamically loaded classes (e.g., classes loaded by DexClassLoader) could pose serious challenges to the bytecode rewriting systems since the dynamically loaded bytecode is not available when statically rewriting the app. Aurasium [121] interposed the inter- process communication [22] between the app and remote Android services. Therefore, it has to bridge the “semantic gap” by reconstructing high-level semantics from the exchanged raw messages, overall a tedious and error-prone task. More importantly, all those systems can be bypassed or subverted by a malicious app using a native library. For example, the app can leverage native code to tamper with the instrumented bytecode [12] or bypass security checks by “restoring the global offset table entries” [121]. In this chapter, we present AppCage, a secure in-app mechanism to regulate the app’s access to sensitive APIs and dangerous operations (e.g., making phone calls). Like other in-app mechanisms, AppCage does not need to change the Android framework; nor requires the root privilege, and thus can be readily deployed. Specifically, AppCage synthesizes a wrapper app for each target app (i.e., a third-party app to be confined). The wrapper sets up the dex sandbox for the app by hooking into its instance of Dalvik virtual machine and redirecting sensitive framework APIs to their respective stubs. The stubs interpose the access to those APIs and enforce the user-defined policies. With API hooking, AppCage naturally supports dynamically loaded classes because the app eventually needs to call those APIs to retrieve sensitive data. However, API hooking alone could be subverted by the app using native code. To address this challenge, AppCage relies on a second sandbox, native sandbox, to confine the app’s native code. The native sandbox leverages software fault isolation (SFI) [115] to ensure that the app’s native libraries (including the system libraries they depend on) cannot escape from the sandbox or directly modify the code or data outside the sandbox. The app thus cannot tamper with the dex sandbox using native code. In addition, native sandbox prevents the app’s native code from directly requesting sensitive data or performing dangerous operations via binder, the Android’s ubiquitous inter-process communication mechanism. Combining those two sandboxes, AppCage can comprehensively interpose the app’s access to key Android APIs and enforce user-defined policies to fine-tune the app’s permissions. We have implemented a prototype of AppCage and evaluated its effectiveness, compatibility, and performance. Our experiments show that AppCage can successfully detect and block attempts to leak the user’s private data by both malicious and benign-but-invasive Android

57 apps, and the security analysis demonstrates that native sandbox can protect our system from being bypassed or subverted. Moreover, the prototype is shown to be compatible with the popular Android apps we downloaded from the Google Play store, and it incurs negligible overhead for apps without native code and a mild 10.7% overhead for ones with native code. Given the protection oﬀered by AppCage, we consider the performance of AppCage is acceptable for most daily uses. The rest of the chapter is structured as the follows: we ﬁrst introduce the necessary background information and discuss the threat model in Section 5.2, and present the design, implementation, and evaluation of AppCage in Section 5.3, 5.4, 5.5, respectively. We then discuss the design choices and potential improvements to AppCage in Section 5.6. Finally, we conclude the chapter in Section 5.7.

5.2 Background and Threat Model

In this section, we will brieﬂy introduce some key concepts in Android to provide necessary background information of the proposed system, and then present the threat model.

5.2.1 Dalvik Virtual Machine

Most Android apps are written in the Java programming language and compiled into the bytecode for Dalvik VM. Dalvik VM is a shared library loaded into each running app and is respon- sible for executing the app’s bytecode. To support later-binding of Java, Dalvik VM maintains a data structure for each Java class in the app (ClassObject) and one for each of its methods (Method). The Method structure in turn contains a pointer to the method’s bytecode. Figure 5.1 shows a simple class and its representation in Dalvik VM. When Sample.M is called, the VM searches for ClassObject of the class and further Method of the target method [111]. It then retrieves the bytecode of the method to decode and execute it. Dalvik VM allows an app to dynamically load extra classes using DexClassLoader. The app can leverage this convenient capability to change its behavior at run-time. Dynamic class loading poses serious challenges to systems based on the bytecode rewriting because those classes are not available when the app is statically rewritten [30, 31, 61]. AppCage can naturally support this feature because it is based on the API hooking.

58 public class Sample { descriptor public void M ( ) { ... } accessFlags }

super ClassObject

... accessFlags

virtualMethodCount ...

virtualMethods insns 6f20 0400 3200 2200 0500 0e00 ......

ClassObject of Sample Method for M Memory-mapped bytecode Figure 5.1 ClassObject and Method in Dalvik

5.2.2 Java Native Interface

Java Native Interface (JNI) defines a framework for bytecode and native code to call each other. Android developers can use NDK to implement part of their apps in native languages such as C/C++. NDK compiles the source files into shared native libraries that can be dynamically loaded into the app by Dalvik VM under the request of the app’s bytecode. Specifically, the VM uses the dlopen function to load the library into the app, and resolves the address of each imported library function using dlsym. These addresses are cached by the VM to avoid duplicated address resolution later. When a native function is invoked by the bytecode, it passes a special data structure of type JNIEnv, which allows the native code to interact with the bytecode [62, 106]. For example, the native function can use JNIEnv->FindClass("Sample") to locate the Java class Sample and subsequently call its functions. AppCage needs to interpose those key JNI related functions to (1) intercept the loading of native libraries and prepare the native sandbox for them, (2) and switch the run-time environment when entering and leaving the native sandbox.

5.2.3 Dynamic Loading and Linking

Android implements its own dynamic loader and linker for native libraries (/system/bin/linker). Unlike its counterpart in the desktop, Android’s loader resolves all the external functions ea- gerly. For example, if the app’s native code depends on the android log print function in liblog.so, the loader will promptly load the library and recursively resolve the function address. Even though Android does not support lazy address resolution, the PLT/GOT [84] structure

59 Third-party App

App Bytecode stub_f Stub Bytecode Permission Manager Bytecode

f Framework Bytecode Native Code f stub_f libhook.so User Libs Dalvik VM System Libs System Libs

Dex Sandbox Native Sandbox Figure 5.2 System architecture of AppCage is still used for dynamic linking. More speciﬁcally, the compiler generates a stub in the PLT section for each external function. All calls to that function in the library are redirect to the stub, which simply contains an indirect branch to the address in the associated GOT entry. When a native library is loaded, the loader resolves the address of the external function and ﬁlls it in the GOT entry.

5.2.4 Threat Model

Similar to existing solutions [59, 138], we assume an adversary model where third-party apps are not trustworthy (e.g., they could leak personal information) but some of their features are desired by the user. Nevertheless, this privacy-aware user wishes to regulate the apps’ access to the private data and dangerous operations. Our system leverages a utility app that runs on the user’s phone to instrument the target app, and this utility app is trusted. Moreover, we assume that the underlying Linux kernel and the Android middleware are trusted and attackers do not have the root privilege.

5.3 System Design

In this section, we describe the design of AppCage, particularly its hybrid user-level sandboxes: dex sandbox and native sandbox.

60 5.3.1 Overview

The goal of AppCage is to interpose key Android APIs to control the third-party app’s access to private data and dangerous operations. Android apps consist of Dalvik bytecode and the optional native libraries. It is necessary to control both components of an app. AppCage provides dex sandbox and native sandbox for this purpose, respectively (Figure 5.2). To confine bytecode, AppCage hooks into Dalvik VM (libhook.so), and then manipulates its internal data structures to redirect each important Android API to its stub provided by AppCage. At run-time, the stub queries the permission manager whether the operation should be allowed, denied, or prompted to the user for confirmation. If the operation is allowed, the stub will then call the actual API on behalf of the original caller. Figure 5.2 shows how the framework method f is interposed by stub f. Native sandbox applies software fault isolation to confine the app’s native code. It prevents the app from using native code to subvert dex sandbox or directly request system services through binder, Android’s lightweight remote procedure call mechanism [22]. Note that user libraries may depend on some system libraries such as libc.so or libm.so. AppCage provides a set of confined system libraries to the native sandbox. (Dalvik VM is still linked to the original system libraries.) With both sandboxes, AppCage has complete control over the app’s access to sensitive APIs. Use case: Figure 5.2 illustrates the run-time state of a confined app. In the following, we describe the use case of AppCage and how the sandboxes are initialized. AppCage provides a utility app that runs on the user’s phone. For each third-party app to be installed, it generates a wrapper app that carries the whole original app, the bytecode of the stubs, and libhook.so (Figure 5.2). If the app has the native code, it also contains an instrumented copy of the native code. The wrapper requests the same permissions as the original app, and its entry point is assigned to a function in AppCage that is tasked to set up the sandboxes before executing the app [121]. The utility app also monitors the installation of new apps from the official and alternative app stores. For the former, it monitors the directory where the apps normally reside (/data/app) and prompts the user to uninstall the original app and replace it with the generated app. The process is mostly automated and the user only needs to click a few buttons when prompted. We cannot intercept the apps from the official app store because that requires the system privilege. For the latter, it can intercept the installation of the app by listening to the INSTALL PACKAGE intent, and generate and install the wrapper app on-the-fly. The original app is not installed.

61 descriptor ClassObject ......

virtualMethods insns Send SMS Message ...... SmsManager SmsManger.sendTextMessage 1

descriptor ... ClassObject virtualMethods ... Policy Check directMethods insns SmsHooks.sendTextMessageDirect ... 2 ... SmsHooks SmsHooks.sendTextMessage Figure 5.3 Dalvik hooking of SmsManager.sendTextMessage

5.3.2 Dex Sandbox

AppCage interposes the app’s access to key framework APIs by essentially hooking those APIs. In contrast to previous systems that rewrite the app’s bytecode for the same purpose [30, 31, 61], AppCage does not require extra efforts to support dynamically loaded classes and can tolerate obfuscation of the app’s bytecode because the app eventually needs to call those interposed APIs to be effective. AppCage’s API hooking is implemented through direct manipulation of Dalvik VM’s internal data structures. (We will discuss the compatibility issue raised in Section 5.5.3.) As mentioned in Section 5.2.1, Dalvik VM maintains a ClassObject data structure for each Java class in the app including those of the framework, through which we can find all the methods of the class. For each framework class that has sensitive methods, we manually create a stub class that contains the same set of stub methods 2. The stub methods query the permission manager whether the operation should be allowed, and call the original methods if so. Figure 5.3 shows an example of the SmsManager class, which allows an app to send text messages in the background via the predefined sendTextMessage method, possibly to premium numbers. To interpose this method, AppCage loads SmsHooks, the stub class for SmsManager, into the app, and manipulates the pointers in their corresponding ClassObjects so that SmsManager. sendTextMessage points to SmsHooks.sendTextMessage and the pointer to the original method

2Most of this process can be automated. Doing it manually is acceptable since it is only a one-time eﬀort.

62 SmsManager.sendTextMessage is stored in SmsHooks’s array of direct methods (arrow 1 and 2 in Figure 5.3, respectively). As such, the app will be redirected to SmsHooks.sendTextMessage when it tries to send a text message and subject to policy check. If the operation is allowed, SmsHooks.sendTextMessage calls the original method, which can be found in SmsHooks’s array of direct methods. Unlike virtual methods, direct methods are called directly without dynamic method resolution [111]. Hence, it is guaranteed that the original method will be called. By only manipulating method pointers, our system is compatible with the just-in-time compiling by Dalvik VM, a key technology to improve the system performance.

5.3.3 Native Sandbox

Android allows its apps to use native code via the JNI interface (Section 5.2.2). Native code is often used to speed up performance-critical tasks such as rendering of 3D games. However, native code could be exploited to subvert security schemes based on bytecode. For example, it can revert the changes to Dalvik VM’s data structures made by AppCage. To address that, we adopt the software fault isolation (SFI) [115] technology to conﬁne the app’s native code. AppCage’s native sandbox provides the following security guarantees: native code cannot write to memory out of the sandbox so that it cannot tamper with dex sandbox (memory read does not pose a threat to AppCage because sensitive data are maintained by Android’s system service app); native code cannot escape from the sandbox; the access to dangerous instructions such as system call is regulated. Since source code of the app’s native binary is not available, we use binary rewriting to implement software fault isolation. Binary rewriting of the native code can take place at both installation time and run-time: AppCage instruments any native libraries discovered when generating the wrapper app (Sec- tion 5.3.1). It also hooks into the related JNI API to translate native libraries that are unknown during the installation, such as the encrypted libraries [99] or the downloaded ones. Our binary rewriter enforces the same set of rules as Native Client (NaCl) [104, 124]. Particularly, instructions are grouped into equal-sized bundles (16 bytes), and indirect branch instructions such as indirect call and return must target the boundary of a bundle. Moreover, the instructions inserted by AppCage (bic and orr) to conﬁne an instruction must be put in the same bundle as that instruction so that they cannot be bypassed by indirect branches jumping over them. The rules of NaCl provide our native sandbox a solid theoretical and practical foundation in security. However, our binary rewriter needs to handle the app’s native code in the binary format, while NaCl is a compiler plugin and thus requires the access to source code. Code generated by NaCl normally has less overhead than that by our binary rewriter. As such, AppCage also utilizes

63 a modified NaCl compiler to confine system libraries that the app’s native code rely on since their source code is readily available. Even though ARM is a RISC architecture, rewriting ARM binaries is not straightforward: 1.) an ARM binary can mix the ARM instructions (32 bits) and the THUMB-2 instructions (16 or 32 bits). 2.) Constants are often embedded among instructions. We need to identify them and prevent them from being executed. 3.) ARM instructions can directly refer the program counter (pc), often to read the embedded constants in code. Binary rewriting shifts the instructions around and may cause the wrong pc to be used. To address challenge 2 and 3, AppCage retains the original code section of the app’s native code but makes it read-only and non-executable. The translated code section only contains instructions but not constants, which must be loaded from the original code section instead. AppCage also keeps a mapping between the original pc and the translated pc and converts them when necessary. To rewrite a binary, AppCage first disassembles it, breaks it into basic blocks, and instruments it as required by the native sandbox. Disassembling Native Code: AppCage recursively disassembles the app’s native code [129] using the exported functions as the initial starting points (the binary may be stripped and may not contain the complete symbol table.) Specifically, it keeps disassembling instructions from a starting point until a return instruction or other terminating instructions. Any targets of direct jumps or call instructions are added to a work list as the new starting points. After exhausting the work list, we start disassembling the leftover gaps with a trial-and-error strategy. Our disassembler faces two challenges. First, constants are often embedded in-between instructions because they do not fit in the instruction (32 bits at most). To address that, we observe that constants are often collected at the end of functions and referred to with the pc-relative addressing mode, for example,

ldr r1, [pc, #284]

We accordingly treat the targets of pc-relative load instructions as constants. However, the heuristic may treat the real code as constants. This is handled at run-time by rewriting those missed instructions on demand. The second challenge is that a binary can consist of functions in the ARM and THUMB/THUMB-2 states. These states have different instruction length and encoding. AppCage needs to identify the instruction state to correctly disassemble them. This is solved as follows: first, branch instructions such as B, BL with an immediate offset, BX, and BLX specify the state of the target instruction in the encoding. AppCage decodes the targets accordingly using the target instruction encoding. Second, we use the context of a gap to infer its state. For example, if the instructions before and after a gap are in the THUMB state, the

64 gap likely is also in that state. Third, if the previous heuristics fail to decide the instruction state, we assume the instructions are in the ARM state and start to disassemble them. We will restart the process in the THUMB state if errors are encountered, for example, if there are invalid instructions or the data flow in a peephole is inconsistent [116]. Note that the instruction mode which is determined by the heuristic, e.g., the branch target of an indirect branch instruction, may be wrong during statically disassembling. AppCage records the instruction mode for such instructions and compare it with the actual instruction mode at run-time. If there is a mismatch, then these instructions will be re-disassembled and instrumented at run-time. Native Code Instrumentation: To rewrite the app’s native code, AppCage breaks the disassembled instructions into basic blocks and then instruments each of them according to the instruction types. Figure 5.4 shows a concrete example for each such case. For simplicity, we assume the native sandbox is at the [0x0, 0x1FFFFFFF] address space range in the figure. a.) Memory write instructions: AppCage requires that memory write instructions can only target addresses within the sandbox. To this end, we position the native sandbox at an address that is 2n-byte aligned with a length of 2n. Consequently, we can confine memory writes by fixing the top 32 − n bits of the target address to that of the sandbox. For example, if the sandbox is located at the range of [0x40000000, 0x5FFFFFFF], we can use the following two instructions to confine memory writes (assuming r0 is the base register): bic r0, r0, #0xa0000000 /* clear bits 31,29 */ orr r0, r0, #0x40000000 /* set bits 30 */ Moreover, we put two guard pages around the sandbox, one at each end, to accommodate addressing modes with an immediate offset, which is always less than 4, 096 in the ARM architecture (see case 1 in Figure 5.4 for an example). If the target address is calculated from several registers, we first save the address to a scratch register (spill one if necessary) and apply the same instructions as above to confine it. The memory write instruction is then patched to use the scratch register as the target (case 2 in Figure 5.4). AppCage normally instruments every memory write instruction. One exception is those instructions with sp as the base register and an immediate offset. They are frequently used to update local variables. To reduce overhead, we do not instrument this type of instruction (case 3 in Figure 5.4), but instead instrument all instructions that update the sp register to guarantee that sp is within the sandbox (case 4 in Figure 5.4.) b.) Branch instructions: the second category of instructions to rewrite consists of branch instructions, used for jumps and calls. Branch instructions can address the target with an immediate offset (direct branch) or with registers (indirect branch). Both types of branch instructions

65 (1) memory write: immediate offset (5) direct branch before: before: e2b8: e5840008 str r0, [r4, #8] dca4: 1affffbf bne 0xdba8 after: after: f8b0: e3c4420e bic r4, r4, #0xe0000000 f068: 1affffb3 bne 0xef3c f8b4: e5840008 str r0, [r4, #8] We need to patch the target of the direct branch instructions to its corresponding translated target. Before writing data into memory,we mask off some bits of the target address. Since the immediate offset is within (6) indirect branch: branch address on the stack the 4K range, we can confine it by adding a guard page before and after the native sandbox. before: 164f8: e8bd8002 pop {r1, pc} (2) memory write: register offset after: 18e10: e8bd0002 pop {r1} before: 18e14: e59ff718 ldr pc, [pc, #1816] ;0x19534 f054: e784e10c str lr, [r4, ip, lsl#2] ... 19534: 0001aae4 after: 1004: e084310c add r3, r4, ip, lsl#2 The registers other than PC will be popped first, and then it jumps to the 1008: e3c3320e bic r3, r3, #0xe0000000 indirect branch trampoline at offset 0x1aae4 (this address is patched 100c: e583e000 str lr, [r3] by AppCage according to whether the PC is on the stack or in the reigster.) The trampoline fecthes the branch address from the stack and For instructions using the register offset,we allocate check whether it is valid. If so, it will jump to the address for execution. a scratch register (r3 in this case) first to store the target address of memory write, and then we mask (7) indirect branch: branch address in a register off the related address bits. The original instruction is replaced by one using the scratch register. before: 164bc: e12fff1e bx lr (3) memory write: SP as the base register with immediate offset after: 18dcc: e59ff75c ldr pc, [pc, #1884] ;0x19530 ... before: 19530: 0001aa88 114a0: e58d11d0 str r1, [sp, #464] Similar to case 6, it jumps to the indirect branch trampoline. This after: trampoline validates the branch target in the register and jumps to it 12f5c: e58d11d0 str r1, [sp, #464] for execution, if valid.

For instructions using the SP register as the base with (8) using PC as the source register in non-branch instructions immediate offset, we do not write them but instead ensure that SP is always within the sandbox by rewriting before: the instructions that update SP. 14e80: e08f1001 add r1, pc, r1

(4) computation : update SP after: 1748c: e52d3004 push {r3} 17490: e59f331c ldr r3, [pc, #796] ;0x177b4 before: 17494: e0831001 add r1, r3, r1 1c284: e084d005 add sp, r4, r5 17498: e49d3004 pop {r3} ... after: 177b4: 00014e88 10200: e084d005 add sp, r4, r5 10204: e3cdd20e bic sp, sp, #0xe0000000 We allocate a scratch register (r3 in this case), spill it when necessary, We instrument instructions that update SP to make sure and load the original PC stored at address 0x177b4 into it. The original SP is always within the native sandbox. instruction is transformed to use this scratch register.

Figure 5.4 Instrumentation of native code by AppCage

66 need to be instrumented to ensure that the app’s native code cannot escape from the sandbox. Direct branches can be handled completely during binary rewriting because their targets are known statically. We only need to verify that they target legitimate instructions in the sandbox and patch the immediate offsets accordingly (case 5 in Figure 5.4). Indirect branches require validation of the branch targets at run-time because they are unknown during translation. The address of the target may be on the stack (case 6 in Figure 5.4) or in a register (case 7 in Figure 5.4). AppCage uses a trampoline to handle the indirect branch instruction. The original instruction is replaced with a direct branch to its associated trampoline. The trampoline retrieves the original branch address and verifies that it lies within the sandbox. If so, the trampoline further converts the address to the translated target, with the help of the mapping between the original pc and the translated pc, and branches to it. c.) Instructions using pc as a general register: in ARM, pc (program counter) can be directly accessed as a general register. Instructions using pc as the destination operand are in fact indirect branch instructions. This case has been discussed in b). If pc is used as the source operand, its value is decided by the address of the currently executing instruction, and thus is different from the original and intended value. For example, the following instruction at address 0x14e80 is relocated to 0x1748c by the binary rewriter. When the app runs, the pc register has a value of 0x17494, instead of the expected value of 0x14e88 (for historic reasons, pc in ARM is the address of the current instruction plus 8.)

14e80: add r1, pc, r1 --> 1748c: add r1, pc, r1 PC: 0x14e88 PC: 0x17494

To address this, we allocate a scratch register, load the original pc into it, and patch the instruction to use the scratch register instead of the current pc (case 8 in Figure 5.4). d.) System call instruction: uncontrolled system calls can be exploited to subvert our system, for example, by tampering with the memory protection or calling system services through binder. As such, AppCage disallows direct system calls in the app’s native libraries. The app instead has to access the kernel services through the APIs of the system libraries (e.g., libc). This is barely restrictive because very few apps, if any, rely on direct system calls. To prevent those libraries from being misused, AppCage provides a conﬁned copy of the necessary system libraries to the native sandbox. During rewriting, direct system call instructions in the app’s native code are replaced by branches to a function that terminates the current app. System Libraries Instrumentation: the app’s native code often relies on system libraries for service (e.g., libc.so). For performance reasons, AppCage uses the NaCl compiler for ARM [104] to sandbox the system libraries. Those libraries are loaded into the native sandbox by a custom

67 loader and linked with the app’s native code (Dalvik VM uses an unconfined version of the system libraries). Those libraries are subjected to the same constraints as the app’s native code: memory writes and branch instructions must target locations within the native sandbox. However, NaCl compiler assumes that the lower 1GB memory is reserved for the sandbox. This cannot be guaranteed by AppCage because the location of native sandbox is unknown until it is initialized at run-time. Hence, we need to customize the NaCl compiler for our purpose. NaCl uses the bic instruction to clear the most significant two bits of a branch target to ensure it is within the first 1GB of the address space. The last four bits of the target are also cleared to prevent the instrumented code from branching to the middle of an instruction bundle (16 bytes):

bic r0, r0, 0xc000000f /*clear top 2 and the last 4 bits*/

For memory store instructions, NaCl uses the tst and streq instructions to conditionally execute the memory write if the address is inside the sandbox.

tst r0, #0xc0000000 /* within the first 1GB? */ streq r1, [r0, #12] /* store to memory if so*/

Because native sandbox is not guaranteed to start at address 0, we modify the NaCl compiler to emit bic and orr instructions to confine sensitive instructions, similar to the binary rewriter. However, we have to keep the immediate values of those instructions undefined during translation because the location of native sandbox is unknown until it’s initialized at run-time. AppCage’s custom loader patches those instructions with the actual location of the sandbox. JNI Interface: the app’s bytecode and native code can call each other through the JNI interface. However, Dalvik VM and native sandbox have different contexts under AppCage such as stack, heap, and the code section. AppCage needs to intercept the JNI calls and switches the context accordingly. This has to be performed in both directions, from bytecode to native code and vice versa. Bytecode can load and resolve native functions via Android’s dynamic linker (/system/bin/ linker) and call it through the JNI interface. To intercept those calls, we hook the dlopen and dlsym functions in Dalvik VM. The dlopen hook allows us to rewrite native libraries unseen during the installation (e.g., a newly downloaded library). Moreover, when dlsym is called to resolve a native function, we return its associated gate function in place of the target function. The gate prepares the execution context for the sandbox by copying over the parameters and switching the stack and registers. It then enters the sandbox to execute the target function. When the function returns, the gate switches the context back to Dalvik VM. Meanwhile, native code can also call exported bytecode functions through the JNIEnv structure. To intercept those calls, we

68 Table 5.1 Conﬁned operations by the current prototype Operation Permissions Send SMS SEND SMS Read SMS READ SMS Delete SMS WRITE SMS Phone call CALL PHONE Read contacts READ CONTACTS Write contacts WRITE CONTACTS Read call logs READ CALL LOG ACCESS FINE LOCATION Get location ACCESS COARSE LOCATION Network INTERNET Read IMEI READ PHONE STATE

replace the functions in JNIEnv with their stubs in the sandbox. The stub switches the execution environment to that of Dalvik VM and then calls the actual JNIEnv functions [106]. The direct reference to Java heap is processed through the copy-in and copy-out mechanism [106].

5.4 Implementation

We have implemented a prototype of AppCage. In particular, dex sandbox is implemented in the Java and C++ programming language, while native sandbox is implemented in C and the ARM assembly. In this section, we discuss the concrete implementation of this prototype.

5.4.1 Dex Sandbox

AppCage generates a wrapper app for a third-party app. The wrapper app consists of the original app and the additional components for the sandboxes. AppCage features both a dex sandbox for the bytecode and a native sandbox for native code. Dex sandbox hooks into the sensitive framework APIs to enforce the user-deﬁne policies. These policies are managed by a separate app (permission manager in Figure 5.2). Only permission manager can update the user policy database; other apps can read the database through an exported content provider interface. Table 5.1 lists the operations that our prototype can interpose. It is relatively easy to extend this list by adding more stubs. Permission manager can respond to a request with three verdicts: allow, deny, and prompt-to-user. It can be enhanced to return mock results (e.g., fake location) to improve its compatibility with third-party apps [59, 138].

69 High Wrapper App's Data, Heap, Stack, System Libraries

Sandbox Library

Trampolines User Libraries System Libraries Stack

Heap Native Sandbox Low

Figure 5.5 Memory layout of the native sandbox

Original App Loading: AppCage loads the embedded app into dex sandbox for execution. It leverages the DexClassLoader class for this purpose. However, this class loader is diﬀerent from the class loader used by Dalvik VM to load the wrapper app and the stubs (PathClassLoader), and only classes loaded by the same class loader can refer to each other (this is also true for apps without AppCage). Therefore, classes in the original app cannot communicate with the stubs. To address this, we change the value of pathList of PathClassLoader to that of DexClassLoader. After that, the classes of the original app will behave like that they are loaded by the same loader as the stubs.

5.4.2 Native Sandbox

Native sandbox conﬁnes the app’s native code into a continuous block of memory space. Fig- ure 5.5 shows the layout of the app’s address space at run-time. The memory for native sandbox is 256MB aligned so that we can use the simple bic and orr instructions to control memory access. AppCage has a custom loader for the native code. It intercepts the app’s requests to load the native code to sandbox it. Speciﬁcally, the loader will load both the original code section and the translated code section. The former is marked as read-only and non-executable. We

70 keep this section so that pc-relative instructions can access the correct memory. The loader also needs to ﬁx various addresses in the translated code, such as those of the indirect jump trampolines. Link to System Libraries: the app’s native code is linked to NaCl-compiled system libraries. NaCl requires that branch targets aligned at the boundary of a bundle (16 bytes). This alignment ensures that the sandboxed code cannot jump into the middle of a bundle and bypass security checks. As such, we need to align return addresses of the native code at the boundary of a bundle. For example, the instruction at oﬀset 0x4ae8 calls android log print@plt, which eventually jumps to the android log print function in the system library. When this function in the system library returns, the last 4 bits of the lr register are masked out by NaCl [104]. When translating this instruction, we need to add padding instructions (nop) to ensure that the return address is 16 bytes aligned (0x22b0 in the example).

4ae8: ebfff8de bl 2e68 <__android_log_print@plt> --> 22a4: e320f000 nop {0} 22a8: e320f000 nop {0} 22ac: ebfff772 bl 0x7c <__android_log_print@plt> /*lr = 0x22b0 */

Changes of System Libraries: AppCage provides the NaCl-compiled system libraries to the native sandbox. It makes the following additional changes for them to safely run in the sandbox: First, the heap management functions in libc such as malloc are changed to allocate memory from the heap of the native sandbox, instead of the default heap. Second, we add security checks in some library functions. For example, the app should not be able to use mprotect to make the code section writable. Another example is the ioctl function in libc, which may be misused to send commands to the key Android services through the binder interface (/dev/binder), bypassing AppCage’s policy check. Third, we relocate the thread local storage (TLS) to the native sandbox. Particularly, we allocate a special region inside the sandbox for TLS and change the get tls function accordingly. Last, callback functions may pose a problem for AppCage. For example, the app can register a callback function to the qsort function in libc. When qsort calls this function, a segmentation fault will be raised because the function is a part of the original code section, which is non-executable (Section 5.3.3). To address this, we register a signal handler to capture segmentation faults caused by those functions. In the signal handler, we lookup the translated callback function and dispatch to it. Indirect Branch Trampolines: the indirect branch trampoline is fairly involved. It ﬁrst saves the scratch registers and the status register, and retrieves the branch target from the stack or

71 1a544: e24dd004 sub sp, sp, #4 ; 0x4 1a548: e92d400f push {r0, r1, r2, r3, lr} 1a54c: ea000000 b 0x1a554 1a550: e1200070 bkpt 0x0000 1a554: e10f2000 mrs r2, CPSR //move status to r2 1a558: e92d0004 push {r2} //save status register on stack 1a55c: ea000000 b 0x1a564 1a560: e1200070 bkpt 0x0000 1a564: e1a03000 mov r3, r0 //move jump target (r0) to r3 1a568: e59f25a8 ldr r2, [pc, #1448] ; 0x1ab18 1a56c: ea000000 b 0x1a574 1a570: e1200070 bkpt 0x0000 1a574: e12fff32 blx r2 // retrieve the pc 1a578: e8bd0004 pop {r2} //pop status register to r2 1a57c: ea000000 b 0x1a584 1a580: e1200070 bkpt 0x0000 1a584: e129f002 msr CPSR_fc, r2 //restore status register 1a588: e58d0014 str r0, [sp, #20] //put new PC on stack 1a58c: ea000000 b 0x1a594 1a590: e1200070 bkpt 0x0000 1a594: e8bd400f pop {r0, r1, r2, r3, lr} 1a598: e49df004 pop {pc} //jump to new PC .. /* patch it to the function to get pc from stack or register*/ 1ab18: 00000000

Figure 5.6 An example of indirect branch trampoline the register. The branch target (in the original code section) is then converted to the translated pc. At last, the trampoline restores the registers and branches to the target pc. Figure 5.6 shows a concrete example of the indirect branch trampoline. The trampoline has a non-trivial design because we cannot simply spill the scratch registers to the stack. For example, if the indirect branch instruction calls a function, some parameters may be saved on the stack. Changing the stack passes wrong values to those parameters. If the indirect branch instruction returns from a function, it could return to a wrong location, even out of the sandbox. The trampoline in Figure 5.6 guarantees the stack is not changed before branching. Since the indirect branch trampoline is in the native sandbox, we need to prevent it from being misused by the native code. Binary rewriting guarantees that the app’s native code cannot jump to the middle of a trampoline. This is because branches in the translated code can only target addresses in the mapping table of the original and translated pcs, and only the beginning of the trampoline is in this table. However, the native code may achieve the same goal by leveraging the indirect branches in the system libraries since they can target any bundles. To this end, we put the bkpt instruction at the code boundaries of the trampoline, and use b instruction to skip bkpt inside the trampoline [124]. Any attempts to jump into the trampoline from the NaCl-compiled system libraries will be captured because they can only

72 target those boundaries (the bkpt instructions in the trampoline), a security rule enforced by the NaCl compiler.

5.4.3 Native Sandbox Optimizations

To reduce performance overhead, we apply several optimization techniques to the native sandbox. Redundant Check Removal: when translating memory write instructions, we can analyze the register usage in an instruction bundle and remove redundant safety checks. For example, we only need to apply the conﬁnement instructions to the ﬁrst memory write instruction in the following case:

3324: str r3, [r4, #8] 3328: str r3, [r4, #20] --> /* native sandbox: [0x40000000, 0x5FFFFFFF] */ 4400: bic r4, r4, #0xa0000000 4404: orr r4, r4, #0x40000000 4408: str r3, [r4, #8] 440c: str r3, [r4, #20]

Function Return Optimization: ARM binaries often use the pop instruction to return from a function. Our binary rewriter treats the pop instruction using pc as the target operand as an indirect branch, which has a relatively heavy instrumentation (Section 5.4.2). Considering function return is highly frequent, we need to avoid the time-consuming indirect branch trampoline. To this end, we fetch the branch target into the lr register and add instructions to conﬁne the value of lr before jumping to it. In particular, we mask oﬀ the last four bits of the return address to align it with the NaCl instruction bundle. The following instructions illustrate this optimization:

pop {r3, r4, pc} --> pop {r3, r4] pop {lr} /* native sandbox: [0x40000000, 0x5FFFFFFF] */ bic lr, lr, #0xa000000f orr lr, lr, #0x40000000 bx lr

Calls of System Library Functions: compilers use the PLT/GOT structure to support dynamic linking. Speciﬁcally, calls to an external function are patched to the function’s stub

73 Table 5.2 AppCage successfully blocks malicious behaviors of samples in 15 malware families

Malware Send SMS Read/Delete SMS Phone Calls Location Call Logs Contacts Internet IMEI √ FakePlayer √ √ YZHC √ √ GoldDream √ TapSnake √ √ √ √ √ √ NickiBot √ √ DroidKungFu √ √ √ √ BeanBot √ √ √ √ Gone60 √ SndApps √ √ √ √ HippoSMS √ √ √ Zitmo √ √ Zsone √ √ Spitmo √ √ √ √ DroidLive √ √ √ √ √ √ Geinimi in the PLT section, which indirectly branches to the function address in the associated GOT entry. The GOT entry is normally ﬁlled in by the dynamic linker after it resolves the address of the external function. In AppCage, the GOT entries are patched by our own custom loader and are guaranteed to be in the sandbox. Therefore, we do not need to rewrite the indirect branch instructions inside the PLT section (the GOT section is set to read-only after initialization.) Address Cache in Indirect Branch Trampolines: indirect branch trampolines need to look up the mapping between old pc and translated pc. Before looking up the table, we ﬁrst search a small cache of the previously converted pcs (8 entries). This simple optimization has a high hit rate (90% for the nbench [66] benchmark.)

5.5 Evaluation

In this section, we evaluate the eﬀectiveness, compatibility, and performance of our prototype. The experiments are based on a Google Nexus S phone running Android 4.1.2 (build number JZ054K).

5.5.1 Eﬀectiveness of AppCage

We used samples from 15 malware families obtained from the Android Malware Genome Project [139] and online malware [73] repository to evaluate the eﬀectiveness of AppCage. Speciﬁcally, we try to trigger their malicious behaviors and check whether our prototype can capture all of them. However, some samples can only be triggered by commands from the defunct

74 (a)Gone60 malware: reading (b) FakePlayer: sending SMS to contacts a premium number

Table 5.3 AppCage detects malicious behaviors

remote command and control (C&C) servers. For example, GoldDream waits for the commands to send SMS or make phone calls to premium numbers in the background. To address this, we redirect the traffic to the C&C servers to our local machines at the network level and send commands to these malware samples. Similarly, some malware samples need to be triggered by particular SMS messages. Table 5.2 lists these samples and the attempted malicious operations by them. AppCage successfully captures all the attempts by them to leak private information and perform dangerous operations. In the following, we present the details of the experiment with the Gone60 malware. Gone60 was first discovered from the official Android Market in September 2011. When executed, it immediately reads the call logs, contacts and SMS messages in the phone and sends them to the remote server. We installed this app on our test phone, AppCage intercepted the installation and installed a confined version of it. When the app was started, AppCage detected its attempts to read the sensitive information. Since we have not specified any policy for this app yet, AppCage prompted us to choose whether to allow or deny the access. Figure 5.3(a) shows

75 the prompt generated by AppCage regarding Gone60’s access to the contacts. Figure 5.3(b) shows a similar prompt when FakePlayer tries to send SMS to a premium-rated number. In addition to malware, we also experimented with some benign but invasive apps. These apps are not malicious, but may aggressively access the private information, say, for targeted ads. In our evaluation, AppCage can detect all the accesses and provide users an option to block them. For example, the BestBuy app requests the permissions to access location, send SMS, and make phone calls. The user can leverage AppCage to disallow this app to send SMS, but allow it to access location (e.g., to ﬁnd the local BestBuy stores.)

5.5.2 Security Analysis

In this chapter, we assume a threat model in which third-party apps are untrusted or even malicious. In this section, we explore possible attacks to bypass or subvert AppCage and the countermeasures built into our system. Java Obfuscation: the bytecode of Android apps are often obfuscated. Java-based obfuscation does not affect the effectiveness of our system because dex sandbox is implemented in Dalvik VM unreachable to the bytecode (tamper-resistance), and the app still needs to call the interposed APIs to get private information. For example, Java reflection is often used to hide the actual framework APIs called by the app. AppCage can interpose this behavior because the function call will eventually be dispatched through the Method structure in Dalvik VM, where AppCage places its hook. Dynamic Bytecode: Android apps can dynamically load external bytecode for execution. For example, they can download the bytecode from a remote server and use DexClassLoader or other loaders to execute it. This poses a threat to bytecode-rewriting systems because the new bytecode is not available during rewrite. This attack is not effective against our system for the same reason as Java obfuscation. AppCage is positioned to interpose the dynamically loaded bytecode. Direct Calls to System Services: In Android, sensitive data are maintained by separate system service daemons and exported to third-party apps through the binder interface. An app can directly access those services through the IBinder interface (in Java) [55] or the raw IPC (in native code). For example, the app can obtain the IBinder interface of the location service to get the current location without using the high-level LocationManager class. AppCage can defeat such attacks by preventing the app from obtaining the IBinder instance of known system services (most legitimate apps do not do this anyway). Moreover, the app can use native code to open the binder device and send commands to the system services using the ioctl system

76 call. AppCage adds security checks in the ioctl function of libc to prevent it, and it disallows the native code to issue system calls directly (Section 5.3.3). Note that we only block the ioctl system call directly issued from user native libraries or the (confined) system libraries linked with user native libraries. The original communication channels to remote system services through the binder interface remain unchanged since they are going through original system libraries. Tampering with Dalvik VM: the app may tamper with Dalvik VM using native code since they share the same address space [12]. For example, it can remove all the hooks of AppCage in Dalvik VM to disable the policy check. This attack can be foiled by our system because the app’s native code is sandboxed and cannot write memory out of the sandbox. In addition, it cannot escape from the sandbox to execute untranslated code. Attacking Native Sandbox: the app may also try to attack the native sandbox. For example, it may try to load unsandboxed native code or break out of the sandbox. Our system design is secure against those attacks. First, AppCage hooks into the Android’s dynamic loader. It intercepts any attempt to load a native binary and ensures that all the loaded user binaries are instrumented and sandboxed. Second, even though AppCage uses both a binary rewriter and the customized NaCl compiler to instrument native code, they enforce the same set of rules as the Native Client, which has been proved to be reliable and secure [104, 124], despite a few fixed implementation issues. Synthetic Attack: to further evaluate the security of the native sandbox, we create several synthetic attacks that violate the native sandbox rules. The first one is to change the loaded app bytecode at run-time, i.e., by writing to the memory mapped bytecode. Our system can capture such an attempt since this attack invokes the mmap system calls (Section 5.3.3) to remap the memory space containing the bytecode as readable and writeable. The second one is to manipulate the Dalvik internal data structure to change the control flow of the app code using the native library at run-time. For instance, it manipulate the method pointer inside the Dalvik VM to invoke the sensitive APIs. Our system blocks this attack since it writes to the memory space outside the native sandbox.

5.5.3 Compatibility of AppCage

AppCage may cause compatibility issues for two reasons: ﬁrst, some apps may not be accom- modating to constraints imposed by AppCage’s sandboxes, particularly the native sandbox. For example, AppCage disallows the app’s native code to directly issue a system call. Meanwhile, dex sandbox should pose few problems because it is, in essential, a set of hooks. Overall, we

77 Table 5.4 Some apps used in compatibility test

(†: in seconds) App Size Package Name Time† Job Search 474K com.indeed.android.jobsearch 5.7 Comics 3.7M com.iconology.comics 13.5 chase 1.8M com.chase.sig.android 10.6 Domino’s Pizza 7.2M com.dominospizza 18.6 Early Detection Plan 4.6M com.nbcf.edp 13.7 Super-Bright 1.5M com.surpax.ledflashlight.panel 4.8 LED Flashlight Ebay 9.6M com.ebay.mobile 37.9 The Weather Channel 7.2M com.weather.Weather 27.9 Bug Rush Free 13M com.fourpixels.td 22.2 Solitaire 8.7M com.mobilityware.solitaire 18.6 Average 5.7 M - 17.3 expect this category of compatibility issues not to be serious because currently not many apps contain native code that has legitimate reasons to directly issue system calls 3. These system calls usually go through the linked system library (libc for example). In fact, we do not find a case during our evaluation that legitimate user native libraries issue system calls directly. Second, our prototype permission manager only supports three coarse responses: allow, deny, and prompt-to-user. It is known that many apps will not fail gracefully when permissions are removed [54, 59]. Issues in this category can generally be remedied by returning mock results, such as a mock location, instead of an error [59, 138]. However, resources such as network are hard to reconcile this way. To test the compatibility of our current prototype, we downloaded 50 popular apps from the Google Play store. Some of the apps we tested are shown in Table 5.4. We first evaluate the compatibility issues caused by the sandboxes by configuring permission manager to always return allow. All the apps can run under AppCage and we have not met any glitches even with exhaustive interactions with the app (the result may not be definitive because we may have missed some code paths). We then evaluate the worst case of compatibility by configuring permission manager to always return deny. Under this stringent setting, some apps can only function partially but can still run. Only two apps crashed during our evaluation: Bug Rush Free and Super-Bright LED Flashlight. They immediately crashed when the access to the network and IMEI was denied, respectively. As aforementioned, the compatibility in this case can be

3Nevertheless, we still need to sandbox native code. Otherwise, malicious apps can easily subvert our system using a native library.

78 Table 5.5 Code size increase

†: sizes in kilobytes before and after instrumentation ‡: percentage of code size increased. ∗: percentage of padding. ]: time in seconds. App Native Library Size† Size† %Inc.‡ %Pad∗ Time] Ebay libredlaser.so 529.2 709.7 34.1 15.9 12.2 AngryBirds libangrybirds.so 1, 283.4 1, 639.8 27.8 16.6 27.7 libjpeg6a.so 213.7 283.5 32.3 12.5 5.4 liblame.so 260.1 347.7 33.7 15.8 5.7 MiBench libmad.so 115.7 147.5 27.5 7.9 2.6 libtiff.so 195.4 257.0 31.5 10.1 5.2 Nbench libnbench.so 82.2 103.3 29.2 13.1 2.2 Average - - - 30.9 13.1 8.7 improved by returning mock results if and when applicable. We also evaluate the compatibility of the dex sandbox on different Android versions. We use five different Android versions, i.e., 2.3.6, 4.0.4, 4.1.2, 4.2.2, 4.3 in our test. Our experiments show that the dex sanbox can tolerant the changes of the Dalvik VM in different versions. We only need to slightly change the offset of the Dalvik VM data structure that needs to be hooked. This is implemented by maintaining a mapping table between the version numbers and the offsets of the Dalvik VM data structure that the dex sandbox are interested. Fortunately, this is a one time effort and the number of interested data structures is small (less than 10).

5.5.4 Performance Evaluation

We also evaluated the overhead introduced by AppCage including its impact to the code size, the installation time and the performance overhead. Code Size: for each target app, AppCage generates a wrapper app that consists of the original app and other components to set up the sandboxes. This adds about 50KB of size to the original app (33KB for the stubs and 18KB for the library). Considering the average size of apps we tested is 5.7MB, the code size increase is less than 1%. There is additional code size increase due to the binary instrumentation for apps with native libraries. Table 5.5 shows the eﬀect of binary instrumentation on the native code of two Android apps (Ebay and Angry Birds) and two benchmarks (MiBench and Nbench). The average increase is around 30%, and 13.1% of it can be contributed to the padding instructions to align code (Section 5.4). Installation Time: AppCage will also increase installation time. For example, it needs to generate a wrapper app and sign it. Table 5.4 shows that the increase to the installation time is about 17 seconds for apps without native code. Moreover, binary rewriting could be time-

79 12,000

Without AppCage With AppCage 10,000

8,000

6,000

4,000 CaffeineMark 3.0 Score

2,000

0 sieve loop logic string float method overall

Figure 5.7 CaffeineMark with and without AppCage consuming for large libraries. For example, AppCage spends about 27 seconds to rewrite the 1.2MB native code of Angry Birds (Table 5.5). Considering that native libraries are normally small and the binary rewriting is performed only once during installation, this increased installation time is acceptable, but maybe frustrating, in the practical deployment. Performance Overhead: We also evaluated the run-time performance overhead introduced by AppCage. For bytecode, AppCage interposes its calls to some framework APIs. We used CaffeineMark, the standard Java benchmark to measure this overhead. The results in Figure 5.7 show that AppCage’s dex sandbox only introduces negligible performance overhead to the bytecode. We obtained the similar results with an evaluation app that intensively invokes the confined framework APIs. Moreover, AppCage needs to communicate with permission manager (see Figure 5.2) to retrieve the policies. To measure the overhead introduced by this operation, we develop an app which continuously retrieves the policy for 10, 000 times. It costs about 3.9 seconds in total for this app to complete. That is, the average time for each policy retrieval is about 0.39 millisecond. We believe this time introduced by AppCage is negligible that users cannot actually perceive it. For native code, AppCage adds instructions to confine memory write and branches. To measure the overhead of native sandbox, we used Nbench [66], a computation-intensive benchmark of the CPU, FPU, and memory system performance. The average overhead of native sandbox is about 10.7% (Figure 5.8). The string sort benchmark has higher performance overhead because it heavily uses the memmove function in libc to move large blocks of data. Libc is built by a

80 30%

25%

20%

15%

10%

−5% Numeric SortString Sort Bitfield Fp EmulationFourier Assigment Idea Huffman Average

Figure 5.8 Normalized overhead of the native sandbox modified NaCl compiler and is the main source of the overhead for this benchmark. This is confirmed by the fact that the overhead will reduce dramatically if the benchmark is linked to a plain libc. This overhead can be reduced (to that of the original NaCl for ARM) if we position the sandbox in the same way as NaCl. This is not feasible unless we can change the default Android loader, a design we avoid for easy deployment. Similar to NaCl, there are three tests in Nbench perform better than the native execution. This is probably due to the caching effects of the code bundles [124].

5.6 Discussion

First, compared to the systems that target the same problem [21, 24, 26, 58, 59, 75, 119, 138], AppCage is a more comprehensive solution with its hybrid sandboxes. The ideal solution is for Google to officially support adjustment of permissions after installation [58]. However, there are two major issues that encumber this solution. First, Android is heavily fragmented with many versions and incompatible customization by major vendors [120]. It is not clear whether and when such update will be deployed to most of the users. In contrast, solutions such as AppCage can be immediately deployed. More importantly, as an official solution, the user would expect it to be compatible with all the apps in Google Play. It is a daunting task to update those millions of apps. It is questionable whether Google will ever deploy such a system (the experimental official permission manager has since been removed in a recent update to Android KitKat 4.4.2 [50].) Users likely have higher tolerance to the incompatibility of third-party solutions.

81 Second, AppCage prompts the user to choose to allow or deny the app’s access to sensitive resources if no policy has been set (Figure 5.3). Compared to the prompt during installation, this in-context prompt is more effective and users are less likely to ignore it. Particularly, the research by Felt et al. shows that only 12% of the participants pay attention to the permission request at installation time [42], while 85% of them denied the location request for at least one app [44]. The system can also be extended to support community-based policy definition [87]. Moreover, the signature of the installed wrapper app is different from the original app, which may break the automatic update feature provided by the Google Play. Our system can monitor the version history of the apps on the Google Play and generate the wrapper app if a newer version is available. Third, our current prototype only supports ARM, the dominate architecture for smartphones and tablets. Intel’s x86 is an emerging architecture for mobile platforms. Our native sandbox can be extended to support x86 using similar techniques. In addition, our prototype does not support self-modify code. We leave it as a future work. Moreover, the indirect branch trampoline temporarily stores the target pc on the stack and branches to it using a pop instruction (Figure 5.6). This introduces a race condition where the target pc could be manipulated by another thread. The race condition can be avoided with an extra scratch register, and instructions to spill and restore the register. It would further complicate the design of the trampoline. However, the window of vulnerability is only four instructions, and the chance of successfully attacking it in practice is low. In fact, this race condition also affects other similar systems [71, 128]. At last, since Android version 5.0, it uses a new runtime (ART) which leverages the ahead of time optimization to convert dex bytecode to a native binary. AppCage could be extended to support the ART runtime since this runtime still has the corresponding data structures to represent the Java classes and methods as the Dalvik VM (Figure 5.1). Accordingly, our system could take similar methods to hook these data structures in the ART runtime (libart.so). We take the ART support as one of the future work.

5.7 Summary

We have presented the design, implementation, and evaluation of AppCage, a system to interpose and regulate third-party Android apps with hybrid user-level sandboxes, dex sandbox and native sandbox. Together, they enable AppCage to securely interpose the app’s access to key APIs and services. Our evaluation shows that AppCage can successfully detect and block the attempts to leak private data or perform dangerous operations by malware and invasive apps.

82 Chapter 6

Conclusion and Future Work

In this dissertation, we first presented a study to understand the overall health of popular app marketplaces in Chapter 3. It showed that there was a clear need for a rigorous vetting process, especially for non-regulated alternative marketplaces. Then to gain a better understanding of Android malware threats, we systematically characterized Android malware from various aspects in Chapter 4. It has provided insights and a comprehensive malware dataset to the research community to help develop more effective defense solutions. At last, in Chapter 5 we further proposed a novel and practical system called AppCage to mitigate Android malware threats. This system is able to thoroughly confine the run-time behavior of third-party Android apps and block the malicious operations. It does not need any framework modifications or the root privilege, thus can be readily deployed. The research in this dissertation has provided a better understanding of Android malware threats and laid a solid foundation towards effective defense towards them. It has also created opportunities for future work. In the following, we propose three possible future directions.

• Building an Advanced Malicious Apps Detection and Analysis platform My previous research involves the development of static analysis systems to detect malicious apps. However, these systems could be thwarted by recent malicious apps using advanced techniques, e.g., complicated code obfuscation or code packer. Dynamic analysis could help, but it could also be bypassed by conditionally triggering malicious payloads. Given the limitations of existing static and dynamic analysis systems, We propose to develop an advanced apps analysis platform which could automatically detect unknown Android malware threats, and analyze their malicious payloads, with little manual eﬀort. The key idea of this system is to thoroughly explore possible program paths inside an app, including the bytecode and the native libraries (if they are used by the app), without

83 the need to feed inputs to the app. Since the app code is dynamically executed, it could deal with the techniques which thwart the static analysis. At the same time, due to the capability of exploring diﬀerent program paths, it could reveal the hidden payloads of malicious apps and maintain a high code coverage.

• Protecting User Data of Sensitive Apps Some apps need to access highly sensitive user data. For instance, online banking apps are processing user-sensitive financial data. However, these sensitive apps run in parallel on the same device alongside other apps from untrusted channels. The large trusted computing base, including the framework and the underlying operating system, may bring threats to sensitive user data. As shown in existing Android malware, malicious apps could exploit vulnerabilities in the framework or underlying operating system to gain the high system privilege, and steal sensitive user data afterwards. We will propose solutions to protect sensitive user data. The first possible solution is to provide an isolated runtime environment for sensitive apps with the ARM TrustZone security extension. An alternative solution is to leverage fault isolation techniques to confine the possible damage, so that even in the case of a compromised operating system, attackers are not able to steal sensitive user data.

• Securing Internet of Things and Interactions with Smartphones The Internet of Things (IoT) is a no longer a technological concept but a reality. Many types of devices are connected to the Internet, including environmental monitoring devices, energy management devices or automobiles with built-in sensors. At the same time, smartphones are becoming the control center of IoT devices. Users use management apps on their smartphones to obtain real-time status of IoT devices or remotely control them. This brings two broad categories of security issues. First, the security of IoT devices, in particular their firmware, needs to be further studied. Potential vulnerabilities in the firmware are exposed to attackers remotely through the Internet. Second, interactions between smartphones and IoT devices bring new attack surfaces. For instance, the management apps used to control IoT devices may be vulnerable or the communication protocols between smartphones and IoT devices may be insecure. We will conduct a systematic study of IoT devices to detect vulnerabilities in the firmware, management apps and the communication protocol. And then we will propose generic solutions to secure IoT devices and their interactions with smartphones.

84 BIBLIOGRAPHY

[1] 1.5 Million Apps are Live on The Google Play Store. http://www.whatech.com/mobile- apps/news/30223-1-5-million-apps-are-live-on-the-google-play-store.

[2] 2014 Mobile Threat Report. https :// www.lookout. com/resources /reports/mobile - threat-report/.

[3] 260,000 Android users infected with malware. http://www.infosecurity-magazine.com/ view/16526/260000-android-users-infected-with-malware/.

[4] adb trickery #2. http://c-skills.blogspot.com/2011/01/adb-trickery-again.html.

[5] AdTOUCH. http://www.adtouchnetwork.com/adtouch/sdk/SDK.html.

[6] Alcatelclub. http://www.alcatelclub.com/.

[7] Amazon Appstore. http://www.amazon.com/mobile-apps/.

[8] An Analysis of the AnserverBot Trojan. http://www.csc.ncsu.edu/faculty/jiang/pubs/ AnserverBot Analysis.pdf.

[9] Android and Security. http : / / googlemobile . blogspot . com / 2012 / 02 / android - and - security.html.

[10] Android Fragmentation Visualized (July 2013). http://opensignal.com/reports/fragmentation- 2013/.

[11] Android Malware Genome Project. http://www.malgenomeproject.org.

[12] Android Security Analysis Challenge: Tampering Dalvik Bytecode During Runtime. https://bluebox.com/technical/android-security-analysis-challenge-tampering-dalvik- bytecode-during-runtime/.

[13] Android.Basebridge Technical Details. http://www.symantec.com/security response/ writeup.jsp?docid=2011-060915-4938-99&tabid=2.

[14] Android.Bgserv Found on Fake Google Security Patch. http://www.symantec.com/ connect/blogs/androidbgserv-found-fake-google-security-patch.

[15] Android.Pjapps Technical Details. http : / / www . symantec . com / security response / writeup.jsp?docid=2011-022303-3344-99&tabid=2.

[16] AnserverBot: Highly Sophisticated Android Trojan Using Public, Encrypted Blog Entries for Command and Control (C&C). http://www.csc.ncsu.edu/faculty/jiang/pubs/ AnserverBot Analysis.pdf.

85 [17] Arzt, S. et al. “FlowDroid: precise context, ﬂow, ﬁeld, object-sensitive and lifecycle- aware taint analysis for Android apps”. Proceedings of the 35th annual ACM SIGPLAN conference on Programming Language Design and Implementation. 2014.

[18] Asroot. http://milw0rm.com/sploits/android-root-20090816.tar.gz.

[19] AVG Mobilation. http://free.avg.com/us-en/antivirus-for-android.tpl-crp.

[20] Backes, M. et al. “AppGuard - Enforcing User Requirements on Android Apps”. Pro- ceedings of 19th International Conference on Tools and Algorithms for the Construction and Analysis of Systems. 2012.

[21] Beresford, A. R. et al. “MockDroid: Trading Privacy for Application Functionality on Smartphones”. Proceedings of the 12th International Workshop on Mobile Computing System and Applications. 2011.

[22] Binder. http://developer.android.com/reference/android/os/Binder.html.

[23] Book, T. et al. “Longitudinal Analysis of Android Ad Library Permissions”. arXiv:1303.0857. 2013.

[24] Bugiel, S. et al. myTunes: Semantically Linked and User-Centric Fine-Grained Privacy Control on Android. Tech. rep. TUD-CS-2012-0226. Center for Advanced Security Re- search Darmstadt, 2012.

[25] Bugiel, S. et al. “Towards Taming Privilege-Escalation Attacks on Android”. Proceedings of the 19th Annual Symposium on Network and Distributed System Security. 2012.

[26] Bugiel, S. et al. “Flexible and Fine-Grained Mandatory Access Control on Android for Diverse Security and Privacy Policies”. Proceedings of the 22nd USENIX Security Symposium. 2013.

[27] Chin, E. et al. “Analyzing Inter-Application Communication in Android”. 9th Annual International Conference on Mobile Systems, Applications, and Services. 2011.

[28] Contagio mobile malware mini dump. http://contagiominidump.blogspot.com/.

[29] Crussell, J. et al. “Attack of the Clones: Detecting Cloned Applications on Android Mar- kets”. Proceedings of the 17th European Symposium on Research in Computer Security. 2012.

[30] Davis, B. et al. “I-ARM-Droid: A Rewriting Framework for In-App Reference Monitors for Android Applications”. Proceedings of the IEEE Mobile Security Technology. 2012.

86 [31] Davis, B. et al. “RetroSkeleton: Retrotting Android Apps”. Proceedings of the 11th International Conference on Mobile Systems, Applications and Services. 2013.

[32] Dietz, M. et al. “QUIRE: Lightweight Provenance for Smart Phone Operating Systems”. Proceedings of the 20th USENIX Security Symposium. 2011.

[33] Distribution of Free and Paid Apps in Android Market. http://www.androlib.com/ appstatsfreepaid.aspx.

[34] Divide. https://www.divide.com.

[35] Droid2. http://c-skills.blogspot.com/2010/08/droid2.html.

[36] DroidKungFu Utilizes an Update Attack. http://www.f-secure.com/weblog/archives/ 00002259.html.

[37] Enck, W. et al. “TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones”. Proceedings of the 9th USENIX Symposium on Operating Systems Design and Implementation. 2010.

[38] Enck, W. et al. “A Study of Android Application Security”. Proceedings of the 20th USENIX Security Symposium. USENIX Security ’11. 2011.

[39] eoeMarket. http://www.eoemarket.com/.

[40] Exploid Root Exploit. http://c-skills.blogspot.com/2010/07/exploid-works-on-droid- x.html.

[41] Felt, A. P. et al. “Permission Re-Delegation: Attacks and Defenses”. Proceedings of the 20th USENIX Security Symposium. 2011.

[42] Felt, A. P. et al. “Android Permissions: User Attention, Comprehension, and Behavior”. Symposium on Usable Privacy and Security. 2012.

[43] First SpyEye Attack on Android Mobile Platform now in the Wild. https : / / www . trusteer.com/blog/ﬁrst-spyeye-attack-android-mobile-platform-now-wild.

[44] Fisher, D. et al. “Short Paper: Location Privacy: User Behavior in the Field”. Proceed- ings of the 2nd Annual ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices. 2012.

[45] Ford, B. et al. “Vx32: Lightweight User-level Sandboxing on the x86”. Proceedings of the USENIX 2008 Annual Technical Conference. 2008.

[46] Fortinet. http://www.fortinet.com/.

87 [47] Gartner Says Annual Smartphone Sales Surpassed Sales of Feature Phones for the First Time in 2013. http://www.gartner.com/newsroom/id/2665715.

[48] Gfan. http://www.gfan.com/.

[49] GGTracker Technical Tear Down. http://blog.mylookout.com/wp-content/uploads/ 2011/06/GGTracker-Teardown Lookout-Mobile-Security.pdf.

[50] Googler: App Ops Was Never Meant For End Users, Used For Internal Testing And Debugging Only. http://www.androidpolice.com/2013/12/11/googler-app-ops-was- never-meant-for-end-users-used-for-internal-testing-and-debugging-only/.

[51] Grace, M. et al. “RiskRanker: Scalable and Accurate Zero-day Android Malware De- tection”. Proceedings of the 10th ACM International Conference on Mobile Systems, Applications and Services. 2012.

[52] Grace, M. et al. “Systematic Detection of Capability Leaks in Stock Android Smart- phones”. Proceedings of the 19th Annual Symposium on Network and Distributed Sys- tem Security. 2012.

[53] Grace, M. et al. “Unsafe Exposure Analysis of Mobile In-App Advertisements”. Pro- ceedings of the 5th ACM Conference on Security and Privacy in Wireless and Mobile Networks. 2012.

[54] Gustafson, E. et al. “Quantifying the Eﬀects of Removing Permissions from Android Applications”. IEEE Mobile Security Technologies. 2013.

[55] Hao, H. et al. “On the Eﬀectiveness of API-Level Access Control Using Bytecode Rewrit- ing in Android”. Proceedings of the 8th ACM Symposium on Information, Computer and Communications Security. 2013.

[56] Hardy, N. “The Confused Deputy: (or why capabilities might have been invented)”. ACM SIGOPS Operating Systems Review 22 (4 1998).

[57] Heuser, S. et al. “ASM: A Programmable Interface for Extending Android Security”. Proceedings of the 23rd USENIX Security Symposium. 2014.

[58] Hidden Permissions Manager Found in Android 4.3, Lets You Set the Rules. http:// www.engadget.com/2013/07/26/hidden-permissions-manager-android-4-3/.

[59] Hornyack, P. et al. “These Aren’t the Droids You’re Looking For”: Retroﬃting Android to Protect Data from Imperious Applications”. Proceedings of the 18th ACM Conference on Computer and Communications Security. 2011.

88 [60] HTC IME Sends All Info to Logcat. http://code.google.com/p/cyanogenmod/issues/ detail?id=445.

[61] Jeon, J. et al. “Dr. Android and Mr. Hide: Fine-grained Permissions in Android Applica- tions ”. Proceedings of 2nd ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices. 2012.

[62] JNI Tips. http://developer.android.com/training/articles/perf-jni.html.

[63] Kiriansky, V. et al. “Secure Execution via Program Shepherding”. Proceedings of the 11th USENIX Security Symposium. 2001.

[64] Klinkoﬀ, P. et al. “Extending .NET Security to Unmanaged Code”. International Journal of Information Security. 2007.

[65] LeNa (Legacy Native) Teardown. http://blog.mylookout.com/wp- content/uploads/ 2011/10/LeNa-Legacy-Native-Teardown Lookout-Mobile-Security1.pdf.

[66] Linux/Unix nbench. http://www.tux.org/∼mayer/linux/bmark.html.

[67] Lookout Mobile Security. https://www.mylookout.com/.

[68] Lu, L. et al. “CHEX: Statically Vetting Android Apps for Component Hijacking Vulner- abilities”. Proceedings of the 19th ACM Conference on Computer and Communications Security. 2012.

[69] Malicious Mobile Threats Report 2010/2011. http://www.juniper.net/us/en/company/ press-center/press-releases/2011/pr 2011 05 10-09 00.html.

[70] Malicious QR Codes Pushing Android Malware. https://www.securelist.com/en/blog/ 208193145/Its time for malicious QR codes.

[71] McCamant, S. et al. “Evaluating SFI for a CISC Architecture”. Proceedings of the 15th USENIX Security Symposium. 2006.

[72] Mmoovv. http://android.mmoovv.com/web/index.html.

[73] Mobile Malware Minidump. http://contagiominidump.blogspot.com/.

[74] Moshchuk, A. et al. “A Crawler-based Study of Spyware on the Web”. Proceedings of the 13th Annual Symposium on Network and Distributed System Security. 2006.

[75] Nauman, M. et al. “Extending Android permission model and enforcement with user- dened runtime constraints”. Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security. 2010.

89 [76] NetQin Mobile Security. http://www.netqin.com/en/.

[77] Number of the Week: at Least 34% of Android Malware Is Stealing Your Data. http: //www.kaspersky.com/about/news/virus/2011/Number of the Week at Least 34 of Android Malware Is Stealing Your Data.

[78] Octeau, D. et al. “Eﬀective Inter-Component Communication Mapping in Android with Epicc: An Essential Step Towards Holistic Security Analysis”. Proceedings of the 22nd USENIX Security Symposium. 2013.

[79] One Year Of Android Malware (Full List). http://paulsparrows.wordpress.com/2011/ 08/11/one-year-of-android-malware-full-list/.

[80] Pandita, R. et al. “WHYPER: Towards Automating Risk Assessment of Mobile Appli- cations”. Proceedings of the 22nd USENIX Security Symposium. 2013.

[81] Payer, M. et al. “Fine-Grained User-Space Security Through Virtualization”. Proceed- ings of the 7th International Conference of Virtual Execution Environments. 2011.

[82] Pearce, P. et al. “AdDroid: Privilege Separation for Applications and Advertisers in Android”. In Proceedings of the 7th ACM Symposium on Information, Computer and Communications Security. 2012.

[83] Peng, H. et al. “Using Probabilistic Generative Models for Ranking Risks of Android Apps”. Proceedings of the 19th ACM Conference on Computer and Communications Security. 2012.

[84] PLT and GOT - the Key to Code Sharing and Dynamic Libraries. https : / / www . technovelty.org/linux/plt-and-got-the-key-to-code-sharing-and-dynamic-libraries.html.

[85] QR code. http://en.wikipedia.org/wiki/QR code.

[86] Rageagainstthecage Root Exploit. http://c-skills.blogspot.com/2010/08/droid2.html.

[87] Rashidi, B. et al. “RecDroid: A Resource Access Permission Control Portal and Recom- mendation Service for Smartphone Users”. Proceedings of the ACM MobiCom workshop on Security and privacy in mobile environments. 2014.

[88] Rastogi, V. et al. “AppsPlayground: Automatic Security Analysis of Smartphone Ap- plications”. Proceedings of the 3rd ACM Conference on Data and Application Security and Privacy. 2013.

[89] Reddy, N. et al. Application-centric security policies on unmodied Android. Tech. rep. Technical Report 110017. UCLA Computer Science Department, 2011.

90 [90] Reina, A. et al. “A System Call-Centric Analysis and Stimulation Technique to Auto- matically Reconstruct Android Malware Behaviors”. Proceedings of the 6th European Workshop on Systems Security. 2013.

[91] Researchers Find Methods for Bypassing Google’s Bouncer Android Security. http:// threatpost.com/researchers-ﬁnd-methods-bypassing-googles-bouncer-android-security- 060412.

[92] Revolutionary - zergRush local root 2.2/2.3. http : / / forum . xda - developers . com / showthread.php?t=1296916.

[93] Russello, G. et al. “FireDroid: Hardening Security in Almost-Stock Android”. Proceed- ings of the 29th Annual Computer Security Applications Conference. 2013.

[94] Security Alert: DroidDream Malware Found in Oﬃcial Android Market. http://blog. mylookout.com/2011/03/security- alert- malware- found- in- oﬃcial- android- market- droiddream/.

[95] Security Alert: Geinimi, Sophisticated New Android Trojan Found in Wild. http://blog. mylookout.com/2010/12/geinimi trojan/.

[96] Security Alert: HongTouTou, New Android Trojan, Found in China. http : / / blog . mylookout.com/2011/02/security- alert- hongtoutou- new- android- trojan- found- in- china/.

[97] Security Alert: Malware Found Targeting Custom ROMs (jSMSHider). http://blog. mylookout . com / 2011 / 06 / security - alert - malware - found - targeting - custom - roms - jsmshider/.

[98] Security Alert: New DroidKungFu Variant – AGAIN! – Found in Alternative Android Markets. http://www.csc.ncsu.edu/faculty/jiang/DroidKungFu3/.

[99] Security Alert: New Sophisticated Android Malware DroidKungFu Found in Alternative Chinese App Markets. http://www.csc.ncsu.edu/faculty/jiang/DroidKungFu.html.

[100] Security Alert: New Stealthy Android Spyware – Plankton – Found in Oﬃcial Android Market. http://www.csc.ncsu.edu/faculty/jiang/Plankton/.

[101] Security Alert: zHash, A Binary that can Root Android Phones, Found in Chinese App Markets and Android Market. http://blog.mylookout.com/2011/03/security- alert- zhash- a- binary- that- can- root- android- phones- found- in- chinese- app- markets- and- android-market/.

91 [102] Security Alert: Zsone Trojan found in Android Market. http://blog.mylookout.com/ 2011/05/security-alert-zsone-trojan-found-in-android-market/.

[103] Security Alerts. http://www.csc.ncsu.edu/faculty/jiang/.

[104] Sehr, D. et al. “Adapting Software Fault Isolation to Contemporary CPU Architectures”. Proceedings of the 19th USENIX Security Symposium. 2010.

[105] Shekhar, S. et al. “Adsplit: Separating smartphone advertising from applications”. In Proceedings of the 22nd USENIX Security Symposium. 2012.

[106] Siefers, J. et al. “Robusta: Taming the Native Beast of the JVM”. Proceedings of the 17th ACM Conference on Computer and Communications Security. 2010.

[107] Spreitzenbarth, M. et al. “Mobile-sandbox: having a deeper look into android applications”. Proceedings of the 28th Annual ACM Symposium on Applied Computing. 2013.

[108] Sun, M. et al. “JVM-Portable Sandboxing of Java’s Native Libraries”. Proceedings of the 17th European Symposium on Research in Computer Security. 2012.

[109] Sun, M. et al. “NativeGuard: Protecting Android Applications from Third-Party Native Libraries”. Proceedings of the 7th ACM Conference on Security and Privacy in Wireless and Mobile Networks. 2014.

[110] Symantec. http://www.symantec.com/.

[111] The Java Virtual Machine Speciﬁcation. http://docs.oracle.com/javase/specs/jvms/ se7/html/.

[112] TrendMicro. http://www.virustotal.com/.

[113] Update: Security Alert: DroidDreamLight, New Malware from the Developers of Droid- Dream. http://blog.mylookout.com/2011/05/security- alert- droiddreamlight- new- malware-from-the-developers-of-droiddream/.

[114] Using QR tags to Attack SmartPhones (Attaging). http://kaoticoneutral.blogspot.com/ 2011/09/using-qr-tags-to-attack-smartphones 10.html.

[115] Wahbe, R. et al. “Eﬃcient Software-based Fault Isolation”. Proceedings of the 14th ACM symposium on Operating systems principles. 1993.

[116] Wang, X. et al. “SigFree: A Signature-free Buﬀer Overﬂow Attack Blocker”. Proceedings of the 15th IEEE Symposium on Security and Privacy. 2006.

92 [117] Wang, Y. et al. “Compac: Enforce Component-Level Access Control in Android”. Pro- ceedings of the 4th ACM Conference on Data and Application Security and Privacy. 2014.

[118] WAPS. http://www.waps.cn/.

[119] Wu, C. et al. “AirBag: Boosting Smartphone Resistance to Malware Infection”. Pro- ceedings of the 21st Network and Distributed System Security Symposium. 2014.

[120] Wu, L. et al. “The Impact of Vendor Customizations on Android Security”. Proceedings of the 20th ACM Conference on Computer and Communications Security. 2013.

[121] Xu, R. et al. “Aurasium: Practical Policy Enforcement for Android Applications”. Pro- ceedings of the 21th USENIX Security Symposium. 2012.

[122] Yan, L.-K. et al. “DroidScope: Seamlessly Reconstructing OS and Dalvik Semantic Views for Dynamic Android Malware Analysis”. Proceedings of the 21st USENIX Security Symposium. 2012.

[123] Yang, Z. et al. “AppIntent: Analyzing Sensitive Data Transmission in Android for Pri- vacy Leakage Detection”. Proceedings of the 20th ACM Conference on Computer and Communications Security. 2013.

[124] Yee, B. et al. “Native Client: A Sandbox for Portable, Untrusted x86 Native Code”. Proceedings of the 30th IEEE Symposium on Security and Privacy. 2009.

[125] Your Apps Are Watching You. http://online.wsj.com/news/articles/SB1000.

[126] yummy yummy, GingerBreak! http://c-skills.blogspot.com/2011/04/yummy-yummy- gingerbreak.html.

[127] ZeuS-in-the-Mobile - Facts and Theories. http :/ / www .securelist. com / en/ analysis / 204792194/ZeuS in the Mobile Facts and Theories.

[128] Zhang, C. et al. “Practical Control Flow Integrity & Randomization for Binary Executa- bles”. Proceedings of the 34th IEEE Symposium on Security and Privacy. 2013.

[129] Zhang, M. et al. “Control-Flow Integrity For COTS Binaries”. Proceedings of the 22rd USENIX Security Symposium. 2013.

[130] Zhang, X. et al. “AFrame: Isolating Advertisements from Mobile Applications in An- droid”. In Proceedings of the 29th Annual Computer Security Applications Conference (ACSAC). 2013.

93 [131] Zhang, Y. et al. “Vetting Undesirable Behaviors in Android Apps with Permission Use Analysis”. Proceedings of the 20th ACM Conference on Computer and Communications Security. 2013.

[132] Zhao, L. et al. “ARMor: Fully Veriﬁed Software Fault Isolation”. Proceedings of the 11th International Conference on Embedded Software. 2011.

[133] Zhou, W. et al. “DroidMOSS: Detecting Repackaged Smartphone Applications in Third- Party Android Marketplaces”. Proceedings of the 2nd ACM Conference on Data and Application Security and Privacy. 2012.

[134] Zhou, W. et al. “AppInk: Watermarking Android Apps for Repackaging Deterrence”. Proceedings of the 8th ACM Symposium on InformAtion, Computer and Communica- tions Security. 2013.

[135] Zhou, W. et al. “Fast, Scalable Detection of ”Piggybacked” Mobile Applications”. Pro- ceedings of the 3rd ACM Conference on Data and Application Security and Privacy. 2013.

[136] Zhou, W. et al. “DIVILAR: Diversifying Intermediate Language for Anti-Repackaging on Android Platform”. Proceedings of the 4th ACM Conference on Data and Application Security and Privacy. 2014.

[137] Zhou, X. et al. “The Peril of Fragmentation: Security Hazards in Android Device Driver Customizations”. Proceedings of the 35th IEEE Symposium on Security and Privacy. 2014.

[138] Zhou, Y. et al. “Taming Information-Stealing Smartphone Applications (on Android)”. Proceedings of the 4th International Conference on Trust and Trustworthy Computing. 2011.

[139] Zhou, Y. et al. “Dissecting Android Malware: Characterization and Evolution”. Pro- ceedings of the 33rd IEEE Symposium on Security and Privacy. 2012.

[140] Zhou, Y. et al. “Detecting Passive Content Leaks and Pollution in Android Applica- tions”. Proceedings of the 20th Network and Distributed System Security Symposium. 2013.

[141] Zhou, Y. et al. “ARMlock: Hardware-based Fault Isolation for ARM ”. Proceedings of the 21st ACM Conference on Computer and Communications Security. 2014.

[142] Zhou, Y. et al. “Owner-centric Protection of Unstructured Data on Smartphones ”. Proceedings of the 7th International Conference on Trust and Trustworthy Computing. 2014.

94 [143] Zimperlich sources. http://c-skills.blogspot.com/2011/02/zimperlich-sources.html.