Curtailing Privilege Escalation Attacks over ...

Curtailing Privilege Escalation Attacks over Asynchronous Channels on Android Katharina Mollus, Dirk Westhoff

Tobias Markmann

Hochschule Furtwangen University Furtwangen, Germany {katharina.mollus, dirk.westhoff}@hs-furtwangen.de

Hamburg University of Applied Sciences Hamburg, Germany [email protected]

Abstract—Recently we presented QuantDroid [7], a quantitative approach towards mitigating privilege escalation attacks on Android. By monitoring all synchronous IPC via overt channels on-the-fly, a so called flow-graph service detects an abnormal amount of traffic exchanged between DVMs running different Apps to indicate a potential horizontal privilege escalation attack. However, although certainly a valuable first step, our initial QuantDroid approach fails when dealing with asynchronous IPC via persistent storage containers on the Android system. To also address this issue, in this work we extend QuantDroid to QuantDroid++ by providing i) a central storage of taints when operating on system-internal databases of Android, ii) an extension of the SQL cursor object to preserve taints and link requested data with such taints, and, finally iii) an inspection of the information flow with such newly available taints for all relevant database operations. Keywords—Android, IPC, Horizontal Privilege Escalation

I.

Introduction

Vulnerability of mobile devices has recently attracted the news, let it be due to the spying out of Mrs. Merkel’s mobile phone, or, Android’s flashlight-App which has been downloaded more than 50 million times revealing the user’s position and device identity. Whereas in case of the flashlightApp, at installation time careless users equip the App even with permissions not required e.g. for the illumination of the mobile’s display, recently we observe more and more sophisticated attacks aiming at an escalation of privileges on a mobile device. We will see that (horizontal) privilege escalation is a common problem on mobile operating systems, which, foremost is true for the Android OS. Android is an open-source platform. Due to the tools and API provided by Google, one can implement applications (Apps) relatively easy. Thus, also relatively unexercised programmers can create own Apps and publish them in Googles official App market (Google Play). Google does not check the qualification of the developer. The only requirement is that Apps are signed with the developers certificate. That way bug prone or malicious Apps frequently find their way onto the end-users’ mobile devices via Google Play or third party markets. Let us assume an App which formats text messages according to a given profile and displays it in a sorted manner. This App may be used as an alternative approach for the core Short Message Service (SMS) App. Naturally it would require the READ SMS or the RECEIVE SMS permission but not the c 978-1-4799-5350-9/14$31.00 2014 IEEE

INTERNET permission. However, as we will see, there are two possibilities that the SMS Formatter App can pose a security risk. Firstly, it could have an exposed component which is not secured against illegitimate access. A stand alone SMS Formatter widget, which displays the SMS sorted by the SMS Formatter on the home screen, would need access to the SMS data. The task to verify correct permissions of the requesting App is handed to the developer of the App. If such a permission check is not executed, nearly any App can access SMS data. To sign an App for its publication, the keystore file and the corresponding password are required. If an unauthorized developer gains access to the certificate and password, he could bogusly sign his own Apps. Google explicitly advises to avoid passing the private key to others since this compromises the identity of the developer and the trust of the users. However, if the key is stored at an unsafe place, it can be stolen and reused. When using the command line options -storepass and -keypass of the keytool, the values inserted can be read in the shell history. Thus, an attacker can easily sign his own malicious App with the SMS FORMATTER key and use the same sharedUserId. Moreover we believe that the real threat is what we coined insidious trustfulness pretension. An attacker can create a useful and successfully operating App which is widely accepted and top-rated by the community. Therefore this App helps establishing the developer’s trust to the community. If a second, now malicious App is created by the same App developer, the attacker can insidiously profit from his reputation since the new App will at least tried out by the trusting user base. This is also true for updates of previously installed and accepted Apps. Such an App could be a task scheduling App which synchronizes to a web server. It would only need INTERNET permission. When this malicious App is also installed on the target device running the SMS FORMATTER, it can effortlessly access all data. If the formatter exchanges data with its standalone widget by using Intents, the task scheduler can request SMS data by Intents too. Also other types of communication channels can be used to e.g. fetch SMS data. Due to the sharedUserID, the malicious App can access the SMS FORMATTER database even asynchronously at a later point in time without requiring the formatter to run simultaneously. This simple example impressively illustrates, how private data like contact information can

silently be transmitted to a web server although none of the Apps have both, SMS permissions and INTERNET permissions. All this poses a high security risk since SMS is currently used for a variety of purposes. Like for example website login verification and the transmission of one-time passwords such as the mTAN used by various banks or DHL packet stations. An attacker, knowing the credentials of the victims online banking by a previous phishing attack, could easily request a mTAN which he then gets delivered via App-toApp communication. This can even be disguised by deleting the mTAN after transmitting to a web server or forwarding to another mobile phone. In the work at hand we revisit QuantDroid, an effective approach against horizontal privilege escalation on Android [7] and provide an extension to the originally proposed approach. QuantDroid uses a method called taint tracking introduced by the underlying Android extension TaintDroid. Data flow is marked with distinct tags such that the data source can be determined at different data sinks. QuantDroid logs labelled communication in a data structure called flowgraph. By continuously monitoring the amount of the exchanged data, it is possible to predict potential data leaks and initiate countermeasures to this. In its simplest form this can be the shut down of the sending App respectively the receiving App. We will later show at which stages of a DVM-to-DVM communication QuantDroid monitors the data flow. Possible open attack points are presented before we propose our countermeasures against such identified attack patterns. II.

Related Work

Horizontal privilege escalation is a common problem on mobile operating systems, especially on Android. QuantDroid [7] aims to address this problem by following a quantitative information flow analysis approach. It uses dynamic taint tagging and builds an information flow graph from communication metadata collected at the IPC boundaries. QuantDroid uses TaintDroid [2] to mark security and privacy relevant data near their sources and propagate those markings throughout the system. Android itself heavily relies on IPC for component reuse and application interaction, which makes it an ideal point to supervise the communication between various application and OS components. Thereby QuantDroid tries to gain an overview about privacy relevant data flows and aims to protect the user from privacy invasion. Various research groups already approached the problem of privilege escalation attacks on the Android platform. XManDroid by Bugiel et al. [1] aims to address the problem of privilege escalation attacks. They monitor communication over covert channels and inter-component communication (ICC) and utilize known high-level permission information of Apps to build a communication graph, analyze the graph for malicious behaviour and initiate counter-measures. With IPC Inspection [3] Felt et al. proposed a system that tries to mitigate privilege escalation attacks by adjusting the run-time permissions of the receiving App such that it is limited to the permissions of the caller App. In some cases copies of running Apps need to be created so they can run with a distinct set of permissions, which is more resource heavy.

However, both proposals [1] [3] are solely based on highlevel permission information and the inter-component communication. QuantDroid, as we will see, on the other hand draws additional information from real-time quantitative data flow graphs between and inside of Apps. Finally Lu et al. [6] introduced the Component Hijacking Examiner (CHEX) as a statical approach to detect App vulnerabilities. Complementary to the aforementioned approaches a data flow-analysis on the App code of each App is performed. It is based on Dalysis, a generic static analysis framework. Opposite to our work, the objective of CHEX is to detect code vulnerabilities per App. Their approach does not consider privilege escalation attacks between Apps, neither via synchronous, nor via asynchronous IPC. III.

Background

A. Privilege Escalation Attacks For all OS supporting multiple users, access of resources has to be restricted. That way different users can receive different permissions. If a user is granted more permissions than it would be commonly permitted, this is named privilege escalation. In Android single application components like service, content provider, broadcast receiver and activity may be able to use privilege escalation to receive more permissions than required or desired. According to [4] we differentiate two types of privilege escalation whereas only the latter is in the scope of our proposed solution: Vertical Privilege Escalation: Bugs and design flaws can be applied to allow the smart phone user to execute higher level applications or functions. A process for instance may use a bug in the system kernel and run functions with system privileges. There must be at least one process running with system rights in order to enable another lower level process to escalate. Horizontal Privilege Escalation: User and applications are located at the same permission level. Privilege escalation takes place if a user or an application can access data or functions of another user or application. One of the Android built in security features is the Android application sandbox. It isolates data and components of one App from another App. However, IPC communication via intents respectively broadcast intents makes it possible to perform horizontal privilege escalation attacks. Figure 1 illustrates the aforementioned example of a privilege escalation in which the Task Scheduler App owns the INTERNET permission, but does not have the READ SMS permission. However, the Task Scheduler is able to send data to another application (SMS Formatter) over an open communication channel. The SMS Formatter does not have the INTERNET but has the READ SMS permission. B. Overt and Covert Channels Overt Channel: Communication Channels that have been defined and designed to be explicitly used for data exchange are called overt channels. In Android those channels are mostly intents and inter-process communication but also content providers and databases. Android controls and monitors data exchange and enforces correct permissions for access. However, no content checking is used. Therefore overt

Figure 1. Illustration of a horizontal privilege escalation between Apps TaskScheduler and SMS Formatter.

channels can be misused and may pose a severe security risk. In [8] Ritzdorf describes possibilities for a flow of sensitive data: External Storage only the permission WRITE EXTERNAL STORAGE is needed to access shared files. The file content is not monitored. Internal Storage - permissions of files inside the application’s own folder can be modified to grant access rights for other Apps. Shared Preferences - strings can be saved as key-value pairs in an XML-based preference file. The generated file can be shared with other Apps, the content is not checked. Broadcast Intents - Apps agree on a registered broadcast. Permissions to communicate over broadcasts are checked but no content filter is applied. Unix Sockets - network sockets can also be used to establish a channel between Apps. This kind of communication must be synchronous and can be detected relatively easy. Covert Channel: Channels that are not intended to be used e.g. for communication between Apps running in different DVMs are called hidden or covert channels. Kemmerer [5] defines them as channels that ”use entities not normally viewed as data objects to transfer information from one subject to another.” So a file lock, where two Apps check if a file is currently accessible, could serve as a communication channel for a few bits. Such exchanged data can not be easily detected and an inspection of such a file does not reveal anything suspicious. Although covert channels are not a new phenomenon, the Android OS surely is not immune to them. Some examples for attacks over such communication links in Android are system preferences, thread count and processor load [8]. The detection of privilege escalation over covert channels is not part of this work. IV.

Design and Implementation of QuantDroid

QuantDroid’s primary enhancements to stock Android are based on TaintDroid and consist of an additional system service, called FlowGraph [7] being integrated into Android’s IPC middleware. TaintDroid marks data which originate from privacy sensitive sources, like camera, location sensors and

address book, and propagates these markings throughout the Android system including the IPC middleware. The highlevel middleware, ActivityManagerService, as well as the more low-level Binder framework, has been modified for its integration with the FlowGraph service. It mainly consists of a call to the FlowGraph service, notifying it about the particulars of the impending communication request which include: 1) initiator PID/UID, 2) recipient PID/UID, 3) message size and 4) the tagging flag from TaintDroid. This way, the FlowGraph service receives on-the-fly information on the data transmitted via the aforementioned overt communication channels and is able to maintain a real-time communication graph of all running Apps. This build up real-time flow graph can be used at runtime to detect abnormal communication of private data which has been tagged by TaintDroid. In combination with the available permissions of the communicating Android processes, this allows to detect illegal privilege escalation which can be subsequently stopped at communication level. The above approach has originally been implemented based upon Android 2.3. To integrate the extensions presented in the remaining paper we updated it to Android 4.1 and the corresponding TaintDroid version. The FlowGraph service is started early during the boot process of Android, inside the ActivityManagerService. Due to the fact that the FlowGraph service is implemented in Java and as a Binder service, it can be easily accessed by other Android components since the Binder RPC framework ensures transparency of the process locality. The ActivityManagerService takes care of most high-level communications, including intents and broadcast intents. This service verifies the credentials of possible receiving components and registered broadcast receivers and forwards the intents accordingly. Here the FlowGraph service is integrated such that the middleware forwards communication meta data to it via binder RPC calls. Broadcast intents are handled in a similar manner, meta data is forwarded and an edge is added to the flow graph for each receiver. To monitor interaction with services via the Binder RPC framework, used by all Android system services and available to developers via the Android SDK, the android.os.Binder class has been modified to forward relevant meta data to our FlowGraph service. This class acts as abstract server-stub all Binder stub classes base upon. This way all existing as well as future services are monitored by QuantDroid. The integration into binder stubs also enables monitoring of communication with content providers, although some adjustments where needed to improve taint dissemination. QuantDroid’s data flow graph provides a quantitative overview on the recent data flow between running applications on the OS, including system services, default installed Apps and downloaded Apps from Google Play. Nodes represent the Apps or system services and directed edges between them represent the amount and kind of data flow. However, in its original version the data flow graph only contains information on communications via overt channels for a period of ∆tmonitor and thus discards old data from the graph. While this limits the detection possibilities, it keeps the real-time graph in memory compact which is essential for constraint devices like mobile

phones or tablets 1 . Privilege escalation is indicated as soon as a data flow between two Apps exceeds a predefined threshold for the taint tag of the communication flow. The particular threshold varies depending on the taint tag. While for geographic location data, even a small quantity of such data transmitted between two processes may indicate an illegal data flow and thereby an escalation, e.g. for camera data a larger amount of data is required to possibly indicate a privilege escalation. Obviously, the monitoring period has a big influence on the detection and mitigation of privilege escalation due to illegal data flows. If the monitoring period is chosen too small, some transitive data flow between multiple Apps might not be detected or could be easily circumvented by delaying and limiting the transmission. On the other side, a long monitoring period will increase the run-time memory usage of the flow graph which could result in performance degradation on memory constrained devices. The mitigation method, implemented and evaluated in the original QuantDroid approach [7], is a simple app termination of the sending process. The sender process is killed as soon as the data flow would exceed the predefined threshold.

V.

Open Issues and Limitations of Original QuantDroid Approach

QuantDroid as presented in [7] mitigates a significant subset of privilege escalation attacks on Android based OSs based on quantitative monitoring of tainted IPC messages. In particular confused deputy and colluding processes have been evaluated by the authors. However, it is unable to propagate these taints over IP- and UNIX-sockets. In addition, since QuantDroid builds upon TaintDroid, markings that go through unprepared native code, are lost. Moreover, there are two main problems left which we will discuss in section VI: i) Long-term monitoring of all possible data respectively information flows is not possible. The flowgraph grows rapidly to an unfeasible size compared to the typically limited smart phone memory for an Android device. ii) Taints are only implemented and propagated for some databases. Since persistent storage of information in databases plays a major role in many popular Apps, and, moreover, its usage in Android is very simple, they provide an easy way to communicate asynchronously within the system. As aforementioned, if e.g. the SMS FORMATTER App is designed poorly and saves SMS data inside its own database, the malicious TASK SCHEDULER can read the database due to the sharedUserID property. However, when applying QuantDroid in its original version, the SMS data is tagged with a taint, but upon saving it inside the App-private database, the taint will get lost. Thus, reading the data at a later point in time, the taint cannot be retrieved since the App-private database is not covered by TaintDroid mechanisms. Figure 2 illustrates the basic principle of such a taint-deleting data flow. 1 While the flow graph is continuously updated in real-time, a snapshot can be taken via the provider flowgdump-program. It requests the current flow graph from the FlowGraph service and prints it in DOT format, which can be easily visualized with well-know tools.

Figure 2. Illustration of QuantDroid’s insufficient Taint handling for asynchronous IPC: Taint-Deleting data flow via App-private database.

VI.

Countermeasures to mitigate Privilege Escalation via asynchronous IPC: QuantDroid++

A. Central Taint Database To address the taint propagation issue like illustrated in Figure 2, we propose to introduce a central taint database which stores taints for every tagged data stored by an App. A continuous monitoring of the required database functions is achieved by modifying the Android SQLDatabase functions which are normally used to utilize a database. In Android databases are read and written using SQLDatabase objects. Even if utilizing a private content provider, the SQLiteOpenHelper, which is usually used, returns a SQLiteDatabase object when getReadableDatabase() or getWriteableDatabase() are called. The SQLiteDatabase implements methods for creating, reading, updating, and deleting (CRUD) operations. The methods insert, query, update and delete correspond to the according SQL operations. The parameters of the methods are used to construct the final SQL statement executed by native code. For query operations a cursor object, which is returned to the App, is used. The cursor holds all rows and columns the query would return. To speed up queries and to reduce the size of the returned cursor a cursor window is used. The cursor window acts as a buffer holding a subset of rows of the complete query result. To monitor data flow into and out of App-private databases, QuantDroid already extends the CursorWindow (CW) to reattach taints to data before returning it. It therefore uses a table containing the aggregated taints for the corresponding row and column in the cursor. When a value is returned, the taint is read and appended to the data. Although this prerequisite is necessary to reattach the taints, it requires the data to be previously inserted over the same CW. Otherwise the table holding the taints is not filled. Therefore taints must be preserved on inserting to be used when creating a cursor at a future point in time. With QuantDroid++ we do achieve this by modifying the core methods of SQLDatabase: Insert: When inserting tainted data using the SQLiteDatabase, multiple insert methods can be used. However, finally each insert method calls insertWithOnConflict() where the SQLStatement executeInsert() method executes the SQL statement constructed from the parameters. executeInsert() returns the row where the values are inserted into the target database. The row number is used to insert the extracted taint into the central taint database. The concrete entries of the taint table are listed in Table 1. To save space no entries in the taint database are created for untainted data. Figure 3 shows the process of inserting a value into the database while saving the taint. In our illustration we

Table I. path tablename rownum columnname taint size fromuid procname

structure of the taint table.

the path of the target database name of the target table row number name of the column the taint fetched from the data size of the data user id which inserted the data into the DB name of the process which inserted the data

Figure 4. Example for accessing a database with inclusion of the cursor on taint data. Figure 3. Process of inserting a value into the database while saving the Taint. Left: Original QuantDroid implementation, right: QuantDroid++ enhancement.

differentiate between the original QuantDroid implementation and our QuantDroid++ enhancement. Update: Updates on database rows are quite similar to inserts. Equally to the insert the method updateWithOnConflict() executes the constructed SQL update statement. QuantDroid++ generates a query of the given parameters to determine the rows and columns which are affected by the update statement. The taint database is then updated accordingly. Delete: When deleting values from a database, the corresponding taints have to be deleted accordingly. The parameter of the delete method is used to construct an own query, selecting the row ID of the target database. These row IDs correspond to row IDs saved in the central taint database. Together with the path of the database they act as key to find the rows of the taint database which have to be deleted. Query: Retrieving the taints and tagging the data correctly is more complex as e.g. an insert or an update operation. The reason is that a query may return many rows as a result set being transferred as a cursor object. All taints of possible resulting rows and columns must thus be fetched and appended to the cursor. Changing or updating single values inside the cursor is not intended, therefore the cursor implementation itself must be altered. Another aspect to be considered is that the cursor window inside the cursor is only filled by the native functions when accessed for the first time. Filling of the cursor can be triggered prematurely but can also lead to unexpected behaviour which is not desirable. Thus, instead of filling the cursor, a second cursor for the required taints is created and included into the the original cursor. When values are accessed, the corresponding taints are fetched from the taint cursor as well and the data is tagged, which is shown in Figure 4. Querying

the database is the same as a data flow from inserting UID and process to querying UID and process. Therefore the flow graph service monitoring functions have to be called before returning the cursor. The process name is used to distinguish two Apps with the same user ID since the process ID (PID) may possibly be invalid at that point in time. A query returns many results, therefore it is not possible to determine which values are really used in the end. To consider all saved taints and to calculate the size of the communication, the data size is aggregated and grouped by taints. Summing it up: With the above described central taint database for every tagged data all the asynchronous IPC between Apps can now be inserted into the flow graph and subsequently be equivalently processed to the original QuantDroid approach. B. Cloud Approach One possibility to manage the long-term monitoring issue is to outsource the management of the graph to a centralized cloud service. Hereby attention must be paid with respect to the amount of data transferred between the mobile device and the cloud service if assuming a limit of data volume e.g. over the wireless access network. As mentioned in section IV QuantDroid builds a flowgraph, which consists of the communication between Apps, exchanged amount of data and the taint. Until now, this graph is fully held in the memory of the mobile device. However, since there is no possibility to save all connections, the graph has to be deleted from time to time. If no communication between two Apps takes place within e.g. one minute, the entry will be deleted. Therefore, data exchanged asynchronously is not monitored. In order to unburden the device, as well as to analyze the measures, QuantDroid shall connect to a server. For analysis of the cloud data different sets of data have to be distinguished. To identify the Android device in the cloud storage a unique ID is generated consisting its serial number

consecutively running Apps:

6

A

A. Security Analysis

B ∆td

- t

concurrently running Apps:

6

A

B ∆tc

-

t

Figure 5. Illustration of consecutively running Apps and concurrently running Apps. Table II.

Conceptually achieved vulnerability mitigation of QuantDroid vs. QuantDroid++ .

concurrently running consecutively running

synchrounous overt channel QuantDroid no threat

asynchrounous overt channel QuantDroid++ QuantDroid++

and MAC address. By hashing the unique ID with the SHA256 algorithm, the privacy of the device owner is maintained. The current implementation does not include any encryption. However, conceptionally all data sent from the device into the cloud should definitively be encrypted by using an adequate algorithm like e.g. AES-256 CBC. A possible use case for the cloud storage would be a bring your own device (BYOD) scenario where the cloud could be used to monitor employee devices. In this scenario the keys for encryption would be exchanged beforehand between company server and employee device. Data exchange takes place via XML-files. Therefore QuantDroid++ continuously transmits all communication between Apps, which occurred since the last transfer. If QuantDroid++ records data exchange between Apps, it will be added to the flowgraph.xml file in the /data/QuantDroid directory. In its current setting an object of the timer class executes a function called writeToServer() every five minutes. The function establishes a connection to the server. In doing so, a check will be performed if the devices is connected to a WLAN. If this is not the case, the method will be interrupted.

VII.

Evaluation

We start our evaluation by illustrating all subcases which need to be evaluated. In Figure 5 we distinguish cases in which two Apps are i) strictly running consecutively with a delay ∆td , or ii) synchronously running in the sense that both Apps run at least concurrently for some duration ∆tc , such that ∆tc ≥ ∆tmonitor . In addition, as said, we distinguish IPC communication via synchrounous overt channels (soc) and asynchrounous overt channels (aoc). QuantDroid can purely handle case ii) for soc, whereas in addition QuantDroid++ promises to also handle cases i) and ii), both for aoc. This, we do also list within Table II. If only QuantDroid is listed this means that QuantDroid++ also covers this case. However, vice versa this is surely not the case. Our objective in the remaining part of this section is to analyze to what extend our implementation of QuantDroid++ indeed achieves this.

1) Dealing with concurrently running Apps: In this case it is possible for both Apps to communicate directly. Potential soc for example are intents, broadcast intents, content provider or service calls. Those components all require sending and receiving Apps to run concurrently as stated in Figure 5. Security for those channels is guaranteed when every data exchange is monitored. To achieve this, every time the corresponding methods of the Android system are called, the given parameters are also handed over to the QuantDroid implementation. The only way to avoid this, would be to change the implementation of the Android API or to intercept the system calls. However, both is impossible for malicious Apps. A common aoc is a database in conjuction with a shared user ID, which is then used as a way to maintain data between different versions (e.g. a free and a paid version) of an App. This aoc is resulting in the threat that the insidious trustfulness poses to users. As mentioned in section V TaintDroid does not cover the propagation of taints via App-private databases. Here, security of such a channel can be achieved by monitoring every interaction with the database. QuantDroid++ extends all native database functions (insert, query, update, delete) to also store the taint in the central taint database. Asynchronous communication by concurrently running Apps via the database takes only place when the App reads data that was previously inserted. Therefore the query method of the Android system also calls the QuantDroid++ method so that each call is monitored. Again, to circumvent the monitoring, a malicious App would need to change the implementation or intercept the system call. 2) Dealing with consecutively running Apps: Consecutively running Apps can only communicate via asynchronous channels. Because database management routines already use asynchronous access mechanisms, database interactions are not depending on the way two processes are executed. The previously described aoc behaves equivalently if used by concurrently or consecutively running Apps and, moreover, security is obtained by monitoring the aoc. To verify our results and to again show the insidious trustfulness pretension, we created two applications DatabaseWriter and DatabaseReader2 that have a shared user ID and share an App-private database. The DatabaseWriter reads data from Android contacts and stores it in the own database. This data is then read by the DatabaseReader which retrieves all datasets and displays it on the screen. Additionally the receiving App can make a HTTP request with the first entry (e.g. Google search). To show that privilege escalation is possible, besides the general permission, only the sending App owns the READ CONTACTS permission and only the receiving App owns the INTERNET permission. Our test showed that every insert/query was monitored by QuantDroid++ , regardless if the Apps where running concurrently or consecutively with different delay ∆td respectively ∆tc . If the specified threshold was reached, the Apps were terminated as we expected. 2 The Apps will be published as soon as possible, meanwhile we can be contacted ([email protected]) to get the current version for testing purposes.

Table III.

Average Execution time of insert, delete and query for TaintDroid and QuantDroid++ .

1 5 10 25 50 100

Unmodified 16,5 ms 93,0 ms 202,1 ms 552,1 ms 1146,0 ms 2482,7 ms

Insert TaintDroid 4.1 14,8 ms 108,5 ms 226,5 ms 581,3 ms 1321,6 ms 2562,4 ms

QuantDroid++ 257,5 ms 1657,3 ms 3334,8 ms 8689,0 ms 16955,3 ms 38254,6 ms

1 5 10 25 50 100

Unmodified 10,3 ms 62,4 ms 113,2 ms 275,0 ms 572,7 ms 1196,2 ms

Delete TaintDroid 4.1 12,2 ms 65,8 ms 132,0 ms 307,3 ms 648,5 ms 1313,9 ms

QuantDroid++ 47,7 ms 238,4 ms 495,7 ms 1294,4 ms 2373,0 ms 5786,4 ms

1 5 10 25 50 100

Unmodified 143,7 ms 241,8 ms 220,6 ms 242,1 ms 275,9 ms 295,1 ms

Select TaintDroid 4.1 53,5 ms 92,0 ms 152,9 ms 185,0 ms 180,7 ms 231,2 ms

QuantDroid++ 254,1 ms 284,9 ms 357,7 ms 318,2 ms 376,2 ms 520,9 ms

B. Performance Analysis To determine the overhead that is imposed by the taint database and querying mechanism, the time needed for the insert, delete and query operation on the App-private database is measured in the DatabaseReader and DatabaseWriter App. The time was taken for 1, 5, 10, 25, 50 and 100 contacts both in an unmodified emulator, an emulator running TaintDroid 4.1 and an emulator with QuantDroid++ . Table III shows the average execution times over 10 runs. The difference between the unmodified emulator and TaintDroid 4.1 is very small. This is due to the fact that TaintDroid is implemented in native code. With QuantDroid++ the most overhead is created while inserting data because each taint tag must be selected and inserted also in the taint database. The same is true for deleting data. As the table shows, there is almost no overhead while selecting. We expect the values for all executions to be significantly smaller in real execution environments because of the overall overhead the emulator itself creates. We also expect smaller datasets to be inserted at once in contrast to selects retrieving large datasets. To evaluate the usefulness of the cloud approach, the size of the created XML file was monitored over several hours with different applications being installed and running in the emulator. Without any aggregation, the file size increased constantly with the emulator mostly being in an idle state. Figure 6 displays the measured values for all three Setups up to 12 hours. Setup 1 (S1) consists of an almost blank emulator with Google-Apps (Play Store, Google-Mail...) and our own Applications (DatabaseReader, DatabaseWriter). Setup 2 (S2) is the same as Setup 1 with three additional Apps, ”Flowly”, ”Pocketnow” and ”Lifehacker US”. To simulate a more realistic system, ten additional random Apps selected from Google Play have been installed in Setup 3 (S3). Although S1 has only few background activity the increase of the size is still

Figure 6. Filesize of the XML File generated by QuantDroid++ for three different Setups

observable over time. Examination of the measurements for S2 show that the startup of the additional Apps (at 0,56 h in Figure 6) creates much activity in the first hour. When running without much user interaction, S2 has also only few background activity. The third environment is the closest to a real system. Still without much user interactions S3 shows background activity created by the additional Apps and monitored by QuantDroid++ . Overall S1 shows an increase of about 56,19 kb/h, S2 650,56 kb/h and S3 1857,08 kb/h. Although the size might seem not that high, the limited resources and the uptime of a real Android device have to be kept in mind. We also expect much higher values when assuming the device in normal use with much more Apps either installed by the user or included in the stock Android version and more user interactions. Therefore the cloud approach is a good way to manage the high amount of data created by the monitoring App. The cloud itself can then also perform operations to manage the data by e.g. aggregation. VIII.

Conclusion

We revisited QuantDroid, our earlier proposed flow-graph based approach to mitigate horizontal privilege escalation attacks on Android. QuantDroid in its original version applies TaintDroid and is purely dedicated to synchronous IPC via overt channels. In this work we extended the approach to also mitigate horizontal privilege escalation via asynchronous overt channels and provided promising evaluation results which show that our enhancements to a large extend detect also such kinds of privilege escalation when consecutively running various vulnerable Apps with shared user ID from Google Play or other App markets. IX.

Acknowledgement

The work presented in this paper was supported by the Federal Ministry of Education and Research (BMBF) within the project UNIKOPS - Universell konfigurierbare Sicherheitsl¨osung f¨ur Cyber-Physikalische Systeme. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the UNIKOPS project or the BMBF.

References [1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

Bugiel, Sven, Lucas Davi, Alexandra Dmitrienko, Thomas Fischer, and Ahmad Reza Sadeghi: XManDroid: A new Android evolution to mitigate privilege escalation attacks. Technical Report TR-2011-04, Technische Universit¨at Darmstadt, 2011. Enck, William, Peter Gilbert, Byung Gon Chun, Landon P. Cox, Jaeyeon Jung, Patrick McDaniel, and Anmol N. Sheth: TaintDroid: An Information-flow Tracking System for Realtime Privacy Monitoring on Smartphones. In Proceedings of the 9th USENIX Conference on Operating Systems Design and Implementation, OSDI’10, pages 1–6, Berkeley, CA, USA, 2010. USENIX Association. http://dl.acm.org/ citation.cfm?id=1924943.1924971. Felt, Adrienne Porter, Helen J. Wang, Alexander Moshchuk, Steven Hanna, and Erika Chin: Permission Re-delegation: Attacks and Defenses. In Proceedings of the 20th USENIX Conference on Security, SEC’11, pages 22–22, Berkeley, CA, USA, 2011. USENIX Association. http://dl.acm.org/citation.cfm?id=2028067.2028089. Ghorbani, Ali A., Wei Lu, and Mahbod Tavallaee: Network Intrusion Detection and Prevention, volume 47 of Advances in Information Security. Springer, 2010. Kemmerer, R.A.: A practical approach to identifying storage and timing channels: twenty years later. In Computer Security Applications Conference, 2002. Proceedings. 18th Annual, pages 109–118, 2002. http://www.acsac.org/2002/papers/classic-channels.pdf. Lu, Long, Zhichun Li, Zhenyu Wu, Wenke Lee, and Guofei Jiang: Chex: Statically vetting android apps for component hijacking vulnerabilities. In Proceedings of the 2012 ACM Conference on Computer and Communications Security, CCS ’12, pages 229–240, New York, NY, USA, 2012. ACM, ISBN 978-1-4503-1651-4. http://doi.acm.org/10.1145/2382196. 2382223. Markmann, Tobias, Dennis Gessner, and Dirk Westhoff: QuantDroid: Quantitative approach towards mitigating privilege escalation on Android. In Communications (ICC), 2013 IEEE International Conference on, pages 2144–2149, 2013. Ritzdorf, Hubert: Analyzing covert channels on mobile devices. ETH Zrich, Department of Computer Science, 2012. http://e-collection.library. ethz.ch/eserv/eth:5608/eth-5608-01.pdf.