Using Network Traffic to Remotely Identify the Type of Applications ...

Using Network Traffic to Remotely Identify the Type of Applications Executing on Mobile Devices Lanier Watkins, Cherita Corbett, Benjamin Salazar, and Kevin Fairbanks Johns Hopkins University Applied Physics Laboratory Laurel, MD USA

Abstract—In an effort to ultimately develop a network-based mobile device resource monitor, we demonstrate the feasibility of remotely detecting the types of applications (i.e., CPU intensive, I/O intensive or non-CPU intensive) actively executing on a mobile device. The distinguishing characteristic of this method is its uncanny ability to remotely infer the types of applications executing on a mobile device when there is no native network traffic being generated from it. To do this, we inconspicuously solicit network traffic from the mobile device by pinging it. Then we capture the timestamps of the ICMP replies, calculate the average inter-packet spacing, and finally use a Neural-Fuzzy Classifier (NFC) that has been previously trained on CPU intensive, I/O intensive, and non-CPU intensive correlated network traffic to discern between the three application types. The NFC acts as a dynamic threshold by grouping the training patterns into clusters and uses these clusters to create membership functions to separate future patterns of each type. We evaluate several Android and Apple devices, and we show that our approach is feasible for Android mobile devices. The key to this method is CPU throttling (when the on-demand governor is used), which scales the CPU performance according to the needs of the presently executing applications in an effort to save power. We exploit CPU throttling to extract embedded delays from solicited ICMP network traffic. Our results show that our method is at least 95% effective in remotely detecting the types of applications executing on Android mobile device. Keywords—Android, mobile devices, forensics, application fingerprinting

security,

network

I. INTRODUCTION Enterprises have recognized that mobile devices are here to stay, so they must determine new and better methods of managing their security; otherwise, mobile device security concerns will overwhelm the security staff and thus leave little or no time to address the security concerns of the rest of the enterprise network. This paper investigates the feasibility of developing a network-based mobile device resource monitor by empirically demonstrating that the type of application executing on a mobile device can be inferred by simply pinging the device. Such a network-based tool can be used to ascertain initial information about a mobile device that is actively connected to the network, but is not natively generating any network traffic. In such a scenario, host-based methods would normally be used to provide detailed information about the processes executing on a remote device, but since a precedent of circumventing anti-virus software has been set [1], it is conceivable that any information garnered for any host-based tool may be spoofed. In [2], it was shown that the passive inference of CPU usage

William H. Robinson Vanderbilt University Nashville, TN

in wireline general-purpose nodes can be used to create a resource monitor. In this paper the authors venture to extend this logic to the realm of mobile devices. The key here is the extraction of delays embedded into network traffic due to CPU throttling. Specifically, when the on-demand governor is used, Android based mobile devices throttle the CPU in an attempt to lower power consumption [3]. This gives us a direct relationship between the state of hardware (i.e., CPU) and the applications running on the device. We demonstrate that this relationship is detectable in network traffic generated from Android devices. In our case, we analyze ICMP network traffic which we solicit from the mobile device by pinging it. The capability to remotely infer the type of application executing on a mobile device has many applications. For instance, this capability can be used as an initial step in application white/black listing for specific situations where the mobile device produces no network traffic. This fills a monitoring void which cannot be filled by a traditional intrusion detection system (IDS) like Snort or a web proxy like Squid (because there is no natively generated network traffic). A host-based system like Mobile device managers (MDMs) could functionally fill this void; however, as stated previously, a precedent of circumventing anti-virus software has been set, so it is conceivable that host-based monitoring tools may be ineffective. Also, their maintenance can be time consuming since each device must have software installed on it and constantly updated and patched. Another application of this capability could be to develop an anomaly detection tool which learns the application usage pattern of users and alerts when this pattern changes. Again, this tool would be most effective in situations where the mobile device is executing applications that produce no native network traffic. Such a tool could determine when a user’s mobile device executes more or less of a specific type of application over a certain time period which may indicate anomalous behavior. The contributions of our work are three-fold: (1) the method is network-based and thus does not require any software to be installed on each mobile device, (2) we evaluate mobile devices from multiple vendors and identify specific and exploitable vendor traits, and (3) the method can be used to remotely identify the types of applications (i.e., CPU intensive, I/O intensive or non-CPU intensive) executing on mobile devices. Our paper is organized into the following sections. In Section II we list the assumptions used and the limitations of our work. In Section III, we discuss related works. In Section

IV, we discuss the categories of applications that we consider in this paper. While in Section V, we briefly discuss the power management differences between Android and Apple iOS based devices, and Section VI mentions the high-level architecture of the Android operating system (OS). In Section VII, we illustrate the restricted modes of operation for Android devices that would mesh well with our method. In Section VIII, the experimental setup and procedures used in this paper are detailed in the experimental evaluation. Finally, in Section IX we summarize the paper and mention future work. II. ASSUMPTIONS AND LIMITATIONS The intent of this paper is to provide the details of information leakage that exists within Android-based mobile devices. These devices can be continuously monitored to obtain information about the applications executing on them when it is not natively generating any network traffic. In an effort to focus on the core details of this method, several assumptions were made. We assumed that: (1) only one application was executing on the mobile device at a time, (2) there was excellent WiFi signal strength, (3) there was no user interaction, (4) there are only three broad types of applications (Section IV), and (5) pinging the mobile devices do not negatively affect the network or the mobile device. The key challenge addressed in our work (i.e., remotely determining the processes executing on a mobile device when no native traffic is being generated) is non-trivial; thus, these assumptions were made to allow the core details of this method to be demonstrable. Also, we have investigated the inability of our method to extract information from the network traffic of Apple iOS devices. The primary reason our method does not work for Apple devices is the lack of the use of CPU throttling in these devices; however, there may be some other way to extract similar information from these devices. We will further investigate Apple devices in future work. This limitation is countered by the overwhelming market share of Android devices. III. RELATED WORK To our knowledge, there is very little directly related work (i.e., remote CPU load inference in mobile devices). The previous work in remote CPU load and memory load inference in wireline networks is the best recent sources of related works. The only other works remotely related to identifying non-network traffic generating applications executing on mobile devices would be MDMs. In reality, these works are only tangentially related, because they are host-based as opposed to the network-based nature of our method. A. Passive Inference of CPU and Memory Load Previous work [2][5] developed a method that correlates network traffic with the state of the hardware that generated the network traffic. In short, network traffic inter-packet spacing (IPS) was used to measure the delays induced into network traffic due to heavy node CPU or memory utilization. In the previous work, the hardware states were binary, either

available or unavailable CPU or memory. Similarly, in this paper we detect CPU states (i.e., speed), but as related to the type of application executing on the device. Also, empirical data from the passive inference related work suggests that the origins of the delays induced into network traffic were excess context switching for heavy CPU utilization and excessive paging for heavy memory utilization. Whereas in this body of work, the delays have their origin in CPU throttling and the preemption of processes that access the secure digital (SD) card. B. Mobile Device Management (MDM) Software There are several MDM vendors such as Airwatch [6], Good [7], and MobileIron [8] that are attempting to capitalize on the adoption of mobile devices for normal business usage. Even security companies such as Symantec [9] are entering the realm of mobile device management. These solutions generally function by installing a proprietary application on the device that communicates with the MDM server(s). This architecture allows a MDM to install profiles on a device as well as provide web based management portals that are used to remotely access the device for monitoring, management, configuring, application inventory, or even remote wiping. The main difference between these vendors is the range of mobile devices supported. For instance, Airwatch supports Blackberry and Good does not. Symantec differentiates itself by leveraging its experience in the security realm. These host-based MDM solutions provide remote access into mobile devices; however, they carry with them the down side of host-based tools. For instance, software is required to be downloaded onto each device. This creates a maintenance issue as well as a security issue because each device will need to download the most current version of the MDM application for updates. If the MDM application is compromised, then compliance with the policy and thereby overall security of the device and any data sent to it cannot be guaranteed. It is entirely possible to compromise a flaw in the MDM application and install unauthorized and potentially dangerous applications through unapproved channels. These issues can be mitigated by using a purely network-based method; unfortunately, to our knowledge, none exist. Currently, our method does not provide the functionality of the abovementioned MDMs, but we believe that our method is a step in the right direction. IV. TYPES OF APPLICATIONS An application can generally be categorized by the resource that is its limiting factor. For example, a CPU intensive application is limited by the speed at which calculations can be completed. I/O intensive applications are limited by the speed at which data can be transferred to and from the source media, for our work this is the SD card. In theory, the CPU does have a role in an I/O process, namely setting up DMA and parsing large files into smaller blocks for copying data. Non-CPU intensive applications are characterized by the fact that they require little CPU time. Finally, a memory intensive application is limited by the amount and speed of memory that is available for the process to use. In Android based mobile

devices, memory is a very important resource, and when this resource is sparse all non-essential applications will be killed to correct this problem [10]. Therefore, we will not focus specifically on memory intensive applications. In fact, in this paper we only consider scenarios where there is only one application executing on the mobile device so as to avoid low memory situations affecting the behavior of the device and thus our experiments. This is another scenario that we will further investigate in future work. There are many applications that fall into these three categories, (i.e., CPU intensive, non-CPU intensive and IO intensive) but to demonstrate the capabilities of our method, we chose to only investigate 6 applications. This method is feasible because the applications in each of these categories use the resources in a mobile device in different ways. CPU intensive application have assembly language instructions that create processes that heavily utilize the CPU, while non-CPU intensive applications have instructions that create processes that require significantly less CPU time. Finally, I/O intensive applications have instructions that create processes that continuously require I/O resources. Each of these types of applications affect the mobile device’s schedulers (i.e., CPU and I/O), CPU and main memory (we do not consider memory intensive applications) in a different way. The CPU scheduler in the Android devices of interest is the current Linux 2.6 scheduler, the completely fair scheduler (CFS) [11]. It ensures that each process uses the resources in the mobile device as fairly as possible relative to the priority of the process. Since I/O intensive processes typically spend a lot of time waiting on I/O resources, the CFS scheduler gives them a higher priority. The I/O scheduler in the Android devices of interest is the Noop scheduler which is a simple first-in first-out queue with request merging ability. This I/O scheduler is best for flash based devices [12]. CPU intensive applications will fill the scheduler with processes that require CPU time while nonCPU intensive applications will have very few processes waiting on the CPU. In contrast, I/O intensive applications will have processes in the CPU scheduler that cannot even access the CPU until after they gain access to I/O resources. For I/O intensive processes, delays due to waiting on processes to release I/O resources dominates even CPU throttling when the device has an external (i.e., removable) SD Card. In our experiments, 6 applications from Google Play were used. The ZArchiver and AppMgr III are I/O intensive applications. The ZArchiver application among other things allows a user to zip up directories on the SD card, and the AppMgr III among other things allows a user to move applications from internal memory to the SD card. The Star Wars Angry Birds and Temple Run 2 games are both CPU intensive applications. Finally, the Android Music player and the Adobe PDF reader are both non-CPU intensive applications. V. MOBILE DEVICE POWER MANAGEMENT One of the most important resources in a mobile device is its battery life (i.e., power). Therefore, one of the most important activities within a mobile device is its power management system. We consider the power management system of the

Android (largest market share) 2.2.x and above OS and the Apple 4.2.x and above iOS (most popular) [17]. The underlying theme of the Android OS 2.2.x is that the CPU should use no power if it is doing no work. The Android’s power management system is mostly equivalent to the Linux power management system. Specifically, our main power save functionality of interest is CPU scaling or CPU throttling. This power-saving functionality lowers power consumption by throttling the CPU relative to the needs of the device. There are several mechanisms that facilitate this process. First there is a governor that determines the CPU needs of the executing application. Then there is a driver that moves the current CPU frequency to the desired value [3]. This can be referred to as CPU throttling or CPU frequency scaling. General techniques for CPU frequency scaling can be found in [18]. In an Android device, CPU throttling is based on the needs of the foreground process and all running background processes. The number of processes allowed to execute in the background depends on the amount of free memory in the mobile device, and the order in which processes are killed (to free up memory) depends on the relative priority of the process [10]. The default governor used in most Android devices is called the on-demand governor. This is the governor used in the experiments in this paper. There are several important variables that support this governor. The maximum allowed CPU speed is stored in a variable called CPUmax. The minimum allowed CPU speed is stored in a variable called CPUmin. There is a variable called up_threshold which contains the maximum CPU load percentage allowable before the governor scales the CPU load up to the next level, and finally the sampling_rate variable contains the rate at which the governor samples the present CPU load. All of these variables [12] are used by the ondemand governor to manage the CPU speed such that the impact to the power source is minimized. Specifically, the ondemand governor keeps the CPU speed at CPUmin when the mobile device is not executing any user-space applications, and as soon as the smallest user-space application is run, it immediately forces the CPU speed to CPUmax then it immediately starts to drop the CPU speed until just before up_threshold CPU load is exceeded. In other words, the ondemand governor scales the current CPU speed such that the up_threshold CPU load for the current CPU speed is never exceeded. This occurs until CPUmax is reached. Because of this, we define the CPU speed for CPU intensive and nonCPU intensive by the below equations 1 and 2 respectively. The CPU speed for I/O intensive applications is defined empirically in Section VII. Essentially, these applications have an average CPU speed very close to that of CPU intensive applications. CPU Intensive >= (up_threshold) x (CPUmax) Non-CPU Intensive < CPU Intensive

(1) (2)

The Apple iOS works a little differently; part of its approach to power management includes only allowing seven applications to run in the background. Other applications are

Mode 0: Idle - Display: On/Off - CPU: CPUmin - Wireless: On

Mode 1: User Interaction - Display: On - CPU: > CPUmin, CPUmin,