UNIVERSITY OF CALGARY. Christopher Jarabek A THESIS SUBMITTED TO THE FACULTY OF GRADUATE STUDIES IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE

Transcription

1 UNIVERSITY OF CALGARY Towards cloud-based anti-malware protection for desktop and mobile platforms by Christopher Jarabek A THESIS SUBMITTED TO THE FACULTY OF GRADUATE STUDIES IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE DEPARTMENT OF COMPUTER SCIENCE CALGARY, ALBERTA April, 2012 c Christopher Jarabek 2012

2 UNIVERSITY OF CALGARY FACULTY OF GRADUATE STUDIES The undersigned certify that they have read, and recommend to the Faculty of Graduate Studies for acceptance, a thesis entitled Towards cloud-based anti-malware protection for desktop and mobile platforms submitted by Christopher Jarabek in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE. Supervisor, Dr. John D. Aycock Department of Computer Science Internal Examiner, Dr. Michael E. Locasto Department of Computer Science External Examiner, Dr. Behrouz Far Department of Electrical and Computer Engineering Date

3 Abstract Malware is a persistent and growing problem that threatens the privacy and property of computer users. In recent years, this threat has spread to mobile devices such as smartphones and tablet computers. At the same time, the main method for combating malware, anti-virus software, has grown in size and complexity to the point where the resource demands imposed by these security systems have become increasingly noticeable. In an effort to create a more transparent security system, it is possible to move the scanning of malware from the host computer to a scanning service in the cloud. This relocation could offer the security of conventional host-based scanning, without the resource demands involved with running a fully host-based anti-virus system. This thesis shows that under the right circumstances, malware scanning services provided remotely are capable of replacing host-based anti-malware systems on desktop computers, although such a cloud-based security system is better suited to protecting smartphone users from malicious applications. To that end, a system was developed that provides anti-malware security for desktop computers by making use of pre-existing web-based file scanning services for malware detection. This system was evaluated and found to have variable performance ranging from acceptable to very poor. The desktop scanning system was then augmented and adapted to serve as a mechanism for identifying malicious applications on Android smartphones. The evaluation of this latter system showed favorable results, and is effective as a mechanism for combating the growing mobile malware threat. ii

4 Acknowledgements No man is an island, as such, this body of research would not have been what it is without the help of several individuals. First and foremost, I would like to thank Dr. John Aycock for his guidance and advice during my studies. His open and approachable nature made him a pleasure to work with, and this research would not have reached its full potential without his direction. I would like to express my gratitude to Dr. Michael Locasto and Dr. Behrouz Far, for serving on my examination committee. I would also like to thank Dr. William Enck and Dave Barrera for their advice regarding Android development, as well as Erika Chin and Adrienne Porter Felt for their assistance with tools for data analysis. Special thanks should also be given to my student colleagues, Daniel De Castro and Jonathan Gallagher for offering up their company and enjoyable discussions. Finally, I would like to thank my family: Chelsey Greene and Patricia and Jim Jarabek. However, words alone are insufficient to show the scale of my gratitude for the love, encouragement, and support they have shown me. iii

5 iv Table of Contents Abstract ii Acknowledgements iii Table of Contents iv List of Tables vi List of Figures vii List of Abbreviations viii 1 Introduction Background The Malware Threat The Cloud Smartphones Mobile Malware Android Thesis Contributions Thesis Outline Related Work Mobile Security and Malware Cloud Based Anti-Malware Device Based Mobile Anti-Malware Non-Device Based Mobile Anti-Malware Other Lightweight Anti-Virus Techniques Summary System Architecture Scanning Services Kaspersky VirusChief VirusTotal Other Services Terms of Service Desktop Thin AV System DazukoFS File System Access Controller Standalone Runner Thin AV Scanning Modules System Circumvention Mobile Thin AV System Reuse of Existing Thin AV System Android Specific Scanner Safe Installer Killswitch

6 3.3.5 System Circumvention System Evaluation - Desktop Thin AV Scanning Service Performance Testing Protocol Results Discussion Actual System Overhead Testing Protocol Results Discussion Predicted System Overhead Testing Protocol Results Discussion Large Scale System Simulations Testing Protocol Results Discussion System Evaluation - Mobile Thin AV Data Set Malware Detection Emulator Performance ComDroid Evaluation Testing Protocol Results Discussion Safe Installer Performance Killswitch Cost Testing Protocol Results Discussion Discussion Thin AV Performance and Feasibility Ideal Deployment Desktop Deployment Mobile Deployment Privacy Desktop Privacy Mobile Privacy Conclusion Bibliography A Appendix v

7 List of Tables 3.1 Thin AV security policy matrix Speed comparison of the hashing functions available in Python Kaspersky file scanning performance statistics VirusChief file scanning performance statistics VirusTotal file scanning performance statistics VirusTotal file upload performance statistics Linear equations for the three scanning services Activities in the web and advanced workload scripts Scenarios examined for assessing Thin AV overhead General characteristics of testing workload scripts Time to complete the three workload testing scripts while using Thin AV Refined linear equations for each of the three scanning services Simulation results of the Kaspersky service for three different activity logs Simulation results of the VirusChief service for three different activity logs Comparison of running time and simulation results for Kaspersky service Comparison of running time and simulation results for VirusChief service General file size characteristics of the Android test data set Summary of malware found in the Google Market data set Android emulator versus hardware performance comparison Linear equation for the ComDroid scanning service Summary of exposed communication in Google Market data set Network speeds used for evaluating the mobile implementation of Thin AV Thin AV safe installer cached performance summary Thin AV safe installer uncached performance summary Linear equations for generating a system fingerprint Data consumption of Thin AV killswitch over different time periods Fingerprint generation time for different conditions Total upload sizes used for calculations of bulk scanning performance Thin AV killswitch app upload times Scan times for different numbers of apps A.1 Raw data from Figure A.2 Raw data from Figure A.3 Raw data from Figures 4.8 and A.4 Raw data from Figure A.5 Raw data from Figure A.6 File size characteristics of Android testing data set vi

8 List of Figures 3.1 System architecture for Thin AV UML Class Diagram for Thin AV System architecture diagram for the mobile implementation of Thin AV User interfaces for the Android killswitch Scan response time for the Kaspersky scanning service Scan response time for the VirusChief scanning service Scan response time for the VirusTotal scanning service Upload response time for the VirusTotal scanning service Example CDF of simulated files by size Accesses which involved an uncached file versus Thin AV induced overhead Number of file system accesses versus Thin AV induced overhead File size in bytes versus Thin AV induced overhead File size versus the proportion of accesses scanned by each scanning service Proportion of file modifications versus Thin AV induced overhead Average time between file accesses versus Thin AV overhead Median file size of the Android test data set by category Reponse time of the ComDroid service as a function of package size Fingerprint generation time versus the number and size of packages vii

9 List of Abbreviations AIDL AJAX API APK ARM ARP AV CPU DLL DNS FFBF FSAC HTML HTTP(S) IP IPC LOC OS RAM RISC VM WEP XML Android Interface Definition Language Asynchronous JavaScript and XML Application Programming Interface Android Application Package File Advanced RISC Machine Address Resolution Protocol Anti-Virus Central Processing Unit Dynamic-Link Library Domain Name System Feed-Forward Bloom Filter File System Access Controller HyperText Markup Language Hypertext Transfer Protocol (Secure) Internet Protocol Inter-Process Communication Lines of Code Operating System Random Access Memory Reduced Instruction Set Computer Virtual Machine Wired Equivalent Privacy Extensible Markup Language viii

10 1 Chapter 1 Introduction Computer malware (malicious software) is a persistent and evolving threat to the privacy and property of individuals and organizations. With software systems growing in complexity every year the potential exploits of these systems are growing in kind. The most common technique for identifying and removing malware from computers is anti-virus software. However, anti-virus products that run on end-user computers have become increasingly bloated in recent years, as developers push to include features that will serve to differentiate their product in a competitive marketplace. This software bloat has a negative impact on the performance of computer systems and on users willingness to use anti-virus products to protect their computer systems. Recently, an idea has started developing which would see security offered as a cloud-based service. Although there are a variety of factors motivating the development of cloud-based security, from a customer s perspective this shift towards cloud-based security ultimately means that the products that are currently used to ensure access, confidentiality, and integrity of both data and computer systems can be replaced with a cloud-based service. Such services are already being employed by security companies seeking to enhance their existing host-based antivirus software with cloud-based features [46]. This thesis aims to show that under the right circumstances, malware scanning services provided remotely are capable of replacing host-based anti-malware systems on desktop computers, although such a cloud-based security system is better suited to protecting smartphone users from malicious applications. The evidence to support this thesis comes from the development and evaluation of Thin AV: a light-weight, cloudbased anti-malware system that was implemented for both Linux desktops and Android

11 2 smartphones. The remainder of this chapter is laid out as follows: Section 1.1 will broadly cover the background for the main concepts relevant to this thesis. Next, Section 1.2 will detail the exact contributions made by this thesis. Finally, Section 1.3 will describe the contents of the remainder of this document. 1.1 Background This thesis ties together a variety of different topics, including malware (of both the mobile and non-mobile varieties), cloud computing, and smartphone security. Whereas Chapter 2 will discuss a wide range of academic research relating these issues, this section is intended to serve as a general introduction to the relevant topics, and provide the context for the rest of the work contained within this thesis. The remainder of this section is outlined as follows: Section will discuss malware and the threat it poses; Section will talk about the concept of cloud computing; and finally, Section will discuss smartphones, with a special focus on mobile and smartphone malware as well as a discussion on the Android smartphone operating system The Malware Threat Malware is, in the broadest sense, a computer program that is designed to compromise, damage, exploit, or harm a computer system or the data residing on it [31]. While the term virus has become somewhat synonymous with malware, this is incorrect, as computer viruses constitute only a single type of malware. Malware refers to all varieties of malicious computer programs, which are typically categorized based on the specific malicious properties the program exhibits. In recent years the creation of new malware has seen tremendous growth [50], and while malware is created for a variety of reasons, the most prevalent incentive is financial gain [53].

12 3 The most common approach to combating malware is through anti-virus programs. These are programs that examine the files on a computer and locate files that look or behave like known malware samples [31]. While there are numerous companies that sell anti-virus products, and even a few anti-virus products that are given away for free, most of these products are fairly comparable at their ability to detect malware [82], at least when it comes to detecting malware that is currently circulating in the wild [106]. This has led to a scenario where companies have to continually add new features to their antivirus products in order to stand out in a crowded market place. And while these features may have some security benefit, there is almost always an associated performance cost [105] The Cloud New trends are emerging in computing that may offer a new direction in the fight against malware. Among these trends is the recent emergence of cloud computing. Cloud computing is not so much a new technology, as it is a new business model for computing. Cloud computing is the delivery of computation services as opposed to computation products. These services are typically delivered over a network such as the internet [78] 1. Amajormotivatingfactorbehindtheadoptionofcloudcomputingisthepotential for cost savings [63]. For example, rather than a company providing to their employees through their own local server, they could pay a subscription fee to acompanythatprovides servicesovertheinternet. Thisservicearrangement saves the company the cost of buying, maintaining, and administering their own server. The procurement, maintenance and potentially the administration of these cloud servers is not the responsibility of the company, but rather the responsibility of the service provider. While the geographic location of the cloud servers is controlled by 1 The term cloud came about because historically a cloud shape is used to represent the internet in network topology diagrams [101].

13 4 the service provider, the location is very much a point of interest to customers, as the location of a service provider s cloud servers can significantly impact the performance of the service, as well as pose significant legal concerns for cloud customers [30]. The concept of cloud computing has its roots in the mainframe computers of a previous generation, but the technology to actually implement cloud computing really began to take shape when grid computing and operating system virtualization started seeing widespread successful applications. The success of these underlying technologies, coupled with a steady increase in the speed of internet connectivity around the globe, eventually allowed for computation services to be delivered over the internet [65, 52]. The notion of providing computation as a service can be broken down into a number of different service categories. Among the most common service offerings are Infrastructureas-a-Service, where a company will offer shared hardware resources, Platform-as-a-Service, for developing and deploying applications, and Application-as-a-Service, which is similar to the example above [78]. The notion of offering Security-as-a-Service is a relatively new concept [29], yet the security company McAfee is already offering a cloudbased enterprise security service that includes malware protection [26], though the details pertaining to the architecture of this proprietary system are not publicly available Smartphones Smartphones are fundamentally just mobile phones with some sort of personal computing functionality. This functionality typically includes the ability to run custom software or applications, on top of purpose-built operating systems. It is somewhat difficult to specify the point at which mobile phones started widely being referred to as smartphones, as their development was simply the result of continual product evolution. However, it is safe to say that the variety of touch screen devices ushered in by Apple s iphone, and later, Google s Android devices, can be classified as smartphones. The growth of smartphones

14 5 sales has been extremely high, with smartphone sales reaching more than 115 million devices in the third-quarter of 2011 [64] Mobile Malware Mobile malware is malware that has been written for a mobile device such as a tablet computer or a mobile phone. The problem of mobile malware has been around for more than a decade. Even in the pre-smartphone era there was considerable speculation as to when malware on mobile phones would become commonplace, and what the capabilities of said malware would be when it arrived [49]. As an emerging platform for malware, there were many factors that dictated when malware authors would be sufficiently motivated to begin writing mobile malware in earnest [85]. However, the tremendous increase in smartphone use [64], coupled with the fact that smartphones increasingly store large amounts of personal or private information, has been enough to push mobile malware from a curiosity to a full fledged industry. In recent years the growth of mobile malware has been dramatic, with F-Secure reporting a nearly 400% increase in mobile malware between 2005 and 2007 [66], and McAfee Labs recording a doubling of mobile malware samples between the beginning of 2009 and the middle of Much like desktop malware, mobile malware ranges from mildly annoying to extremely insidious, and all major platforms have been affected [77, 71, 33, 32, 57, 100]. Combating malware is not trivial on high-resource desktop computers, and the resource constraints present on mobile devices only increases the challenge of this task. It is not simply that the processing and storage capacity of a mobile device is less than a contemporary desktop computer, but it is the fact that the uptime of the device is limited by the available battery power. Thus, excessive computation caused either by malware or anti-malware code running on the device will shorten the battery life, and decrease the usefulness of the device [37].

15 Android Given that a large portion of this research uses the Android operating system, it is worth discussing Android, as well as the Android security model and some of the issues around Android security. (For the remainder of this section, unless otherwise stated, please refer to [2] for details pertaining to the Android operating system.) The selection of Android as the platform for this study was based on a variety of factors. When comparing the top smartphone operating systems (Android, ios, Windows Phone, Symbian and Blackberry OS), Android is the only mainstream operating system which is open-source, allowing for modification of the operating system. This, coupled with the rise of Android as a smartphone platform made it the obvious choice [64]. Android is middle-ware developed by Google and built on top of Linux. It is targeted at mobile devices such as smartphones, tablets and e-readers. Like many mobile operating systems, Android has been designed to provide developers with a rich environment in which to develop applications (or apps ) that leverage the available physical hardware. Android apps are written in Java, but are not executed on a traditional Java Virtual Machine. Rather, Android includes a high performance, mobile-specific VM called the Dalvik Virtual Machine that executes the compiled Android bytecode. In order to create a secure operating environment, Android implements a high degree of process isolation between apps. When an app is launched, a new process is created for that app, owned by a user ID unique to that app. Within this process, a new Dalvik VM is launched, within which the desired app is run. This process isolation, in conjunction with Google s design philosophy of all apps are created equal, is highly beneficial from a security perspective. It means that flaws or exploits in a given app cannot easily result in access to restricted data, processes or services. For example, a successful buffer overflow attack on a particular app would only provide access to the files and process owned by the compromised app [58], as well as any other public files present on the file system.

16 7 Another key component of the Android security system is the permissions model which, broadly speaking, defines what portion of the Android API a given app has access to, and what actions an app can perform when interacting with another app on the device [54, 59]. For example, at install time, an application could declare that it requires access to the internet and the ability to receive SMS messages. Before proceeding with the installation, the user must approve these permission requests. However, an application could potentially request a set of permissions that would allow for malicious behavior, such as creating an application to monitor phone conversations, or track a user s location without their knowledge [56]. This permissions model is further complicated by the addition of the inter-process communication model which provides a mechanism for passing messages and data between applications, or from the operating system to an app on the device. These messages are referred to as intents, and these intents can be explicit (app A sends a message to app BandonlyappB)orimplicit(appAsendsamessagetoanyappwhichsupportsthe desired operation). Unfortunately, both explicit and implicit intents allow for a scenario where an app can spoof an intent, in an attempt to gain information from the target app. Additionally, the latter case creates a scenario where an intent can be intercepted by a malicious app, bypassing its intended target [45]. In light of the process isolation enforced by Android, it is becoming increasingly likely that malware in the conventional sense is being eclipsed by the issue of malicious apps which are unwittingly installed by a user [55]. These can be applications that ask for a specific collection of permissions that could enable malicious behavior [56] or applications which abuse Android s message passing system for malicious purposes [45]. Apps for Android can be distributed in a variety of ways. The most common way is via an application market. A market is simply an app that runs on a device and allows a user to find and install other apps. The feature that differentiates the Android

17 8 Market 2 model from other market models (most notably, the Apple App Store), is the fact that developer submissions to the Android marketplace are relatively unregulated. Submissions do not go through any sort of rigorous quality control checks. Specifically, apps are not manually reviewed for quality and content prior to release, a hallmark of the Apple App Store [42, 97]. While on one hand, Google s marketplace model provides developers with the ability to quickly take an app from development to deployment, it also means that developers of malicious apps have fewer obstacles to overcome when trying to quickly publish their apps to a wide audience. In order to combat this, both the Google and Apple markets contain a remote killswitch that allows not only for the removal of an app from their market, but also the remote removal of the app from a user s device [76]. Additionally, Google has potentially staked the reputation of their brand on their Market, and so has a vested interest in preventing it from becoming filled with malicious apps. Therefore, it is not surprising, given their more permissive market model, that Google has had to actually use their killswitch to remove malicious apps [40]. Furthermore, Google has very recently announced that due to the spate of malware on their market, they have developed their own internal anti-malware scanning system called Bouncer, which performs automated scanning of apps submitted to the market [73]. Android s market model is further complicated by the fact that a user does not need to use the Android Market to install apps. Android allows the installation of apps downloaded from the web, attached in an , transferred via USB from another computer, or downloaded from any number of the third-party app stores that are available for Android. McDaniel and Enck provide a brief discussion of some of the security challenges presented in such a multi-market environment [76], arguing that markets by 2 As of March 6, 2012 Google has grouped the Android market together with a number of their other commercial services creating a new service called Google Play [91]. Any future references to the Google Market or the Android Market, refer specifically to the market for Android apps that is now part of Google Play.

18 9 themselves do not fail at security, because markets don t claim to provide security. Rather the onus is on the users to make informed decisions about what apps they install. To that end, it is suggested that what Android needs is a level of automated application certification in Android s multi-market ecosystem. Thin AV, the system described in this thesis, is intended to be a step towards this goal. While the official Android Market comes with a built-in killswitch for the removal of malicious apps, the only other high-profile Android market, the Amazon App Store, does not [43]. Then there are the numerous other, less well known Android application markets, some of which are targeted at specific geographic regions [10, 15], others that are targeted at specific hardware platforms [4], while others still are targeted to individuals with more salacious tastes [14]. There is even a market under development that focuses specifically providing apps that have been banned by the official Google Market [87]. As the number of third-party app stores increases, it is likely that some of these markets will be more interested in the quantity of apps available for download, than the quality of those applications. It is possible that these unofficial application markets will become significant vectors for malicious applications in the years to come. The mobile anti-malware system, Thin AV, which is described in Section 3, is a step in combating this malware vector. By combining an install-time application check with a marketindependent killswitch capable of notifying users of malicious apps regardless of their source, it is possible that these non-google Market sources can be made safer for mobile users. 1.2 Thesis Contributions The first main contribution of this research is the design and development of Thin AV, asystemforprovidinganti-virusscanningforlinux-baseddesktopcomputers.thinav

19 10 combines a set of pre-existing, third-party scanning services and offloads the scanning of files from the host computer to these services. The evaluation of Thin AV found that performance of the system was highly dependent on the file system activity while the system was active, but that there were specific instances where the system performed well. The findings from this research can help to address the performance concerns involved in cloud-based malware scanning. This could result in a system that would be capable of performing nearly transparent anti-malware protection from the cloud. The second contribution of this thesis was an extension of the desktop version of Thin AV, specifically targeted at smartphones and other mobile devices. The system was designed and developed for the Android operating system, and the evaluation of the system showed favorable performance, suggesting that cloud-based anti-malware scanning may be a very good fit for providing a level of security to mobile devices. Finally, this research includes a comprehensive examination and summary of the current body of academic research pertaining to cloud-based security for both desktop computers and mobile devices, as well as research regarding low-impact anti-malware techniques which might also be suitable for mobile devices. 1.3 Thesis Outline This thesis is divided into chapters as follows: Chapter 2 will examine the existing research in the related fields of mobile malware, cloud based-anti-malware, as well as research into other lightweight anti-malware systems. Chapter 3 will introduce Thin AV, the system at the centre of this thesis, with a significant focus on the design and implementation of both the desktop and mobile versions of Thin AV. Chapter 4 will focus on the evaluation of the desktop version of Thin AV, while Chapter 5 will deal with the evaluation of the mobile version. Chapter 6 will discuss the results of the evaluation as

20 11 well as the areas in which Thin AV could be improved, giving specific attention to the privacy implications of Thin AV. Chapter 7 will conclude this thesis.

21 12 Chapter 2 Related Work Most of the research related to Thin AV can be grouped into one of three categories: security and malware in mobile environments, which will be discussed in Section 2.1, cloud based anti-virus systems, which will be discussed in Section 2.2, and mobile antivirus systems, which are reviewed in Section 2.3. Section 2.4 contains a review of related research that can be found in the overlap between these research areas. Section 2.5 will discuss and critique the work that is relevant to Thin AV, but cannot be clearly classified into any of these previous areas. Finally, Section 2.6 will conclude this chapter. 2.1 Mobile Security and Malware The problem of mobile malware has been around for more than a decade. In that time, the nature of the malware threat has shifted significantly. In the pre-smartphone era, most malware came in the form of viruses or Trojan horses [66], while in recent years most malware comes in the form of malicious applications [60]. However, Bickford et al. have shown the possibility of developing rootkits for a modern smartphone, though their work did not focus on a well known smartphone operating system [38]. Additionally, [95] showed that smartphones are susceptible to more traditional denial of service attacks due to their lack of firewalls. The same study also raised the possibility of using smartphones as offensive platforms, though this is less promising due to their limited power. Porter Felt et al. conducted a survey of malware found in the wild on Android, ios and Symbian devices [60]. Their survey found that all instances of malware for Android devices used application packages as their vector, meaning that users were un-knowingly

22 13 installing the malware on their device. Interestingly, the only instances of malware on the iphone occurred through an SSH exploit in rooted (or jailbroken ) devices. The study went on to examine the incentives behind each piece of malware, most of which were financially based, and outlined a series of practical changes to each of the mobile platforms to help curb those incentives. Given the current glut of mobile malware, and the rate at which smartphones are being adopted, it is clear that mobile security has become a pressing issue. Oberheide et al. provide an overview of security issues in mobile environments [83]. They point out that previous approaches to mobile security are either overly entrenched in desktop security practices, or argue for entirely new paradigms. Oberheide et al. suggest the truth lies somewhere in between. They discuss five issues that cause security on mobile platforms to be subtly different than in non-mobile environments: resource constraints, different attack strategies, different hardware architectures, platform/network obscurity, and usability. Enck et al. performed a review of Android application security by developing a tool for reverse engineering Java code from the compiled Android byte code, then performing static analysis [55]. The top 1,100 apps from the Android market were downloaded and analyzed for a host of security flaws and poor programming practices. Enck et al. found a pervasive misuse of personally identifying information such as phone identifiers and location information, as well as evidence of poor programming practices such as the writing of sensitive data to Android s public centralized log. Fortunately, no evidence was found of exploits in the Android framework, or the presence of malware in the collection of analyzed apps. However, given that the apps selected for study were the top apps in the Android market place, this likely resulted in a bias towards higher quality code than might be found in a broader cross-section of apps. Chin et al. performed a study of Android inter-process communication (IPC) that is

23 14 complementary to the analysis in Enck et al. [45]. Using ComDroid, a custom static code analysis tool, one hundred of the top Android applications in the Android Marketplace were examined for vulnerabilities in how they sent and received IPC messages (intents). Numerous vulnerabilities were identified, as well as several instances of misuse of the Android framework. These findings motivated a collection of programming best-practice guidelines for Android programmers. The same 1,100 apps from [55] were also studied by Barrera et al. with the goal of understanding how the Android permission model is used in practice [35]. The study found that the use of Android permissions showed a distinctly heavy tailed distribution, with some permissions being employed in most apps (e.g., access to the internet) while most other permissions were comparatively rare. Ultimately, it was concluded that the Android permissions model could be improved by sub-dividing certain broad permissions (e.g., internet access) to provide a more expressive model, while at the same time rarely used permissions with related functionality could be grouped together (e.g., install / uninstall applications). The findings of Barrera et al. are also in keeping with those of Ongtang et al. [86]. Here, various elements of the Android permissions model were enhanced and modified to accommodate a richer, more expressive set of permissions. The Android permissions model was also examined by Felt et al. when they examined the issue of overprivilege in applications [59]. By mapping the Android API, it was possible to determine which API calls required which permissions. Using this permissions map they were able to build a tool, Stowaway, to examine several hundred Android applications, finding that almost a third of Android applications over-request permissions. Additionally they found several that the Android permissions model is severely underdocumented, and in some cases, incorrectly documented.

24 Cloud Based Anti-Malware The notion of cloud-based malware scanning was first posited in [81], addressed at length in [82], and was a significant source of inspiration for the creation of Thin AV. The system described by Oberheide et al. is called CloudAV. It involves running a local cloud service consisting of twelve parallel VMs, ten of which run different anti-virus engines, and two running behavioral detection engines. End hosts run a lightweight client (300 LOC in Linux, and 1200 LOC in Windows) which tracks and suspends file access requests, until the file has been scanned. The use of several heterogeneous scanning engines dramatically improved threat detection, with Oberheide et al. claiming a 98% detection rate when testing with the Ann Arbour Malware Library. Such a high detection rate does increase the risk of false positives. However, it was found that by requiring at least four of the scanning engines to flag a file as malware, false positives could be eliminated, while the overall detection rate only dropped by 4%. Given that CloudAV was deployed with dedicated scanning servers in a LAN environment, the performance impediment from network latency and system load is minimal. This results in an average file scan time of just over one second. This process is sped up through the use of caching, which was shown to be highly effective, producing a 99.8% hit rate with a primed cache. The performance of Thin AV could give an indication as to how such a remote scanning system like CloudAV would perform over a WAN, where network latency can be significant. Following their success on the desktop, Oberheide et al. applied their strategy to a mobile environment [84]. Their results showed a marked reduction in power consumption and improved malware coverage. However, they failed to provide any information on how fast their solution operated in the lower-bandwidth / higher-latency mobile realm. Conversely, in their examination of the trade-offs between energy consumption and security,

25 16 Bickford et al. showed that cloud-based anti-malware scanning is more energy intensive than host-based scanning when performed on a mobile device capable of running a VM hypervisor [37]. Although, it should be noted that the latter study was an examination of cloud-based rootkit detection, not virus detection, and both implementations differed greatly. Therefore, the latter is not necessarily a refutation of the results of Oberheide et al. A novel extension to cloud-based malware scanning was provided by Martignoni et al. [75]. They implemented a system wherein suspect executables are uploaded to a cloud-based analysis engine. The system executes the malware, intercepting the system calls generated by the execution, and where necessary, passing those system calls back to the original host. The rationale behind the approach is that most malware behaviorbased detection engines are based on running malware samples in a highly synthetic environment. Yet often, the malicious characteristics of a piece of code are only triggered by a very specific processing environment on the target machine (e.g., visiting a specific banking web site). Like Thin AV, this approach reduces the user s risk of infection, but this approach provides the scanning service with a much more diverse set of computing environments in which to test potentially malicious code, thus improving coverage when seeking malicious behavior in a piece of code. Such a system, implemented in a VM, would make a compelling addition to other cloud-based anti-malware systems such as Thin AV or CloudAV. Jakobsson and Juels described a strategy for malware scanning that also relies on external computing resources [70]. Their technique allows trusted servers to audit the activity logs of remote clients in an effort to establish the security posture of the clients. The trusted servers, in most cases, would be owned and operated by institutions susceptible to malware-based fraud, such as banks. A client-based agent would be responsible for logging activity on the client such as file downloads and installations. This log file

26 17 could then be sent to the trusted server which would then allow the server to decide whether or not to proceed with the transaction with that particular client. Jakobsson and Jules claim their technique is secure against log tampering because any events that could result in a malware infection occur only after the event in question has been logged, and the log has been locked. However, they do not address the case where their agent software would be installed on an already compromised machine. Because only logs are being processed, this technique is well suited to low powered mobile environments, where bandwidth is limited. Additionally, because logs and not entire files are being transmitted, the privacy concerns are somewhat less than those presented by Thin AV, where whole files are transmitted. Clone Cloud [47] and MAUI [48] are both systems designed to enhance the processing capabilities of smartphones by offloading intensive processing to highly resourced cloudbased servers. The designers of Clone Cloud were the first to envision a system capable of offloading smartphone malware scanning on to more powerful cloud-based hardware. However, the ability to perform intensive malware scans was posited as only one of many possible applications of their approach. Although, it should be noted that the notion of moving intensive processing from mobile devices on to more powerful servers predates Clone Cloud by many years [94, 61], yet Clone Cloud is the first system to apply this practice to modern smartphones, and the first to consider the potential security applications of such an approach. Paranoid Android is an implementation of a cloud-based anti-malware system which follows very closely on the heels of Clone Cloud [89]. The technique involves replicating an entire mobile device in a virtualized server-based environment. System calls on the physical device are recorded, and transmitted to the server where the user s behavior is replicated. This allows the server to maintain a faithful copy of the user s device most of the time (barring network disruptions). This server-based replica can be scanned using

27 18 traditional CPU intensive techniques that would not be feasible on a mobile device. A major upside of this approach is that once a replica has been established on a server, the amount of traffic necessary to maintain a consistent state is quite small. The obvious downside, like CloudAV and others, is the privacy concerns involved in replicating a device which very likely contains personal information. However, such a solution would be ideal in a highly-managed corporate environment where worker privacy on company provided devices is not a given. Finally, private security company BitDefender also developed a cloud-based antimalware product [46]. In their solution they suggest that only the signature based scanning portion of the malware-scan should be offloaded to the cloud. Their reasoning behind this is that more than 90% of the size of BitDefender is composed of the static signature based scanning engine. Therefore, if the less intensive operations such as heuristic scanning remain on the client, and signature-based scanning is done remotely, then network traffic can be kept to a minimum. For privacy reasons, they also opt to have users only upload cryptographic hashes of their files for analysis, only uploading the whole file in the event that a hash cannot be matched. This is very similar to the approach used by Thin AV which will be discussed in Chapter Device Based Mobile Anti-Malware There are a host of anti-malware systems which are designed to run on resource constrained mobile devices. VirusMeter is a proposed approach for general malware detection in a mobile environment [72]. The approach involves detecting malware by monitoring battery consumption. The assumption is that if the battery consumption of benign behavior can be adequately modeled, then deviations from that model will suggest the presence of unauthorized code. The key issue with their approach is that even the best

28 19 case scenario has more than a 4% false-positive rate. This is high for a malware scanner. More importantly, their system was prototyped on a comparatively old mobile device, and it is unclear if their approach would work effectively on a modern smartphone which typically runs a diverse collection of rich media applications capable of quickly draining adevice sbattery. Heuristic based anti-malware scanning is conducive to mobile platforms simply due to its reduced overhead. The approach in [102] identifies malware based on the pattern of DLL usage in a program. Venugopal et al. observed that many malware programs share similar behaviors, and these behaviors are accessed through DLLs. Furthermore, the spreading mechanisms and targeted exploits of viruses in the mobile domain are different than those in the desktop domain, so the heuristic methods from the latter domain cannot be applied to the former. By developing a heuristic system and training it on a collection of Symbian viruses, they were able to successfully identify 95% of other (nontraining set) Symbian malware, with no false positives. Much like VirusMeter, the most obvious problem with this solution is that it was developed in a pre-smartphone world. Smartphones typically now run a diverse, customized collection of mobile applications. In asoftwareenvironmentwherenewapplicationswithnovelfunctionalityarebeingreleased on a daily basis, it raises questions about the efficacy of such a heuristic technique, or at the very least, about the rate of false positives in such an environment. A similar strategy for malware identification on Android-based mobile devices can be found in [98]. The strategy involves using Linux-based tools to analyze the low-level function calls of ELF files. They then use various heuristic techniques to classify a file as malicious or clean depending on the functions being called. They also suggested a technique for combating infection by having co-located mobile devices collaborate to identify malware. Prior to their work on Android, Schmidt et al. developed a technique for instrumenting Symbian and Windows Mobile devices with the intention of recording