international journal of critical infrastructure protection 7 (2014) 247–256
Available online at www.sciencedirect.com
www.elsevier.com/locate/ijcip
Security considerations related to the use of mobile devices in the operation of critical infrastructures Alessandro Armando, Alessio Merlon, Luca Verderame Computer Security Laboratory, DIBRIS – University of Genoa, Viale F. Causa 13, 16145 Genoa, Italy
art i cle i nfo
ab st rac t
Article history:
An increasing number of attacks by mobile malware have begun to target critical
Received 8 January 2014
infrastructure assets. Since malware attempts to defeat the security mechanisms provided
Accepted 4 October 2014
by an operating system, it is of paramount importance to understand the strengths and
Available online 17 October 2014
weaknesses of the security frameworks of mobile device operating systems such as
Keywords:
Android. Many recently discovered vulnerabilities suggest that security issues may be
Mobile devices
hidden in the cross-layer interplay between the Android layers and the underlying Linux
Android
kernel. This paper presents an empirical security evaluation of the interactions between
Malware
Android layers. The experiments indicate that the Android Security Framework does not
Cross-layer interplay
discriminate between callers of invocations to the Linux kernel, thereby enabling Android
Security
applications to directly interact with the kernel. This paper shows how this trait allows
Critical infrastructure
malware to adversely affect the security of mobile devices by exploiting previously unknown vulnerabilities unveiled by analyses of the Android interplay. The impact of the resulting attacks on critical infrastructures is discussed. Finally, an enhancement to the Android Security Framework is proposed for detecting and preventing direct kernel invocations by applications, thereby dramatically reducing the impact of malware. & 2014 Elsevier B.V. All rights reserved.
1.
Introduction
Mobile devices are no longer used only for personal and leisure activities; they are finding their way into organizations and businesses. Since mobile operating systems are geared for personal use, their use in other environments is raising serious security concerns, especially when mobile devices are used to monitor and control critical infrastructure assets. Although a variety of organizations have become very interested in the Bring Your Own Device (BYOD) paradigm [14] and several solutions have been put forward [5,22,37], security concerns persist and the paradigm has yet to gain wide acceptance. Mobile devices are also already routinely used by operators to monitor and control critical infrastructures. For example, in n
Corresponding author. E-mail address:
[email protected] (A. Merlo).
http://dx.doi.org/10.1016/j.ijcip.2014.10.002 1874-5482/& 2014 Elsevier B.V. All rights reserved.
Haverhill, Massachusetts, on-call workers use tablet PCs to monitor alarms and other systems in the local water treatment plant that serves 58,000 customers [23]. But many more solutions addressing a variety of application scenarios are emerging, including a collaborative indoor positioning system designed for time-critical scenarios (e.g., military operations) where infrastructure-based localization is impossible [30] and a mobile radiation detector with the ability to log and share data using 3G and GPS technologies [25]. The transition from personal to professional use of mobile devices is driving more stringent security requirements. Needless to say, fulfilling these requirements is crucial when mobile devices are used in the critical infrastructure. As pointed out in a 2013 Mobile Threat Report by F-Secure Labs [20], malware is the primary threat facing mobile
248
international journal of critical infrastructure protection 7 (2014) 247 –256
devices. Malicious apps can be retrieved from application markets (e.g., Apple Store, Google Play, Samsung Store and Windows Store) and installed on mobile devices. This malware exploits vulnerabilities in other applications or in the mobile operating system itself. When executed, it may steal sensitive information, corrupt the integrity of data, and even affect device usability. Recent studies [29] have shown that it is not particularly difficult for a programmer to implement and distribute malware using a public store. The deployment of countermeasures at the market-side (see, e.g., [3,27]) may mitigate adverse effects, but it does not eradicate malicious applications [31,38]. This paper focuses on the highly popular Android operating system. Android engages a Java stack built on top of a native Linux kernel. The services and their functionality are realized through the interplay of components residing in different layers of the operating system that invoke function calls. The Android Security Framework (ASF) stems from the fruitful combination of security mechanisms in different layers, namely the standard discretionary access control (DAC) model of Linux, the isolation offered by the Java Virtual Machine (JVM), and a collection of Android-specific mechanisms such as the Android permission system. The Android Security Framework oversees the cross-layer interplay among components to detect malicious or unwanted interactions and intervene, if necessary. However, the security that it offers has been recently challenged by the discovery of a number of vulnerabilities involving different layers of the Android stack and the associated crosslayer interplays (see, e.g., [6,12,16]). One example is the Zygote vulnerability reported in [6], which enables malware to force a Linux kernel to fork an unbounded number of processes, rendering the device completely unresponsive. In this case, the problem arises from the fact that the Android Security Framework is unable to discriminate between a legitimate Android cross-layer interplay performed by trusted Android services and an insecure interplay involving an application; this permits the direct invocation of a critical kernel functionality (fork operation) by any application. The essence of the problem is the lack of control on Linux system calls that are involved in launching new applications. This paper examines if the lack of control between the Android stack and Linux kernel is limited to certain types of calls or if it is a more general issue with the Android Security Framework. If the latter is true, there is the distinct fear that malware could leverage a wide attack surface that spans the entire native Linux kernel. To ascertain the situation, an empirical assessment is conducted for the cross-layer interplay between the Android stack and Linux kernel. The assessment provides insights into the extent to which the Android Security Framework can discriminate between trusted and untrusted invocations of core system functionality. The results demonstrate that very little control is exercised by the Android Security Framework and that malware may force and exploit insecure interplays, including attacks that adversely affect privacy and device usability. This paper also discusses the impact that such Androidbased malware may have on mobile devices that are used in the critical infrastructure. Finally, an enhancement is proposed to the Android Security Framework that helps
recognize and effectively prevent insecure cross-layer interplays between the Android stack and Linux kernel.
2.
Related work
Android security has received considerable attention during the past few years. For example, general surveys are available in [18,35], vulnerabilities are reported in [6,33] and vulnerability detection techniques are proposed in [12,21]. Most of the research focuses on enhancing the Android architecture and its security model. Researchers have shown that the Android platform suffers from vulnerabilities that allow malware to perform denial-ofservice attacks [6], create covert channels [33] and launch web attacks [28] and privilege escalation attacks [16]. Some vulnerabilities are intrinsic to the Android security model (see, e.g., [16]), while others are due to security flaws, bugs and the lack of controls in the security mechanisms that constitute the Android Security Framework (see, e.g., [6,28,33]). Several tools have been developed for malware detection and application certification. For example, SCanDroid [21] performs automatic application certification by assessing whether application data flows are consistent with the application manifest. Comdroid [12] assesses the actual privileges of Android applications by analyzing their intent-based communications. Another tool [34] statically analyzes Android executables to compare function calls with malware signatures. Solutions for malware detection at the market-side have also been developed. An example is Google Bouncer [27], a malware detector that runs on the Google Play store; however, Oberheide and Miller [31] have shown that Bouncer is easily circumvented. DroidRanger [40] is an application market analyzer that combines a footprint-based detection engine of known malware, focusing on API calls and declared permissions, with a heuristic detection engine for zero-day malware. These tools are powerful, but they do not consider cross-layer interplays between the Android stack and Linux kernel or direct kernel invocations via system calls, which is the focus of this paper. The monitoring of Android system calls is performed by the Android Application Sandbox (AASandbox) [8] and by Crowdroid [10]. AASandbox can perform static and dynamic analyses in a fully isolated environment through a loadable kernel module that monitors system calls. Crowdroid carries out a dynamic analysis of application behavior. Based on the collaboration with the Android user community, Crowdroid can distinguish between benign and malicious applications of the same name and version, detecting anomalous patterns in the execution of system calls. These approaches are different from the one presented in this paper for two reasons: (i) they log only the return value of each system call without logging the parameters and (ii) they do not provide security assessments of system calls, nor propose solutions that could mitigate possible malicious interplays. Formal frameworks for modeling application behavior in terms of interactions have been proposed. Chaudhuri [11] has proposed a language-based approach to infer the security properties of Android applications. Although it allows for the formal assessment of application properties, the approach does
international journal of critical infrastructure protection 7 (2014) 247 –256
not support the modeling of interplays with the Linux Kernel. We have recently proposed a framework for the formal modeling of interactions between the Android stack and Linux kernel [4]. This was done by extending Featherweight Java [24] to support the modeling of Android-specific interactions such as intent exchange and system call invocation. To the best of our knowledge, no researchers have attempted to experimentally assess the security of crosslayer interplays between Android layers and the Linux kernel. This paper proposes a novel approach to support the monitoring and analysis of Android interplays. The approach has led to the discovery of previously unknown vulnerabilities related to cross-layer interactions. Before discussing the details of the approach, we briefly introduce the Android architecture and the interplay between Android layers.
3.
Android overview
The Android architecture shown in Fig. 1 has five layers. The Linux kernel resides in the bottom layer (which we simply call the Linux kernel). The remaining four layers are Androidspecific and we collectively call them the Android stack: Application Layer (A): Applications are at the top of the stack and comprise user and system applications that are installed and execute on a device. Each application comprises a set of components, each performing a different role in the logic of the application. Application framework layer (AF): The application framework provides the main services of the platform, which are exposed to applications as a set of APIs. This layer provides the System Server, a process implementing the core services of the layer.
249
Android runtime layer (AR): This layer consists of the Dalvik Virtual Machine (Dalvik VM), the Android runtime core component that executes application files built in the Dalvik executable format (.dex). Libraries layer (L): This layer contains a set of C/Cþþ libraries that support the direct invocation of basic kernel functionality. The libraries are widely used by AF layer services to interact with the Linux kernel and to access data stored on the device. Example libraries are the Bionic libc, a custom implementation of libc for Android; and SQLite, a selfcontained, transactional database engine. Kernel layer (K): Android relies on a Linux kernel for core system functionality. The functionality includes (i) access to physical resources (i.e., device peripherals, memory, filesystem) and (ii) inter-process communication (IPC). Device peripherals (e.g., GPS antenna, Bluetooth/Wireless/3G modules, camera, accelerometer) are accessed via Linux drivers installed as kernel modules. The triggering of peripheral drivers and access to the filesystem and memory are achieved by means of system calls (e.g., open, read and write for file management). IPC may be carried out using the Binder driver or by reading/writing via native Unix domain sockets. The Binder driver is activated through binder calls (i.e., ioctl), while sockets are accessed through socket calls (e.g., connect, bind, sendmsg).
Operations in Android are carried out via interactions between layers. The interactions, which constitute the Android interplay, are implemented by six types of calls: (i) function; (ii) dynamic load; (iii) Java native interface (JNI); (iv) system; (v) binder; and (vi) socket calls. The calls involve distinct subsets of layers and libraries. As discussed above, system, binder and socket calls allow the direct triggering of
Fig. 1 – Android architecture.
250
international journal of critical infrastructure protection 7 (2014) 247 –256
Linux kernel functionality. Hereafter, we refer to these types of calls as “kernel calls.” Android provides the operating system functionality to applications via combinations of calls. For example, the launching of a new Android application is normally realized via the following interplay: 1. A requesting application (i.e., device home screen) executes a binder call to the Activity Manager Service (AMS) in the AF layer to start the launching process. 2. The Activity Manager Service checks the permissions of the requesting application and, if they are sufficient, executes a set of socket calls (i.e., connect, sendmsg, listen) to the Zygote socket in the K layer to write a command that requests the launching of a new application. The command contains information related to the application that is to be launched. 3. The controlling process of the Zygote socket (i.e., Zygote process) parses the command and invokes a JNI call to load a proper library function in the L layer to access kernel functionality. 4. The invoked function directly executes a fork system call in the K layer, building a new Linux process to host the launching application. If something goes wrong, the command provided by the Activity Manager Service to the Zygote socket forces the kernel to destroy the created process; otherwise, a new Dalvik VM with the code of the launching application is bound to the process and execution begins.
The cross-layer interplay in Android is poorly documented and is not standardized. In fact, the official literature [9] only discusses a few operations of the Android cross-layer interplay. Moreover, the operations related to the launching of a new application are not documented. The description provided above (which is borrowed from [6]) was inferred by systematically analyzing the Android source code. The lack of documentation and standardization implies that the same functionality could be potentially implemented through different Android cross-layer interplays, some of which may lead to security flaws. To prevent this, the Android Security Framework discriminates whether an interplay is secure or not based on the permissions of applications and the basic Android security policy. The next section describes the Android Security Framework and its limitations related to the analysis of the Android cross-layer interplay.
4.
Android security framework
The Android Security Framework (ASF) provides a cross-layer security solution (i.e., sandboxing), which is built by combining native per-layer security mechanisms. Each layer in the Android stack, except for the L layer, comes with its own security mechanisms: Application (Android permissions): Each application has a file named AndroidManifest.xml, which contains the permissions that the application may require during
execution. During installation, the user is asked to grant all the permissions specified in the manifest. Application framework (Permission enforcement): Services in this layer enforce the permissions specified in the manifest and granted by the user during installation. Runtime (VM isolation): Each application is executed in a separate Dalvik VM. This ensures the isolation of applications. Linux (Access control): As in any Linux kernel, resources are mapped to files (e.g., sockets and drivers). The Linux discretionary access control (DAC) model associates each file with an owner and a group. The model allows the owner to assign an access control list (i.e., read, write and/or execute) on each file to the owner itself (UID), owner's group (GID) and other users.
Sandboxing is a cross-layer solution adopted in Android to provide strong isolation of applications. Android implements application sandboxing by binding each Android application to a separate user in the K layer, thereby combining the native separation due to the execution of applications on different Dalvik VMs with the isolation provided by native Linux access control. After an application is installed on a device (i.e., the user accepts all required permissions in the AndroidManifest. xml file), a new user in the Linux layer is created and the corresponding user id (UID) is bound to the installed application. As stated above, the application is launched as a new process with its UID along with a new Dalvik VM to execute it. This solution forces a non-privileged UID to have at most one process running (i.e., the process containing the running application). Rarely, more than one active process for the same UID is allowed if this is explicitly requested in the AndroidManifest.xml file. However, the maximum number of active processes is bounded by the number of components comprising the application. At runtime, sandboxing and other per-layer security mechanisms are expected to avoid illegal cross-layer interplay. For example, if an application attempts to invoke a kill system call on a process that hosts another application, sandboxing is violated (i.e., a Linux user tries to kill a process belonging to another user) and the system call is blocked. Some recent vulnerabilities suggest that the integration of Android-specific security mechanisms with those provided by Linux may suffer from unknown security flaws. For example, the launching flow presented in Section 3 [6] shows that an application can invoke socket calls directly and send an ad hoc command through the Zygote socket, thereby bypassing the Activity Manager Service. The Android Security Framework identifies this cross-layer interplay as legal because it does not know that call invocations directed at the Linux kernel come from an application instead of a trusted service in the AF layer. Specifically, every running application (benign or malicious) and trusted service is hosted in an unprivileged process in the Linux layer due to sandboxing. This makes it difficult for the Linux kernel to determine if a socket or system call comes from an application rather than a trusted service; such impersonations should be detected by security mechanisms in the Android
international journal of critical infrastructure protection 7 (2014) 247 –256
stack. However, in this specific case, no mechanism recognizes the unexpected caller and the malicious interplay is permitted. Note that this interplay can be repeated any number of times by the malicious application until each device becomes totally unresponsive [7]. Other vulnerabilities suggest that security breaches can be hidden in the communications between applications. For example, single messages exchanged between applications (via binder calls) can be individually compliant with the application permissions and are, therefore, permitted by the Android Security Framework. However, some maliciously crafted cross-layer interplays can lead to undetected privilege escalation [16] or attacks on legitimate applications [12]. The analysis reveals that the problems listed above are due to a lack of control on:
The identification of the caller for direct kernel invoca-
tions (i.e., binder, socket and system calls) that may allow malware to operate undetected in the kernel instead of only legitimate Android services. The monitoring of cross-layer interplays that may allow malicious interactions if single calls do not violate the system policy or sandboxing. The identification of repeated cross-layer interplays that can expose the operating system to denial-of-service attacks.
The next section substantiates our claims using an empirical evaluation of the Android platform.
5.
Supervision of Kernel calls
As discussed above, the Zygote vulnerability is due to a lack of control on the identity of a component that invokes a socket call targeted at the K layer, which is normally expected to be executed by a trusted service in the AF layer. However,
251
the same problem may affect other calls that are normally invoked by the same trusted service. Unfortunately, due to very limited documentation on the topic, it is impossible to obtain reliable information about the kernel calls invoked by trusted services. Static analysis techniques could assist in this task (they are widely used to extract models of Android applications from the Dalvik VM code). However, due to the size and complexity of Android source code, static analysis is complex and cumbersome. Therefore, we opted for an empirical approach with two goals: (i) relating trusted services with the kernel calls they invoke and (ii) verifying that the Android Security Framework can recognize that an execution of a kernel call is invoked by a malicious application instead of a legitimate service. The experiment involved the implementation of (i) a Monitoring Kernel Module (MKM) to intercept kernel calls invoked by the entire Android stack and (ii) a tester application (KernelCallTester) that replicates the calls intercepted by the MKM. The MKM was set up to intercept kernel calls executed by trusted services in the AF layer while the KernelCallTester application was set up to reproduce each kernel call as soon as it was intercepted in order to assess if the Android Security Framework can recognize the attempt as malicious. Fig. 2 shows the interactions between the MKM and KernelCallTester. The MKM is a kernel module that customizes the invocation of kernel calls. Upon installation, the MKM retrieves the kernel call prototypes from systemcalls.h and the kernel call numbers from unistd.h. Then, it modifies each entry in the sys_call_table structure, which contains the kernel call routines; in particular, it substitutes each routine in the table with a customized one. Each customized routine obtains the calling thread name and process pid (using the Linux macro current) as well as the optional parameters passed to the call and proceeds to execute the normal routine. At runtime, the MKM creates a netlink socket in order to store the intercepted kernel calls and the corresponding parameters. Whenever
Fig. 2 – Interactions between the MKM and KernelCallTester.
252
international journal of critical infrastructure protection 7 (2014) 247 –256
MKM intercepts a kernel call, the custom routine writes a message on the netlink socket. KernelCallTester replicates kernel call invocations intercepted by the MKM and stored on the netlink socket. KernelCallTester attempts to replicate each kernel call invocation a random number of times. It comprises a broadcast receiver, an Android service (called Replay Service) running in the background and a pre-compiled Cþþ library. The broadcast receiver is responsible for launching the Replay Service after the device has booted. The Replay Service connects to the netlink socket created by the MKM and parses the data it contains. For each invocation stored in the socket, the Replay Service, via a JNI call to the KernelCallTester library, starts replicating the corresponding kernel call with the same parameters as the original call. Depending on the types of kernel calls, the Replay Service may also execute other ad hoc calls. For example, if a read call is invoked on a file, the Replay Service attempts to execute an open on the same file before invoking the read. After replicating the call, Replay Service removes the entry from the socket. The Replay Service keeps track of the success/failure of each replication attempt in the appropriate log file; error messages for failed invocations are also stored. We deployed the MKM and KernelCallTester in two Android builds, namely v. 2.3.3 (API 10) and v. 4.0.3 (API 15), the most representative distributions available on entry-level and top-notch smartphones, respectively, during the second quarter of 2013. Since the ability to load modules is natively disabled in the Linux kernel deployed in Android, the feature was enabled by recompiling the kernel for a generic ARM architecture. This modification does not alter kernel functionality, thus the behavior of the recompiled kernel is equivalent to the original one. Moreover, we developed a custom rc.module script, executed as a service in init.rc, that installs the MKM automatically at startup. We configured the MKM to intercept kernel calls executed by trusted services and to keep track of a subset of the most representative kernel calls, including core system calls (e.g., for I/O and process management: open, close, read, write, lseek, mkdir, rmdir, exit_group, exit, getpid, gettid, kill, lstat64, prctl, setuid, setgid, waitid, shutdown, gettuid, geteuid, getgid, mount, umount), socket calls (bind, connect, sendmsg, sendto, socket, recvfrom, recvmsg, listen) and binder calls (which rely on the ioctl system call). This selection covers a wide range of Android security relevant operations, such as file management, Internet connections, IPC and the launching of new applications. The motivation for reducing the subset of monitored kernel calls was to limit the overhead generated by the MKM and KernelCallTester on the test devices.
6.
These smartphones were given to a heterogeneous set of users (i.e., university students, teenagers, professors and clerks) for normal use for two weeks. The users were free to install and use any applications they wished. During the testing period, application execution had forced services in the AF layer to invoke kernel calls to provide the desired functionality to the applications. Upon analyzing the MKM logs from the smartphones (which reported more than 100,000 kernel call invocations), the services in the AF layer were correlated with the kernel calls they invoked. Table 1 presents the results. In all, 28 out of 33 (85%) of the kernel call types intercepted by the MKM were successfully replicated by the KernelCallTester on smartphones with the Android v. 2.3.3 and v. 4.0.3 builds. Only five calls (15%) failed due to Linux permission errors or incorrect parameters.
System calls: System calls reproduced by KernelCallTester may be divided into file management and process management system calls. ○ File management system calls: The MKM intercepts system calls related to file management and the parameters used (e.g., data written and absolute path of the opened file). Since files are accessed in Linux via file descriptors, whenever a filesystem call occurs, KernelCallTester attempts to reopen the targeted files and reproduces the corresponding operation (write, read or lseek). KernelCallTester also handles the mkdir and rmdir system calls. In all the test executions, we observed that possible failures were only due to Linux permission errors (e.g., KernelCallTester is not in the owner group of a certain file). ○ Process management system calls: KernelCallTester is also able to successfully reproduce process management system calls such as gettid, getpid or exit_group. Table 1 – Kernel calls invoked by services in the AF layer. AF Service
Kernel Calls
Alarm Manager Activity Manager
getpid, ioctl, open close, getpid, gettid, ioctl, lseek, mkdir, open, prctl, read, write – close, exit, gettid, open getpid, ioctl getpid, ioctl, lseek, open, read
Audio Service BatteryStats GpsLocationProvider Location Manager Service Package Manager Power Manager Service ServerThread
Experimental evaluation
We installed the two customized Android builds (v. 2.3.3 (API 10) and v. 4.0.3 (API 15)) on a set of ten smartphones. Android v.2.3.3 was deployed on five smartphones (HTC Desire HD, LG Optimus One p550, LG Optimus 3D, LG Optimus L3 and Galaxy Next GT-S5570) while Android v.4.0.3 was deployed on five other smartphones (Galaxy Nexus, HTC Sensation XL, Motorola Droid RAZR MAXX, Galaxy Tab 7.1 and HTC Vivid).
ThrottleService
VoldConnector Window Manager
close, getpid, gettid, ioctl, lstat64, open, sendmsg, write getpid, ioctl, open, read, write close, connect, getpid, gettid, ioctl, lseek, lstat64, open, prctl, read, recvmsg, sendmsg, sendto, socket, write close, exit_group, getpid, gettid, ioctl, open, prctl, read, sendmsg, write getpid, gettid, ioctl, open, recvmsg, write close, getpid, gettid, ioctl, open, read, write
international journal of critical infrastructure protection 7 (2014) 247 –256
Only the kill call cannot be reproduced because an unprivileged user is only permitted to kill a process that he/she owns. Socket calls: Since sockets are mapped to files, KernelCallTester first attempts to connect to the socket before reproducing socket calls such as recvmsg and sendmsg. Failures again occurred as a result of insufficient Linux access permissions (e.g., sockets owned by root with permissions set to 660) or unaccepted parameters (e.g., bind fails because the targeted socket is already bound). Binder calls: Binder calls rely on an ioctl system call, which allows simple commands and data to be sent to a file descriptor. With regard to IPC, the sender process performs an ioctl call to the Binder, specifying the addressee and including the message data. The Binder, which handles the passing mechanism, reads incoming messages and routes them to the appropriate destinations. KernelCallTester is unable to reproduce the same call because one of the arguments – a pointer to the data sent – causes a “bad address” failure as it is located within the addressee's memory space.
Above all, the tests show that every kernel call invoked by trusted services in the AF layer can be reproduced by an unprivileged application. More specifically, the experiments show that the Android Security Framework never intervenes when a kernel call invocation is attempted by an application instead of a trusted service, revealing that Android does not discriminate between callers of kernel calls. Moreover, there is no intervention in the case of repeated (and suspicious) invocations of the same kernel call. Even attempts to replicate the same kernel call as many at 1000 times in a few seconds were not deemed to be suspicious by the Android Security Framework. Thus, the ability to forge and directly execute kernel calls from the A layer may allow any application to take advantage of the kernel functionality for malicious purposes. The next section presents two Android cross-layer interplays that can be executed by malicious applications. These interplays degrade device performance and violate user privacy.
7.
Kernel calls and malicious interplays
A central design point with regard to the Android security architecture is that applications must not adversely impact other applications, the operating system or the user. According to the official Android documentation [1], this statement represents the final goal of the Android Security Framework. Starting from this goal, we identified two security requirements:
An application must not exhaust system resources. An application must not access data belonging to another application.
Next, we analyzed all the logs produced by the MKM during the testing phase in order to find potential vulnerabilities that, if exploited, could lead to a violation of the two security requirements. The analysis was conducted using
253
manual and automatic inspections of the entire set of logs. The results of the analysis are:
No bound exists on the number of executions of filesystem operations.
Files located in /data/data/com.android.browser/ cache/webviewCache containing the caches of installed browsers can be read by any application.
Next, we implemented two Android applications, namely WriteTest (which requires no privileges upon installation) and CacheHooker (which requires only the INTERNET permission), to perform attacks using kernel calls. WriteTest repeatedly executes open, write and close system calls at different periods of time; each interplay created a dummy file of 4 MB in the internal memory of the smartphone. CacheHooker cyclically invokes a read to the cache file, followed by a write to its data folder. Moreover, it connects (using socket and connect calls) and sends (using a sendmsg call) every copied file to a remote server. The connecting operation exploits the android.permission.INTERNET permission. We installed both applications on smartphones so that they execute as services in the background after a random period of time upon completion of the bootstrapping. Users reported that other applications started to crash or terminate at launch, and that Android provided visual notifications that the phone memory was exhausted. Uninstalling other applications did not solve the problem. Very few users were able to identify the WriteTest application and solve the problem by flashing their devices. Furthermore, during the tests, CacheHooker successfully and silently grabbed user browsing data and delivered it to the remote server.
8. Android malware and the critical infrastructure Incidents involving malware targeting and/or impacting critical infrastructure assets have been reported widely. In 2003, the SQL Slammer worm crashed a computer network at an Ohio nuclear plant [32]. In 2012, the Shamoon malware [15] disabled more than 30,000 computers and stole and wiped data at facilities belonging to Saudi Aramco, the national oil company of Saudi Arabia. According to the World Economic Forum [39], a major critical information infrastructure breakdown may have a global cost of 250 billion dollars and the probability of such an event ranges from 10% to 20%. During the past few years, mobile devices have begun to be used to monitor and control critical infrastructure assets. The Australian National Bank recently provided its employees with Android devices instead of traditional desktops [17]. Stephane [36] discusses the use of tablet devices in a minimal, autonomous control system in the event of power loss in a nuclear power plant control room. The use of Android-based mobile devices in critical infrastructures widens the attack surface by exposing them to attacks that exploit the weaknesses described in this paper. In March 2013, computer networks at the top three South Korean banks and the country's two largest broadcasters
254
international journal of critical infrastructure protection 7 (2014) 247 –256
were paralyzed by malware that was injected by a mobile phone with a standard Android distribution [13,19]. This first documented attack on a critical infrastructure by Android malware is a harbinger of the future, especially since standard Android distributions have difficulty in identifying and isolating malicious applications. The experimental results presented in Section 6 confirm this weakness and show that kernel calls can be invoked by any application, whether it is legitimate or not. Furthermore, it has been reported that open (), read(), access(), chmod() and chown() are commonly invoked by malicious applications [10]. This shows that malware releases that are capable of directly interacting with the Android kernel are likely to proliferate. To demonstrate the possibility of Android malware impacting critical infrastructure assets, we discuss two examples where our malware applications, CacheHooker and WriteTester, which leverage kernel calls, could impact the healthcare infrastructure: Denial-of-service attack on medical records: Koufi et al. [26] have proposed an Android-based framework for accessing emergency medical services using a cloud-based system. This framework enables immediate access to patient medical information by authorized ambulance personnel at an incident site and by emergency room personnel. Of course, if the Android devices of the medical personnel were to be compromised, vital patient information would not be available in a timely manner. The mobile application used in this scenario would download and access the required information locally when an emergency call occurs, eliminating the need to maintain a persistent connection with the web server. A malware application such as WriteTester installed on an Android device could be automatically activated during an emergency call. It would be a trivial task for the application to prevent the device from storing the downloaded data, thereby preventing medical personnel from accessing the latest patient information. Theft of patient data: A framework that supports the sharing of patient data within a hospital is described in [2]. The framework enables physicians to use Android tablets to monitor patients, access their medical information and communicate with hospital personnel. Since the services provided by the framework are available to the tablet through a web interface, a malware application like CacheHooker could easily obtain sensitive information from the tablet cache and exfiltrate it to an external entity. The next section discusses a solution involving an enhancement of the Android Security Framework that restricts kernel calls to trusted applications, thereby preventing the attacks described above.
9.
Restricting kernel calls
As discussed in Section 7, the lack of restrictions on kernel call invocations in Android is due to two reasons. First, the Android Security Framework does not identify the invoker of a kernel call, meaning that it is impossible to discriminate if the invoker is a legitimate application, a trusted service in the AF layer or a malware application. Second, the Android
Security Framework does not enforce any security policy that distinguishes between legitimate and illegitimate interplays. Our enhancement of the Android Security Framework relies on a modification of the Bionic libc and the development of a kernel call evaluation module called Kernel Call Controller (KCC). KCC, which is placed in the L layer, exposes a set of options for evaluating a kernel call. The following options are set by the Activity Manager in the AF layer:
Application kernel call restriction: Denies or permits kernel call invocations performed by the A layer (i.e., caller with a PID greater than 10,000). Kernel call frequency restriction: Bounds the number of calls of a given type (also with different parameters) that can be invoked by a single caller in a certain period of time (e.g., one, ten or 60 s).
Bionic libc is a derivation of the standard C implementation for a mobile environment. In Android, this library is included in each Linux process and performs the actual invocation of kernel calls. Each call is implemented by a different tiny assembler source fragment (called syscall stub), which is responsible for executing the corresponding kernel code. Note that syscall stubs are generated automatically by a Python script (gensyscalls.py). We extended Bionic libc by modifying the syscall stubs, i.e., by changing the script that generates them. Before executing the kernel code of the call, the modified stub invokes the main routine of KCC, which is able to (i) identify the PID of the caller; (ii) calculate the frequency of each invocation; and (iii) assess whether or not the behavior is compliant with the KCC settings, accordingly allowing or denying the execution of the call. Furthermore, information collected by the KCC is stored in the /data folder as a text file for offline analysis. The idea of hooking system call procedures has been also adopted by SEAndroid; however, this significantly impacts the system architecture. In fact, whereas our patch only involves a modification to Bionic libc, SEAndroid requires a deep customization of parts of the Android Framework and the recompilation of the Linux kernel. We deployed KCC as well as WriteTest and CacheHooker in our two Android builds and then installed them on the smartphones used in the experiments. The same tests described in Section 6 were performed. We configured KCC by disabling the invocations of kernel calls from the A layer and limiting the number of allowed calls to ten per second. KCC was able to block the unexpected direct kernel call invocations produced by the malicious applications, thereby defeating the attacks. Specifically, the WriteTest and CacheHooker applications were successfully blocked and, thus, the memory exhaustion and the web cache privacy leak were both prevented. During the testing phase, no user reported any visible performance issues or unexpected behavior. These results, albeit limited to a small subset of available Android applications, appear to indicate that most applications do not need to perform direct kernel call invocations to work properly.
international journal of critical infrastructure protection 7 (2014) 247 –256
10.
Conclusions [7]
Security issues underlying cross-layer interplays in Android devices enable malware to interact with the underlying Linux kernel and directly invoke kernel functionality. To gain insight into the security problem, an ad hoc Monitoring Kernel Module (MKM) and the KernelCallTester application were designed to capture and replicate all kernel calls invoked by trusted services in the Android Application Framework (AF) layer. Experiments involving two custom malicious applications (WriteTest and CacheHooker) demonstrate that cross-layer interplays can undermine Android device usability, user privacy and, indeed, critical infrastructure assets where such devices are used. Fortunately, the proposed enhancement of the Android Security Framework allows the invocation of kernel calls by malware to be limited, dramatically reducing the attack surface at the kernel layer. The enhancement is easily ported to any existing Android build by simply recompiling the source code. Future research will focus on deeper and automated analyses of the MKM logs to discover other potential malicious interplays. The malicious interplays executed by WriteTest and CacheHooker were identified using a mix of manual and semi-automatic analysis techniques. Optimized and methodical approaches, including the use of machine learning techniques, would significantly advance malicious interplay discovery. Another research avenue is to test the malware and its security solution on Android devices used in the critical infrastructure; this would help assess precisely how malicious interplays could impact the security and availability of critical infrastructure assets. Finally, future research will focus on using the MKM and KernelCallTester application to evaluate the efficacy and robustness of the new security mechanisms adopted in the Android Security Framework from Android version 4.3 (i.e., SEAndroid) with regard to their ability to limit direct invocations of kernel calls.
r e f e r e n c e s
[1] Android Developers, Security Tips (〈developer.android.com/ guide/topics/security/security.html〉). [2] J. Antony, B. Vijayan, S. Joy, G. Santhoshkumar, N. Chandran, Ubiquitous patient monitoring and smart alert generation in an intensive care unit supported by low cost tablet PC based
[8]
[9] [10]
[11]
[12]
[13] [14] [15]
[16]
[17] [18] [19] [20] [21]
[22]
[23] [24]
automation system powered through open source software, in: Proceedings of the Global Humanitarian Technology Conference: South Asia Satellite, 2013, pp. 334–339. [3] Apple, App Store Review Guidelines, Cupertino, California
[25]
(〈developer.apple.com/appstore/guidelines.html〉), 2013. [4] A. Armando, G. Costa, A. Merlo, Formal modeling and reasoning about the Android Security Framework, in:
[26]
Proceedings of the Seventh International Symposium on Trustworthy Global Computing, 2012, pp. 64–81. [5] A. Armando, G. Costa A. Merlo, L. Verderame, Bring your own device, securely, in: Proceedings of the Twenty-Eighth ACM
[27]
Symposium on Applied Computing, 2013, pp. 1852–1858. [6] A. Armando, A. Merlo, M. Migliardi, L. Verderame, Would you mind forking this process? A denial-of-service attack on Android (and some countermeasures), in: Proceedings of the
[28]
255
Twenty-Seventh IFIP International Information Security and Privacy Conference, 2012, pp. 13–24. A. Armando, A. Merlo, M. Migliardi, L. Verderame, Breaking and fixing the Android launching flow, Comput. Secur. 39(A) (2013) 104–115. T. Blasing, L. Batyuk, A. Schmidt, S. Camtepe, S. Albayrak, An Android application sandbox system for suspicious software detection, in: Proceedings of the Fifth International Conference on Malicious and Unwanted Software, 2010, pp. 55–62. P. Brady, Anatomy and physiology of an Android, Google I/O, 2008. I. Burguera, U. Zurutuza, S. Nadjm-Therani, Crowdroid: behavior-based malware detection system for Android, in: Proceedings of the First ACM Workshop on Security and Privacy in Smartphones and Mobile Devices, 2011, pp. 15–26. A. Chaudhuri, Language-based security on Android, in: Proceedings of the Fourth ACM SIGPLAN Workshop on Programming Languages and Analysis for Security, 2009, pp. 1–7. E. Chin, A. Porter Felt, K. Greenwood, D. Wagner, Analyzing inter-application communication in Android, in: Proceedings of the Ninth International Conference on Mobile Systems, Applications and Services, 2011, pp. 239–252. S. Choe, Computer networks in South Korea are paralyzed in cyberattacks, New York Times, March 20, 2013. Citrix, IT Organizations Embrace Bring-Your-Own Devices, Fort Lauderdale, Florida, 2013. L. Constantin, Kill timer found in Shamoon malware suggests possible connection to Saudi Aramco attack, Computerworld, August 23, 2012. L. Davi, A. Dmitrienko, A. Sadeghi, M. Winandy, Privilege escalation attacks on Android, in: Proceedings of the Thirteenth International Conference on Information Security, 2011, pp. 346–360. National Australia Bank hangs up on desk phones, trials BYOD, FierceMobileIT, September 27, 2013. W. Enck, M. Ongtang and P. McDaniel, Understanding Android security, IEEE Secur. Priv. 7(1) (2009) 50–57. Fielder, Tales from the darkside: Mobile malware brings down Korean banks, RSA Security Analytics, March 21, 2013. F-Secure Labs, Mobile Threat Report, July-September 2013, Technical Report, Helsinki, Finland, 2013. A. Fuchs, A. Chaudhuri, J. Foster, SCanDroid: Automated Security Certication of Android Applications, Technical Report, Department of Computer Science, University of Maryland, College Park, Maryland, 2009. D. Gessner, J. Girao, G. Karame, W. Li, Towards a user-friendly security-enhancing BYOD solution, NEC Tech. J. 7(3) (2013) 113–116. M. Hamblen, Haverhill, MA, Water treatment plant uses iPads to monitor systems, Computerworld, October 16, 2012. A. Igarashi, B. Pierce, P. Wadler, Featherweight Java: a minimal core calculus for Java and GJ, ACM Trans. Program. Lang. Syst. 23(3) (2001) 396–450. Y. Ishigaki, Y. Matsumoto, R. Ichimiya, K. Tanaka, Development of mobile radiation monitoring system utilizing smartphone and its field tests in Fukushima, IEEE Sensors J. 13(10) (2013) 3520–3526. V. Koufi, F. Malamateniou, G. Vassilacopoulos, A. Prentza, An Android-enabled mobile framework for ubiquitous access to cloud emergency medical services, in: Proceedings of the Second Symposium on Network Cloud Computing and Applications, 2013, pp. 95–101. H. Lockheimer, Android and security, Google Mobile Blog (〈googlemobile.blogspot.com/2012/02/android-and-security. html〉), February 2, 2012. T. Luo, H. Hao, W. Du, Y. Wang, H. Yin, Attacks on WebView in the Android system, in: Proceedings of the Twenty-Seventh
256
[29]
[30]
[31] [32] [33]
[34]
international journal of critical infrastructure protection 7 (2014) 247 –256
Annual Computer Security Applications Conference, 2011, pp. 343–352. A. Mylonas, S. Dritsas, B. Tsoumas, D. Gritzalis, Smartphone security evaluation: the malware attack case, in: Proceedings of the International Conference on Security and Cryptography, 2011, pp. 25–36. Y. Noh, H. Yamaguchi, U. Lee, P. Vij, J. Joy, M. Gerla, CLIPS: Infrastructure-free collaborative indoor positioning scheme for time-critical team operations, in: Proceedings of the IEEE International Conference on Pervasive Computing and Communications, 2013, pp. 172–178. J. Oberheide, C. Miller, Dissecting the Android Bouncer, Presented at the SummerCon Conference, 2012. K. Poulsen, Slammer worm crashed Ohio nuke plant network, SecurityFocus, August 19, 2003. R. Schlegel, K. Zhang, X. Zhou, M. Intwala, A. Kapadia, X. Wang, Soundcomber: a stealthy and context-aware sound Trojan for smartphones, in: Proceedings of the Eighteenth Annual Network and Distributed System Security Symposium, 2011. A. Schmidt, R. Bye, H. Schmidt, J. Clausen, O. Kiraz, K. Yuksel, S. Camtepe, S. Albayrak, Static analysis of executables for
collaborative malware detection on Android, in: Proceedings of the IEEE International Conference on Communications, 2009, pp. 631–635. [35] A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, S. Dolev, C. Glezer, Google Android: a comprehensive security assessment, IEEE Secur. Priv. 8(2) (2010) 35–44. [36] A. Stephane, Using STPA in the design of a nuclear power plant control room, Presented at the MIT STAMP/STPA Workshop, 2012. [37] G. Thomson, BYOD: enabling the chaos, Netw. Secur. 2012(2) (2012) 5–8. [38] T. Wang, K. Lu, L. Lu, S. Chung, W. Lee, Jekyll on iOS: when benign apps become evil, in: Proceedings of the TwentySecond USENIX Security Symposium, 2013, pp. 559–572. [39] World Economic Forum, Global Risks 2013, eighth edition, Cologny/Geneva, Switzerland, 2013. [40] Y. Zhou, Z. Wang, W. Zhou, X. Jiang, Hey, you, get off of my market: Detecting malicious apps in official and alternative Android markets, in: Proceedings of the Nineteenth Annual Network and Distributed System Security Symposium, 2012.
