|
|
Design and Implementation of an Android Host-based
Intrusion Prevention System
1. INTRODUCTION
We now live in a mobile digital era and smartphones are becoming indispensable as they are being used as personal communication and computing devices. Unfortunately, smartphones are also becoming hackers’ biggest target [44]. Android is an open source operating system for mobile devices. Its market share has reached around 80 percent of all smartphone shipments in the second quarter of 2013 [35]. Due to its large market share, it becomes the major target for hackers. A recent report [26] indicated that 97 percent of these threats targeted Android devices. Furthormore McAfee [39] showed that 17,000 new Android malware were found in the second quarter of 2013. All these indicate that Android devices are facing an explosive growth of malware threat.
Part of this work was done during his internship at Qihoo 360.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Permissions@acm.org.
ACSAC ’14, December 08–12 2014, New Orleans, LA, USA
Copyright is held by the owner/author(s). Publication rights licensed to ACM.
ACM 978-1-4503-3005-3/14/12 ...$15.00
http://dx.doi.org/10.1145/2664243.2664245
Permission mechanism is the primary security protection in Android. When an Android user installs a mobile application (app for short), the system will alert the user about the required permissions of that app. But this mechanism does not provide an adequate level of security. As shown in [28, 31, 38, 16], there are plenty of Android permission abuses. Due to the working mechanism and the open source nature of Android system, it is easy to write malware variants which can bypass the detection of anti-virus software.Recently, researchers [59, 48] have shown that some of the existing anti-virus software cannot effectively detect malware variants which were generated by simple transformations. Most of the existing anti-virus engines are using static analysis and malware signatures [62, 32] for detection. To make up for the limitations of static analysis, several systems [24, 55, 8] aim to detect the runtime behaviors by using dynamic analysis. However, these systems are mainly for post-mortem analysis and with a high likelihood, the malware under investigation may have already infected many devices. Furthermore, for these dynamic analysis systems, how to automatically trigger the malicious behaviors is still an ongoing research problem [58, 47]. Therefore, the security community has been advocating the use of a host-based intrusion prevention system (HIPS), which is an installed software on a mobile device to monitor suspicious activities, and to block and report malicious behaviors by analyzing events at realtime. HIPS can be installed on mobile devices to provide protection against apps which have runtime malicious behaviors. HIPS can also dynamically intercept the apps at runtime and notify users when the malware invoke some dangerous application program interfaces (APIs). In fact, the use of HIPS is gaining popularity and has been implemented in products like Jinshan Mobile Duba [9], LBE [10], 360 Mobile Safe [13], etc.
In general, there are three approaches to implement HIPS in Android, they are: (1) system patching, (2) application repackaging and (3) API hooking. System patching is to modify the Android operating system with new permission management functions. Application repackaging is to disassemble a mobile app, add new policy enforcement to it, and then repackage the mobile app as a new app. API hooking is to intercept mobile app’s API calls at runtime so as to inspect malicious behaviors. Each of these approaches has its own limitations and may bring new vulnerabilities. In Section 3, we present in detail the implementation issues as well as weaknesses of these three popular HIPS implementations.
Given the limitations of static and/or dynamic analysis, as well as weaknesses of existing HIPS products, we propose an enhanced HIPS called Patronus, which not only performs a secure policy enforcement, but can also dynamically detect existing malware using runtime information. To guarantee the ease of deployment, Patronus does not require any modifications on the Android firmware or mobile apps. Patronus performs runtime policy enforcement on the system level to inspect malicious behaviors. Moreover, Patronus provides a host-based runtime detection which can halt malicious behaviors execution. We make the following contributions:
• To the best of our knowledge, this is the first work which systematically analyzes three popular frameworks of HIPS and exposes various security vulnerabilities of these existing HIPS architectures. We also illustrate how to exploit the vulnerability of a popular HIPS product so as to bypass malware detection.
• We design and implement a secure architecture Patronus, which can prevent mobile malware intrusions and can detect malware at runtime. Patronus addresses the security issues we reveal in the current HIPS products and effectively prevent intrusions.
• We design and implement a two-phase detection algorithm based on the runtime intrusion information to detect existing malware. The algorithm can determine and prevent malware at runtime (online), while traditional signature-based static method can only achieve this in an offline manner.
The rest of the paper is organized as follows: Section 2 introduces the necessary background on Android. In Section 3, we present the strengths and weaknesses of three popular HIPS implementations. In Section 4, we propose our Patronus system, and describe the method to prevent intrusions as well as proposing a two-phase algorithm for dynamic malware detection. In Section 5, we present our experimental results to illustrate the effectiveness and performance of Patronus. Section 6 presents the related work and the conclusion is given in Section 7.
2. BACKGROUND
In this section, we introduce the architecture of Android system, its binder inter-process communication mechanism, as well as the Dalvik Virtual Machine and the Native Development Kit in Android. This background is essential to understand how one can create a HIPS for Android devices.
2.1 Android Architecture
Android is an open source operating system for mobile devices developed by Google. The system consists of five functional layers: (1) kernel, (2) libraries, (3) runtime support, (4) application framework and (5) applications. Figure 1 presents the Android architecture. Android utilizes Linux as the core kernel with various drivers for hardware communication. The libraries layer contains native libraries such as libc or OpenGL so as to support higher application layers. The runtime layer consists of the Dalvik Virtual Machine (DVM) with various runtime libraries. DVM is a special Java virtual machine to execute Android apps. Application framework layer contains basic services to provide activity management, SMS management, etc. Lastly, all Android apps are running on top of these layers.
Android apps are mostly written in Java using the Android SDK , and DVM is responsible for interpreting and executing these apps. Each app is running within its own DVM. The Android system assigns a unique ID for each DVM to achieve process (or app) isolation. This sandboxing mechanism provides the basic security protection between apps. Android also provides a special inter-process communication mechanism called the Binder. Each app has to go through the Binder (which is in the kernel layer) so as to communicate with other apps or services.
Besides using DVM sandbox, permission is another security mechanism provided by Android. Only when an app has explicitly declared its permissions in its AndroidManifest.xml file, then the app can use the corresponding APIs. Moreover, when installing an app, the system will display a dialog window to alert users about the declared permissions of that app. However, most users usually accept these permission alerts without paying much attention at installation. Once the installation is completed, the system will not warn users in later invocations. Many Android malware take advantage that most users are negligent and simply accept the permission alerts, so the malware can often obtain enhanced permissions (e.g., sending premium SMS messages to subscribe chargeable service in the background).
2.2 Binder Mechanism
Binder is a specialized inter-process communication (IPC) mechanism in Android. Since apps are running in their own DVM sandboxes, they need to communicate through the Binder so as to utilize others’ services. Figure 2 shows the basic flow of the Binder mechanism. For instance, if an app wants to send an SMS message, it should first (1) contact the Service Manager which contains the information of all registered services. The Service Manager will provide a handler to communicate with the ISms Service which is responsible for sending SMS messages. Once the app has the handler, it can (2) ask the ISms Service to send SMS messages, then (3) the ISms Service will process the request and send the message through the SMS Driver. Note that all communications have to go through the Binder by sending transactions with the required information (i.e., the parcel). Transaction is a communication procedure between two processes. In Android, the Binder transaction is used to send service requests (which is represented by a transaction code) to the corresponding processes. There are two stages to complete a transaction. First, the Binder will deliver a data parcel to the destination process containing the receiver information (i.e., transaction descriptor). Secondly, after completing the request, the received process will save the result in a reply parcel. In the above example of sending an SMS message, there are two transactions and they are completed in three steps. The first transaction requests for the ISms Service handler. The second transaction requests for sending an SMS message. In the second transaction, the data parcel contains the ISms Service descriptor (com.android.internal.telephony.ISms) and information (e.g., destination address and text content) for sending an SMS message. In the third step, the ISms Service sends the request and saves the result in a reply parcel.
Note that this procedure is similar to the client-server communication model. Apps are on the client side and they are executing within their own sandboxes, while various services are on the server side and they are managed by the Service Manager. The System Services are a group of services related to the Android system (e.g., Account Manager Service, Battery Service and Network Management Service). Moreover, an app can export its service to the public by registering to the Service Manager. This special Binder mechanism not only provides a flexible inter-process communication framework, but also isolates apps and services so as to protect the system.
2.3 DVM & Native Development Kit
Dalvik Virtual Machine (DVM) is a special component in the Android system. The apps are written in Java and compiled into a bytecode file (i.e., class file) with Android SDK. These bytecodes will be converted to Dalvik executable files (i.e., dex file) before installation. To instantiate an app, the DVM will interpret and run the app in a different virtual machine. In order to integrate with other C/C++ native libraries, Android provides the Native Development Kit (NDK) for developers to implement parts of the app using native code such as C/C++. Moreover, Java Native Interface (JNI) provides a bridge between the Java code and C/C++ code so developers can invoke native code easily. Therefore, for the system, DVM can use native libraries (e.g., OpenGL, libbinder, libc) to support its execution.
