Dynamic Detection of Inter-application Communication Vulnerabilities in Android
Roee Hay Omer Tripp Marco Pistoia IBM Security, Israel IBM T. J. Watson Research Center, USA [email protected] {otripp,pistoia}@us.ibm.com
ABSTRACT Keywords A main aspect of the Android platform is Inter-Application inter-application communication, Android, security, mobile Communication (IAC), which enables reuse of functional- ity across apps and app components via message passing. 1. INTRODUCTION While a powerful feature, IAC also constitutes a serious at- Android is the most popular mobile operating system, tack surface. A malicious app can embed a payload into with 78% of the worldwide smartphone sales to end users an IAC message, thereby driving the recipient app into a in Q1 2015 [6]. A key aspect of the Android architecture potentially vulnerable behavior if the message is processed is IAC, aka Inter-Process Communication (IPC), which en- without its fields first being sanitized or validated. ables modular design and reuse of functionality across apps We present what to our knowledge is the first compre- and app components. hensive testing algorithm for Android IAC vulnerabilities. The Android IAC model is implemented as a message- Toward this end, we first describe a catalog, stemming from passing system, where messages are encapsulated as Intent our field experience, of 8 concrete vulnerability types that objects. Through Intents, an app (or app component) can can potentially arise due to unsafe handling of incoming IAC utilize functionality exposed by another app (or app com- messages. We then explain the main challenges that auto- ponent), e.g. by passing a message to the browser to render mated discovery of Android IAC vulnerabilities entails, in- content or to a navigation app to display a location and cluding in particular path coverage and custom data fields, provide directions to it. and present simple yet surprisingly effective solutions to The Android IAC interface is a significant attack sur- these challenges. face [?, 10, 4]. Familiar examples of IAC vulnerabilities are We have realized our testing approach as the Intent- Cross-Application Scripting (XAS), whereby an app is ma- Droid system, which is available as a commercial cloud nipulated into running untrusted JavaScript code when ren- service. IntentDroid utilizes lightweight platform-level in- dering IAC content inside an HTML-based view; client-side strumentation, implemented via debug breakpoints (to run SQL injection (SQLi), whereby an app backed by an SQLite atop any Android device without any setup or customiza- database (supported natively by the Android platform) in- tion), to recover IAC-relevant app-level behaviors. Evalu- tegrates unvalidated or unsanitized IAC data into an SQL ation of IntentDroid over a set of 80 top-popular apps query; and injection or manipulation of UI elements, which has revealed a total 150 IAC vulnerabilities — some already occur if reflective APIs, such as Fragment.instantiate(...), fixed by the developers following our report — with a recall are used without proper input validation. We describe these rate of 92% w.r.t. a ground truth established via manual as well as other attack vectors in detail in Section 2.3. auditing by a security expert. Past Research. The Android IAC interface has been in- vestigated from different angles. These include static detec- Categories and Subject Descriptors tion algorithms for confidentiality threats due to outbound IAC [4]; fuzzing tools to test the robustness of message han- D.2.5 [Software/Testing and Debugging]: Testing tools dling [10], or otherwise detect specific security weaknesses like capability leakage [21]; as well as proposals to revise ar- chitectural aspects of the Android system for more secure General Terms IAC [7]). Algorithms, Experimentation, Security While these studies are all useful, a main concern that re- mains unaddressed is IAC integrity threats. In recent years, several critical IAC vulnerabilities have been disclosed. A notable example is CVE-2011-2357 [5], which reports a Cross- Permission to make digital or hard copies of all or part of this work for Application Scripting (XAS) vulnerability in the Android personal or classroom use is granted without fee provided that copies are Browser manually discovered by one of the authors of this not made or distributed for profit or commercial advantage and that copies paper. (See Section 2.3.) Yet another example is the ability bear this notice and the full citation on the first page. To copy otherwise, to to exploit the IAC interface using drive-by techniques, e.g. republish, to post on servers or to redistribute to lists, requires prior specific by pointing the browser at a malicious website [19]. These permission and/or a fee. ISSTA’15 , July 12–17, 2015, Baltimore, MD, USA and similar discoveries expose IAC as a potentially serious Copyright 2015 ACM 978-1-4503-3620-8/15/07 ...$15.00. security hole. To our knowledge, none of the existing research provides a 2. THE IAC ATTACK SURFACE solution for comprehensive integrity testing of IAC channels. In this section, we provide technical background on An- The main challenge for the testing tool is that all fields of an droid IAC, and then describe a catalog of security vulnera- IAC message but uri are custom (i.e., not specified in the bilities that are all exploitable via the IAC surface. These IAC interface declaration). This complicates the construc- are based on publicly available vulnerability reports [5] as tion of meaningful test inputs. Another challenge is how to well as on one of the authors’ field experience in performing obtain effective path coverage with low overhead. manual security audits. Our Approach. We address the problem of testing for IAC integrity vulnerabilities. In stating this problem, we 2.1 Background: The Android Architecture place special emphasis on practicality. Our goal is to de- An Android app consists of components of the following sign a testing algorithm featuring high recall (or coverage) types: Activity, Fragment, Service, BroadcastReceiver alongside low overhead. This twofold requirement implies, and ContentProvider. All the components comprising an in specific, that the testing tool can only (i) rely on sparse app (except dynamically registered BroadcastReceivers) are app/platform instrumentation (as opposed to gleaning ar- declared in the app’s manifest file (AndroidManifest.xml). bitrary run-time information), and (ii) apply a small and An Activity defines a single UI screen, e.g. a browsing focused set of tests. window or preferences dialog. A Fragment is a finer-grained While high coverage is a natural requirement, the motiva- UI container that is reusable within the same app. Services tion for low overhead is to enable efficient large-scale testing perform background tasks. Finally, the role of BroadcastRe- by third parties, such as app stores or organizations with a ceivers is to intercept incoming messages from other appli- Bring Your Own Device (BYOD) policy, that currently have cation components and ContentProviders. Another (poten- limited vetting power. Indeed, the testing system we have tial) component in an Android app is native code. Such code, created, dubbed , is packaged as a cloud-based IntentDroid typically written in C or C++, interfaces with the Java code service to support these use cases.1 via the Java Native Interface (JNI). The idea underlying is to monitor only a IntentDroid Android apps are executed in a sandboxed environment select set of platform APIs — those responsible for security- to protect both the system and the hosted applications from relevant functionality as well as access to IAC data — and malware [4]. The Android sandbox relies on, and augments, utilize the resulting run-time information to guide testing. the Linux kernel’s isolation facilities. While sandboxing is We describe how, based on this information alone, Intent- a central security feature, it comes at the expense of inter- is able to prune redundant tests, recover custom IAC Droid operability. In many common situations, apps require the fields, and vary inputs to increase path coverage. ability to interact. For example, the browser app should be We report on extensive evaluation of across IntentDroid capable of launching the Google Play app if the user points a set of 80 top-popular Android apps from the wild, wherein toward the Google Play website. a security expert detected a total of 163 IAC vulnerabili- To recover interoperability, Android provides high-level ties. Using an average of 40 tests per app, IntentDroid IAC mechanisms via the Binder class, implemented as a was able to detect 150 of those vulnerabilities, which consti- driver in the Linux kernel. IAC is achieved via Messages (for tutes a recall rate of 92%. Some of the vulnerabilities have Services) and Intents (for Services as well as other com- already been fixed by the developers. Beyond validating the ponents). Intents are messaging objects that contain both overall efficacy of , we also validate each of the IntentDroid the payload and the target application component. Content design choices it features, and demonstrate its significance is placed into the uri (or data) attribute. and can addition- experimentally. Last, we provide qualitative insight into the ally be stored within an associated Bundle in the form of usefulness of via detailed analysis of several IntentDroid extra parameters. of the detected vulnerabilities. Intents can either be implicit, which means that the tar- Contributions. This paper makes the following principal get is not specified, or explicit, which means that a specific contributions: target is provided. Intents can be broadcast to Broadcas- 1. Comprehensive IAC Security Testing: We have created tReceivers, invoke Activitys, or launch a Service. An the first comprehensive dynamic testing system for An- application component can only be invoked by external par- droid IAC integrity vulnerabilities (Sections 4-5). ties, via an Intent, if the manifest file permits that. The 2. Attack Surface: We develop a catalog of attack vectors manifest also defines the permissions that the external party that all result from insecure handling of incoming IAC must possess. traffic (Section 2). Some of these vectors correspond to previously unknown vulnerabilities (including at the 2.2 Attacking Apps via IAC platform level), which we have reported to the respec- tive vendors and were subsequently fixed (Section 6.3). We refer to an Android component as public if (i) it is exported, either explicitly or implicitly, via Intent filters; This is of independent value for future research on An- 2 droid security. (ii) it requires neither signed nor system permissions; or 3. Implementation and Evaluation: We have implemented (iii) unsanitized data emanating from a public component our approach as the IntentDroid system, which is flows into it. featured as a commercial cloud service (with a free trial Public components form a hole in the Android sandbox. period), and has been evaluated atop 80 top-popular They expose themselves to incoming data from malicious Android apps (Section 6). We report on a rich set of parties, which may lead to vulnerabilities if the data is not vulnerabilities that IntentDroid was able to detect. sanitized or validated. Fragments are also potentially vul- 1 http://www-03.ibm.com/software/products/en/ 2 Other permissions are either enabled implicitly or granted appscan-mobile-analyzer by the user at install time. nerable, as they have access to incoming IAC data via their File Manipulation. Android app packages are each as- enclosing Activity and through its initiating Intent. signed a unique Linux UID. A direct consequence is that Malicious parties are both local and remote. Malware, files created by an app package cannot be accessed, let alone highly prevalent in Android, can interact with the public tampered with, by another app. Though an attacker can- IAC interfaces directly through explicit Intents without any not directly manipulate a file, if (s)he has control over a special permissions. Another attack vector is drive-by ex- parameter specifying the path to a given file used by the ploitation: Using the intent URI scheme, malicious web- vulnerable app, then (s)he can subvert the integrity and/or sites can drive the browser to generate Intents targeting confidentiality of the file. the public IAC interface of an arbitrary app [13, 11, 19]. Native Memory Corruptions. As mentioned in Sec- These may be either implicit or explicit depending on the tion 2.1, Android apps may include native code written in browser. C/C++. Such code is subject to classic memory corruption issues like buffer overflow, format-string violations and dan- 2.3 Vulnerabilities Due to IAC Channels gling pointers. Such weaknesses can be leveraged to execute arbitrary code in the context of the vulnerable app. Unsafe handling of incoming IAC data can result in dif- Unhandled Exceptions (Denial of Service). Pro- ferent forms of attack. Below we list the main threats. gramming errors that trigger unchecked exceptions (like null Cross-Application Scripting (XAS). Similarly to Cross- dereference) will usually cause the target app to crash if the Site Scripting (XSS) in the Web landscape, XAS arises when exception is not caught. This presents an opportunity for script content (mostly JavaScript code) is injected into the denial-of-service (DoS) attacks, and can more generally drive HTML UI of a hybrid mobile application. This enables dif- the application into an unexpected state. ferent forms of attack, including (i) access to sensitive in- formation, (ii) invocation of native code via JavaScript and (iii) UI defacing/rewriting to trigger phishing attacks. 3. OVERVIEW A concrete interface point for XAS attacks is the WebView Achieving high coverage at an affordable cost in IAC test- class, which is used to render HTML content within a mobile ing is not straightforward. We explain the challenges, and app [9]. The principal method of WebView is loadUrl(...). how they are handled by IntentDroid, in a progressive If a malicious app can control the current URL, then all manner with reference to the running example in Figure 1. the attacks listed above turn into potential threats. To ex- We motivate the features we developed in response with the ploit an XAS vulnerability, an attacker can inject JavaScript support of experimental data from Section 6. code using either the javascript URI scheme or the file scheme. In Android versions up to Jelly Bean, the latter 3.1 Running Example attack vector is relatively straightforward: The attacker cre- The code in Figure 1 is illustrative of the different ways ates a malicious HTML file, and directs the target WebView in which incoming IAC messages are processed. getDataS- object to load that file via an Intent. tring() retrieves the value of the built-in data field, whereas Fragment Injection. The static instantiate(Context custom fields (like "foo") are read via getStringExtra(...) ctx,String fname,Bundle args) method of class Fragment and getBooleanExtra(...). These can also be accessed via accepts as fname the name of the Fragment subclass to load the Bundle object, as shown at line 14 with getString(...). reflectively. This can be leveraged by an attacker to load String values from incoming messages often flow into sen- arbitrary code obtainable through the class loader of ctx. sitive operations, such as write(...) and execSQL(...) at A successful Fragment injection attack can result in load- lines 11 and 17, respectively, illustrate. write(...) also ing of an attacker-selected class into the context of the vul- demonstrates use of native code. Boolean values often gov- nerable app, which grants that class the same privileges and ern branching decisions, as with "b1" at lines 19 and 20. access rights as its host app. Otherwise an exception is thrown, but prior to that, the class’ static initializer and 3.2 Test Pruning default constructor are executed, which creates another at- Naive fuzzing, whereby all available test payloads (corre- tack/privacy vector. sponding to all the attacks listed in Section 2.3) are injected Another alternative is to load a Fragment already defined into the data field of an Intent object, yields limited cov- by the application or Android/Java framework, but inject erage at a high cost. The first order of business, therefore, malicious initialization data into the Fragment. Fragments is to prune out irrelevant tests via detection (or probing). that are normally loaded by private Activitys are more IntentDroid achieves a reduction of 87% in testing ef- likely to trust rather than validate their initialization ar- fort via a lightweight specification of necessary conditions. guments, which renders them more exploitable to Fragment Intuitively, for a given attack type (e.g., SQLi), the specifica- manipulation attacks. tion states conditions that must be met for vulnerabilities of Client-side SQL Injection. Android provides support that type to be present. The conditions refer to (i) security- for SQLite databases. Applications can create and manip- relevant APIs (e.g., execSQL(...)), and (ii) whether/how ulate a private database via a string handle. Once created, unique probe values flow into these APIs (e.g., the extra the database is stored in a subdirectory of the directory al- parameters flowing into execSQL(...)). located for the app with the chosen handle as the file name. The Android SQL support exposes Android applications 3.3 Attack Targets to the full spectrum of SQL injection (SQLi) vulnerabilities. The second challenge, having optimized performance via Insecure invocation of a database operation (for example, detection, is to improve recall. Naive fuzzing stands at 57% SQLiteDatabase.execSQL(...)), can result in an SQLi vul- recall. A key reason for misses is that often the vulnerable nerability that may have implications on both the integrity entity is not the data field but rather a custom IAC (or and confidentiality of the vulnerable app. extra) parameter. 1 class WriteActivity extends Activity { r ::= a | (a ∨ a) | a a| 2 static { System.loadLibrary (”native ”); } a ::= ? | ` | `/ | `( ) 3 ` ∈ { all Android and Java library APIs } 4 protected void onCreate(Bundle savedInstanceState) { 5 super.onCreate(savedInstanceState ); 6 setContentView(R.layout. activity write ); Figure 2: Grammar for Necessary Vulnerability 7 Intent intent = this. getIntent (); Conditions 8 String data = intent.getDataString (); 9 File target = new File(this . getFilesDir (), ”log ”); 10 int fd = NativeIO.open(target.getAbsolutePath()); 4. MAIN FEATURES 11 int size = NativeIO.write(fd , data); 12 Bundle bundle = intent.getBundle(); In this section, we describe the main features of the In- 13 String fooExtra = intent. getStringExtra (”foo”); tentDroid algorithm, aiming toward coverage improvement 14 String barExtra = bundle.getString(”bar”); and performance optimization. We defer description of the 15 if (fooExtra == null) return; overall algorithm, as well as its formal guarantees, to Sec- 16 SQLiteDatabase db = ...; tion 5. 17 db.execSQL(String.format(”UPDATE ... 18 WHERE name=’%s’ ... id= ’%s’”, fooExtra, barExtra)); 4.1 Reducing Testing Effort via Probing 19 boolean b1 = intent.getBooleanExtra(”b1”, false ); 20 if (true == b1) { The goal of the detection, or probing, stage is to decide 21 boolean b2 = intent.getBooleanExtra(”b2”, false ); for a given input point which tests should be applied to it. 22 boolean b3 = intent.getBooleanExtra(”b3”, false ); This is done by tracking, for the different security rules, (i) 23 if (true == b2) which relevant APIs are invoked while processing the probe 24 db.execSQL(String.format(”UPDATE ... input and (ii) the data arguments reaching each invocation 25 WHERE name=’%s’”, fooExtra)); 26 if (true == b3) point. 27 db.execSQL(String.format(”UPDATE ... The security rules each define a necessary condition for a 28 WHERE name=’%s’”, fooExtra)); }}} vulnerability to manifest in the form of a regular language ranging over library APIs. As an illustration, below are Figure 1: An Activity with IAC Vulnerabilities simplified versions of the necessary condition for memory corrpution and SQLi, respectively, per our running example:
? System.loadLibrary ? (Bundle.getStringExtra/ ∨ Extra parameters are not documented in the manifest Intent.getDataString/ ∨ Intent.getString/ ) ? file, nor is it possible in general to recover their identi- fiers via static analysis. Instead, IntentDroid identifies ex- ? (Bundle.getString / ∨ Intent.getStringExtra/ ∨ tra parameters by monitoring getExtra(...) calls and vari- Intent.getDataString/ ) ? execSQL( ) ? ants thereof (getStringExtra(...), getDoubleExtra(...), ? is short for .?, and denotes any sequence of trace events. etc). For the running example, this yields "foo" and "bar" denotes the probe value. as well as the boolean extras. Thus, the memory-corruption rule mandates that the trace Thanks to this feature, discovered string extras become prefix contain a call to loadLibrary(...), and at a later attack targets, which leads to an iterative probing/testing point the probe value be accessed (through getString(...), algorithm (running as long as new targets are discovered). getStringExtra(...) or getDataString()). The (partial) The iterative algorithm outputs an overall of 140 detected SQLi rule matches traces that read the probe value, and vunlerabilities, which constitutes an increase of almost 50% later flow the read value into execSQL(...). in recall for a rate of 0.85. The general grammar for expressing necessary vulnerabil- ity conditions is given in Figure 2. The grammar root is the 3.4 Path Conditions r symbol. ` can refer to any built-in API either in Java or in the Android libraries. While accounting for string extras boosts recall signifi- cantly, there are still missing vulnerabilities along unexe- 4.2 Recovery of Custom Message Fields cuted paths. Obtaining better path coverage is nontrivial in At time zero, IntentDroid only has knowledge of the de- general, as it requires a notion of how path conditions are clared IAC interface through the manifest file. Recovering structured and how to negate them. custom fields, or extra parameters, is an iterative process A simple yet effective practical observation is that often that begins with an “empty” message. For the running ex- boolean extras act as flags that govern (at least partially) ample, for instance, the first message may be the probing how the incoming IAC message is processed. As an illus- Intent tration, the conditional branches at lines 20, 23 and 26 are governed by "b1", "b2" and "b3". Manipulating boolean { cmp=...WriteActivity act=android...MAIN extras is thus an effective vehicle to increase path coverage, uri =http://G0B/ with Extras Bundle[{}]} leading to the detection of 11 additional vulnerabilities, al- where the uri field of the initial Intent is populated with a beit at the cost of 63 tests and 25 minutes per app. unique signature (in the above case: http://G0B/). As an optimization, we explore boolean extras assum- By instrumenting the platform APIs used to read custom ing they relate to each other either through “independence” fields (getStringExtra(...), getBooleanExtra(...), etc), ("b2"/"b3") or via “domination” ("b1"/"b2","b3"). This IntentDroid observes (failed) accesses to custom field iden- simplifying assumption, yielding linearly many assignments, tifiers that are missing from the current message. Thus, in appears justified in practice. There is significant cutdown in the next interation, these will be populated into the sent testing effort while only a single vulnerability is missed. message, e.g.: { cmp=...WriteActivity act=android...MAIN m[bi 7→ ¬bi] under the assumption of independence. Dom- uri =http://G0B/ with Extras Bundle[{foo=http://G4B/}]} ination is (even) more restrictive, toggling only newly ex- posed boolean extras b (while previously identified booleans The unique signature http://G4B/ is now associated with i retain their original value). We justify this simplified algo- the custom parameter "foo". rithm below. Note that aside from setting "foo", the new Intent is exactly identical to the original Intent leading to the dis- n Lemma 4.1 (Linear Path Exploration). Let {bi} covery of this custom parameter, including the exact probe i=1 be boolean extras that pairwise are either independent or re- value attached to the uri field. This is to ensure that the lated via domination. Then toggling each in turn is equiva- control flow leading to the access to "foo" is preserved. lent to exhausting all 2n joint valuations of b , . . . , b . Beyond accessing custom fields directly via Intent APIs 1 n
(like getStringExtra(...)), there is the alternative, demon- Proof Sketch. If bi and bj are independent, then their strated at line 14 in Figure 1, of obtaining custom values conjunction does not form a path condition, and so it suffices via the Bundle associated with the Intent. We refer to this to toggle each of them in turn. If alternatively bi dominates method of accessing custom parameters as indirect, because bj (without loss of generality), then toggling bi would obviate a given Bundle may or may not be linked to the Intent sent access to bj , and so exploring all possible combinations of bi by IntentDroid. and bj is redundant. To account for indirect accesses, IntentDroid first estab- lishes the binding between the message it sent and the Bun- dle object created for its respective Intent object. This is 5. FULL ALGORITHM done by installing a monitor inside the Intent.getBundle() Having highlighted the main IntentDroid features, we method. The monitoring code (i) checks whether the receiv- now describe the complete algorithm. ing Intent indeed corresponds to the message sent by In- tentDroid (by inspecting its data and extra fields), and if 5.1 Setup so, then (ii) the Bundle is marked as relevant. Furthermore, The testing session begins by deploying the target app when a Bundle is cloned, the clone is marked as relevant as in debug mode. This enables the insertion of debug break- well. This is achieved by placing monitoring code within the points into library APIs. The motivation for this design Bundle copy constructor. choice was that it applies to any Android build and any de- Based on this marking technique, IntentDroid is able vice (provided the ro.debuggable property is set to 1) as to distinguish between accesses to relevant versus irrelevant opposed to requiring a custom build (as in [3]), which limits Bundle objects. Only the former contribute custom field applicability and requires heavy maintenance. identifiers that IntentDroid subsequently explores and ex- Once the target app is deployed, IntentDroid obtains ploits. Interaction with irrelevant Bundles is ignored. — via the apktool utility — its manifest file. Parsing the manifest reveals the set of Activitys defined by the app 4.3 Path Exploration via Boolean Extras that are both public and exported. These are reachable While string values carried by the Intent pose as attack directly via Intents, and so the first IAC inputs created by targets, boolean values are not candidate attack targets, and IntentDroid are benign Intents. so the naive approach is to simply ignore these custom fields. In practice, boolean extras are typically used by the code 5.2 Testing Loop that handles the Intent to decide how to process the in- During testing, IntentDroid switches between 3 modes: coming data. That is, they often manifest in (or as) path • Monitoring: While a message is being processed by the conditions. target input point, IntentDroid tracks via system- In light of this observation, a naive strategy to increase level hooks which security-relevant APIs are invoked, path coverage is to enumerate all possible combinations of and which custom fields the app attempts to access. boolean extras. Instead, to strike a better performance/- Monitoring serves both for coverage and for validation coverage tradeoff, IntentDroid enforces certain simplify- purposes. ing assumptions, which appear effective in practice. (See • Testing: When a new field is detected, a probe re- Section 6.) These are based on the below definition. quest is sent for it. Comptabile attack types are then launched. Definition 4.1 (Independence & Domination). For • Exploration: For a given probe message with boolean IAC input point e and boolean extras b and b0, we say that extras, variants thereof (with one extra flag toggled at b dominates b0 under e if in any execution starting at e, b0 a time) are also sent as probes. is accessed if b is assigned a specific truth but not the other Interleaving monitoring, testing and exploration yields an (e.g., only when b is true). We say that b is independent of iterative testing cycle. As custom fields and fresh execu- b0 (under e) if neither is dominated by the other (under e). tion paths are incrementally discovered, the attack surface expands. On the other hand, submitting probe and test In the running example, "b1" dominates both "b2" and messages reveals more custom fields and execution paths. "b3", yet "b2" and "b3" are independent of each other. To validate the success of a security test, IntentDroid The assumption that distinct boolean extras are either relies on externally observable indications, such as compo- indepdent or related via domination leads to a linear-time nent/application crashes, as well as on the following: search algorithm, whereby boolean extras are toggled one 1. Code monitoring: Detection monitors are used also at a time. That is, given Intent m defining boolean extras for validation. Values reaching security-sensitive oper- b1, . . . , bn, path exploration is carried out by exploding m ations are observed via run-time handlers triggered in n into n (rather than 2 ) variants m1 . . . mn, such that mi ≡ response to hitting debug breakpoints. Input:( D,M,V,I) // testing capabilities Input: A // subject mobile app Output: O // detected vulnerabilities begin A0 ←− I(A) // instrument A E ←− declared interface points of A O ←− ∅ while E 6= ∅ do e ←− choose from E E ←− E \{e} foreach m ∈ M(e) do b ←− D(m, e) Figure 3: A Vulnerability Report Output by Intent- if b then Droid p[m, e] ←− create payload for e with m (r, E0) ←− fire p[m, e] E ←− E ∪ E0 2. Log listener: IntentDroid tracks updates to the stan- if V (r) then dard log files provided by the Android platform. O ←− O ∪ {r} 3. HTTP listener: A second output that IntentDroid end listens on is outbound HTTP traffic. This method is end used primarily to validate XAS vulnerabilities. end Thanks to these varied validation methods, IntentDroid is end able to generate actionable security warnings. These include end both (i) detailed code-level artifacts (call stack) and (ii) a Algorithm 1: Outline of the Core IntentDroid Al- concrete attack vector (both payload and entrypoint). An gorithm, where D, M, V and I Denote Detection, example of such a report appears in Figure 3. Mutation, Validation and Instrumentation, Respec- 5.3 Formal Description tively Algorithm 1 summarizes the complete flow of the Intent- Droid algorithm. The starting point is to instrument the Theorem 5.1 (Coverage). Let input point e be data target app to record (select) library calls as well as accesses independent, s.t. the value of incoming IAC field f, arriving to user-provided data. Next, IntentDroid obtains the de- through e, flows into sink s. Denote by E-IntentDroid the clared IAC input points E of the subject application via naive version of IntentDroid, which enumerates all pos- analysis of its manifest. These seed the iterative testing sible combinations of boolean extras. Then E-IntentDroid process. The fixpoint loop iterates over E, picking at each is guaranteed to reach s with f mapped to a test payload.3 iteration a candidate input point e and removing it from the worklist. Proof Sketch. E-IntentDroid systematically enumer- For the current input point e, the next step is to check ates all boolean combinations. This — conjoined with the whether e satisfies the necessary conditions for each attack assumption that e is data independent — guarantees that at type m. This is represented as the D(m, e) call. Successful some point access to f will be observed. Thus, f will become detection leads to the creation and application of a payload an attack target (where only the presence, but not the value, p[m, e]. Exercising the instrumented app A0 with p[m, e] of f affects control flow). All continuations of the execution yields two artifacts: additional input points E0 (discovered prefix leading to f will be enumerated, which guarantees that by monitoring accesses to custom parameters) and recording a path p starting at e, going through a read of f and end- of app behaviors/outputs r for validation. The set O of ing at s will be traversed. Given f is a non-boolean field, vulnerabilities reported by IntentDroid is augmented if r E-IntentDroid will initiate a test execution of p with f confirms a vulnerability (the V (r) check). mapped to a test payload, which completes the proof. While IntentDroid is a dynamic testing system with (purposely) limited means to track the internal behavior of 6. EXPERIMENTAL EVALUATION the target app, there are still situations in which full cov- erage is guaranteed. These are governed by a simplifying In this section, we describe quantiative results and share assumption, stated formally in Definition 5.1, which is too qualitative insight from our evaluation of IntentDroid. idealized to hold pervasively in reality, but still (i) provides insight into the design of IntentDroid, and (ii) appears 6.1 Experimental Setup and Methodology useful in practice given IntentDroid’s recall rate of > 90% For our experiments, we assembled a suite of 80 Android over a large set of popular Android apps. (See Section 6.) apps: 4 enterprise apps, 3 apps shipping with version 4.4 of the Android platform, as well as the 73 top-popular Google Definition 5.1 (Data Independence). We refer to in- Play apps in the geography of one of the authors. The ex- put point e in the IAC interface as data independent if ex- periments were conducted on a LG Nexus 5 device running ecution flow starting at e is decided solely according to (i) version 4.4 of the Android platform (CyanogenMod 11). For boolean extras and/or (ii) presence of extra fields. In partic- 3 This claim is trivially extensible to IntentDroid by fur- ular, the values of non-boolean extras (and other variables ther assuming that boolean extras are related either via in- in the program) do not affect control flow (cf. [18, 20]). dependence or via domination. accuracy and reproducibility, we reset the device to a clean image before testing each of the apps. Performance Recall Prior to running IntentDroid, an independent profes- 1 sional ethical hacker audited all 80 apps. The manual audit consisted in running, and validating by hand the results of, a brute-force fuzzing tool. The tool (i) establishes a crude 0.75 attack surface by targeting, beyond the uri field, all con- stant strings in the Dalvik bytecode as candidate extra pa- rameters, and (ii) discharges a large amount of pre-defined 0.5 payloads at each target. The fuzzing process demanded several hours (if not more) per application, and was carried out over a period of three 0.25 weeks with multiple instances of the tool running in parallel. It resulted in a total of 163 IAC vulnerabilities. Table 1 0 provides a breakdown of the results by issue type. Fuzzing Probing String Extras Linear PC Exp PC
6.2 Performance Results We have conducted a series of experiments to measure, and thereby justify, the key features of IntentDroid. We Figure 4: Visual Performance/Recall Comparison organize our description of the experiments around four re- between Testing Variants search hypotheses. The starting point is a baseline algorithm that only targets declared input points via the data field. H1: Probing Boosts Performance. To quantify the Under this assumption, which enables toggling of boolean performance gain thanks to probing, we enhanced the base- extras one at a time and thus linear-complexity path ex- line algorithm with necessary-conditions specifications as de- ploration, testing time drops to 19 minutes (24% improve- scribed in Section 4.1. Instead of blindly attempting all pos- ment) and the average number of tests is only 40 compared sible test payloads, the enhanced version first analyzes the to 63 before (37% improvement). At the same time, only one probing trace to focus testing only on relevant attack types. of the 151 vulnerabilities detected via the exponential-time The statistics demonstrate significant improvement. While path-exploration algorithm is missed for a negligible drop of naive fuzzing expends an average of 64 tests and 24 minutes < 1% in recall. Discussion. In conclusion, IntentDroid effectively bal- per app, the enhanced version requires < 15 tests and < 7 4 minutes per app to detect the same set of IAC vulnerabili- ances performance against coverage. Regarding false neg- ties. atives, our analysis of the 14 misses (w.r.t. the most com- H2: String Extras are Often Vulnerable. The naive prehensive IntentDroid configuration) reveals that these testing algorithm, equipped with probing capabilities, is able are caused by one or both of the following reasons: (i) in- to detect a total of 94 out of the 163 known vulnerabilities complete path coverage (and in particular, path conditions for a recall rate of 0.57. Enhancing it to incorporate string other than boolean extras) and (ii) overly conservative prob- extras as attack targets pushes recall up to 0.85, as 46 new ing checks (where the probe is nontrivially mutated by the vulnerabilities are detected. app, yet it is possible to craft a successful test payload). The resulting variant features an iterative testing loop, A visual illustration of the performance/coverage trade- which attacks targets discovered in previous probing/testing offs achieved by the different variants is provided in Figure 4, rounds. Naturally, this renders it more expensive than its where IntentDroid is labeled “Linear PC”.“String Extras” naive counterpart with an average of 26 (compared to 15) stands out as the variant that maximizes the recall/perfor- tests and 12 (compared to 7) minutes per app. mance gap. Even though performance increase exceeds gain H3: Boolean Extras Manifest in Path Conditions. in coverage when switching to “Linear PC”, we still view The algorithm featuring both probing and manipulation of this option as preferable, as less true warnings are missed in string extras already detects 140 out of the 163 known vul- return for affordable performance slowdown. nerabilities. A natural means to further increase coverage is by exploring new execution paths. 6.3 Interesting Vulnerabilities Augmenting the testing algorithm to explore different com- Though all vulnerabilities specified above are exploitable, binations of boolean extras achieves this goal effectively. most of them are of low severity as they either only impact This is seen through the discovery of 11 new vulnerabili- the stability of the target app or assume a complex payload- ties, constituting a 7% improvement in recall, for a total of /vector that is hard to create in practice. Other findings are 151 vulnerabilities detected fully automatically. of high severity, as they impact the confidentiality of user The cost, as expected, is noticeable. The average number data, the integrity of the application or both, and we were of tests per app climbs by x2.42 from 26 to 63 with a pro- able to demonstrate a concrete exploit for them. We con- portional rise of x2.1 in testing time from 12 to 25 minutes. clude by highlighting three of these vulnerabilities. We have This motivates more efficient detection of new paths. 4 H4: Linear-time Path Exploration is Effective. The Beyond the data we present here, which confirms our de- sign choices one atop the other, we have a full matrix of fourth and final hypothesis concerns the relationship be- measurements per every combination of the choices we’ve tween boolean extras in their capacity as branching expres- made. We have omitted most of these measurements for sions. The claim is that it is effective to treat boolean extras lack of space, but note that they are in strong support of as either dominating each other or being independent. our hypotheses. Table 1: Detected Vulnerabilities with Breakdown by Attack Type Unsafe UI Fragment Java Native File App Name Version Count XAS SQLi Refl. Spoof. Injection Crash Crash Man. com.dropbox.android 230800 4 com.ebay.mobile 43 3 com.evernote 15120 7 com.facebook.katana 228325 4 com.google.android.gm 974 2 com.lotus.sync.traveler 2013062023 1 com.linkedin.android 56 6 com.nytimes.android 5523 2 com.google.android.youtube 4517 2 com.adobe.air 3700209 0 com.adobe.psmobile 10 0 com.adobe.reader 77016 3 com.antivirus 180265 0 com.android.chrome 1453090 1 clalit.android 12 0 com.alibaba.aliexpresshd 56 1 com.android.vending 80280020 3 com.box.android 30200 1 com.cleanmaster.security 10400566 0 com.fibi 8 0 com.fitbit.FitbitMobile 1772 1 com.fitnesskeeper.runkeeper.pro 215 0 com.google.android.apps.docs.editors.sheets 1314426 4 com.google.android.apps.m4b 62 0 com.google.android.apps.magazines 2014051213 0 com.google.android.apps.maps 800001324 2 com.google.android.apps.plus 413004558 10 com.google.android.GoogleCamera 22024130 0 com.google.android.maps.mytracks 74 3 com.google.android.music 1514 4 com.google.android.talk 21224130 1 com.google.earth 13294050 1 com.hipmunk.android 102 0 com.ideomobile.hapoalim 117 12 com.ideomobile.leumicard 42 2 com.intsig.camscanner 3302 1 com.leumi.leumiwallet 18 1 com.melodis.midomiMusicIdentifier.freemium 10602 2 com.mxtech.videoplayer.ad 700000070 2 com.netgate 141 0 com.nike.plusgps 99 0 com.onoapps.cal4u 5 0 com.paypal.android.p2pmobile 49 1 com.runtastic.android 90 1 com.snapchat.android 323 0 com.ubercab 30618 0 com.urbandroid.sleep 842 4 com.viber.voip 61 2 com.waze 1019718 1 com.yahoo.mobile.client.android.flickr 41700 0 com.yelp.android 10000903 4 com.android.contacts 19 7 com.android.dialer 19 2 com.facebook.orca 221196 1 com.facebook.pages.app 232657 1 org.mozilla.firefox 2013061803 6 com.gau.go.launcherex 234 2 com.google.android.apps.currents 130781200 0 com.google.android.apps.docs 1218226 5 com.google.android.apps.finance 35 2 com.google.android.apps.translate 20700177 2 org.dayup.gtask 1602 11 com.ibm.lotus.connections.mobile 2013092105 5 com.ibm.android.sametime.meetings 20130528 3 com.ibm.android.sametime 2013041715 1 com.ibm.mobile.android.unyte 20121206 0 com.imdb.mobile 103220310 0 com.instagram.android 197069 3 com.android.mms 19 3 mobi.mgeek.TunnyBrowser 331 1 com.opera.browser.beta 1600559192 0 org.telegram.messenger 227 0 org.zwanoo.android.speedtest 124 1 com.shazam.android 78059 5 com.skype.raider 50469393 0 com.sgiggle.production 53 3 com.ted.android 18 0 com.devuni.flashlight 139 0 com.whatsapp 47672 0 fr.beungoud.xbmcremote 47 0 55/80 163 5 1 4 6 8 30 1 1 reported these vulnerabilities to the developers. In all cases, Applications written on top of Cordova make use of a the vulnerable scenario was confirmed as such and was fixed WebView instance to interact with the user. When the appli- shortly thereafter. cation is first loaded, it invokes the loadUrl(...) method of Preference Activities and Fragment Loading. The An- the CordovaWebView class, which is a subtype of Activity. loadUrl(...) has the following implementation: droid framework provides an abstract Activity class, an- droid.preference.PreferenceActivity, which serves as a 1 public void loadUrl( String url ) { 2 if ( url . equals(”about:blank”) || reusable and extensible preferences dialog. The Prefer- 3 url . startsWith(” javascript : ”)) { this .loadUrlNow(url); } enceActivity class queries its input Intent for several ex- 4 else { tra data fields. These include fields EXTRA_SHOW_FRAGMENT 5 String initUrl = this.getProperty(”url ”, null ); } (show_fragment) as well as EXTRA_SHOW_FRAGMENT_ARGUMENTS. 6 // If fst page, then set URL to load to be the one passed in (show_fragment_arguments). 7 if ( initUrl == null) { this .loadUrlIntoView( url ); } The first of these fields specifies the name of a Frag- 8 // Otherwise use the URL specified in the extras bundle 9 else { this .loadUrlIntoView( initUrl ); }} ment class, which PreferenceActivity displays dynamically upon being created. The Fragment.Instantiate(...) method As the code shows, the initUrl string is defined as the result creates a Fragment instance dynamically, via reflection, and of a getProperty("url", null) call, which consists of the following code: then casts it into the Fragment type. The second field is the Fragment’s input Bundle. A loaded 1 public String getProperty( String name, String defaultValue ) { Fragment can receive input arguments by accessing its host 2 Bundle bdl = cordova. getActivity (). getIntent (). getExtras (); 3 if (bdl == null) { return defaultValue ; } activity (and therefore its input Intent) using the Frag- 4 Object p = bdl.get(name); ment.getActivity() API. The second field therefore pro- 5 if (p == null) { return defaultValue ; } vides the additional arguments required to instantiate the 6 return p. toString (); } Fragment (if any). The return value of getProperty(...) is an extra param- Any app containing an exported Activity that extends eter obtained from the Bundle object associated with the the PreferenceActivity class can be subverted to load an current Intent (which, in turn, is retrieved via the get- arbitrary class (available to the class loader of the target ap- Intent().getExtras() getter chain). Thus, variable url in plication) by exploiting the unsafe dynamic Fragment load- loadUrl(...), flowing into the loadUrlIntoView call, opens ing process. was indeed able to take advan- IntentDroid the opportunity for an attack. This variable is defined as tage of this weakness in several applications — including the value of the ’url’ extra parameters, which can be set Gmail, Google Translate and Dropbox — by targeting the externally. Thus, a malicious caller could launch the Activ- show_fragment field with Fragment class names from the ity with an Intent whose respective Bundle maps ’url’ to Android framework and providing corresponding arguments an unintended value. The provided URL will consequently via the show_fragment_arguments field. be loaded by Cordova and rendered within the WebView. As a notable example, was able to inject IntentDroid This vulnerability enables theft of sensitive data (such as integrity payloads via the input Bundle in Android’s built- login credentials) owned by any Cordova-based app having in Settings app, where PreferenceActivity is used. The the vulnerable WebView embedded in a public Activity. We vulnerability detected by IntentDroid allows a malicious emphasize that in the described scenario, the ’url’ extra app to load an instance of ChooseLockPasswordFragment parameter is fetched directly from the extras Bundle. and feed data into it despite its normal instantiation under IntentDroid was able to successfully detect this nontriv- a non-exported activity. A user can then bypass insertion ial vulnerability using its ability to track indirect accesses to of the old PIN number when changing PINs by setting the extra parameters, as described in Section 4.2. We disclosed confirm_credentials field to false. this acute issue to the Cordova team as CVE-2014-3500. We have reported this severe issue to the Android security The Cordova team has issued a patch starting version 3.5.1 team. In response, they created a patch for PreferenceAc- of the framework. tivity starting Android 4.4 KitKat. The patched class con- File Manipulation in the Firefox Browser. Public class tains a new method, isValidFragment(String fragment- org.mozilla.gecko.CrashReporter extends Activity. Its Name), where the Android SDK clearly states that“[s]ubclasses purpose is to send crash dumps to Mozilla when the Firefox should override this method to verify that the given fragment browser treminates unexpectedly. CrashReporter, a sub- is a valid type to be attached to this activity”. class of Activity, receives the dump file path as input via XAS Weakness in Apache Cordova. an extra Intent parameter called minidumpPath. When this Apache Cordova is among the most prevalent Android Activity is launched, its onCreate(...) method is executed, frameworks, serving as the basis of 5.8% of all Android ap- triggering the following sequence of actions: plications and 1.2% of the top 500 apps in the Google-Play 1. Using the moveFile(...) method, the current dump store.5 Cordova exposes a set of APIs that allow the de- file is moved to the pending dump-files path: files/- veloper to access native device functionality, such as the mozilla/Crash Reports/pending. camera or accelerometer, from JavaScript. Combined with 2. A metadata filename is derived from the given dump a UI framework like jQuery, Cordova enables the develop- file path by replacing all occurrences of the .dmp file ment of smartphone apps based only on HTML, CSS and extension with .extra. JavaScript. This is forming into a strong trend. Indeed as 3. The metadata file is subsequently moved to the pend- of July 2014, 7.8% of all new apps (30 days old or younger) ing dump-files path using the moveFile(...) method. are built atop Cordova, which indicates that Cordova is in- 4. The metadata file is parsed into key/value format. The creasingly gaining popularity. target server’s URL (i.e., the URL of the server that 5http://www.appbrain.com/stats/libraries/details/ the crash information is sent to) is specified there using phonegap/phonegap-apache-cordova the ServerURL key. 5. The CrashReporter dialog is displayed to the user. et al. [15], performs dynamic security analysis of Android 6. Finally, when the user presses either the “Close” or apps to detect malware as well as grayware apps. AppsPlay- the “Restart” button with the “Send report” checkbox ground has a modular deign, enabling usage of different ex- enabled, the dump file — along with other sensitive ploration techniques, including event triggering, fuzz testing information — are sent to the specified server by in- and context-sensitive crawling. The choice of detection tech- voking the sendReport(...) method. Note that if the nique is also modular, permitting e.g. taint tracking, API user further checks the “Include the address” checkbox, monitoring and kernel-level monitoring. then Android logs are sent as well. Verification. The ComDroid tool, developed by Chin et The security problem created by this scenario traces back al. [1], detects IAC vulnerabilities statically. Specifically, to CrashReporter and its treatment of the minidumpPath ex- ComDroid performs bounded interprocedural flow-sensitive tra parameter as trusted, where in fact it should be treated tracking of Intent objects with sensitivity to Intent proper- as untrusted, as it is specified by an external agent. Indeed, ties, such as whether the Intent contains extra parameters an adversarial agent can manipulate the source path of the or defines an action. The Epicc analysis tool, by Octeau et moved file as well as the deduced extra file. This manipula- al. [12], has a similar scope. It achieves better scalability tion enables control over the server that the crash dump is than ComDroid by modeling the discovery of communica- reported to, in addition to controlling the path of the crash tion instances as Interprocedural Distributive Environment dump file, which allows theft of sensitive information. (IDE) problems [16]. We have disclosed this issue as CVE-2014-1506 to the The CHEX system, developed by Lu et al. [8], vets An- Mozilla security team, which released a fixed version shortly droid apps for component hijacking vulnerabilities by means afterwards.6 IntentDroid was able to detect this issue by of flow- and context-sensitive data-flow analysis. The au- discovering the minidumpPath extra parameter and record- thors report on an evaluation of CHEX over 5,486 Android ing calls to File.renameTo(...) and File.createNewFile(), apps, 254 of which were found vulnerable. wherein the initialized File object is mapped to a user- Prevention. Kantola et al. [7] address IAC vulnerabil- controlled path. ities due to (i) exposure of app-internal messages to third parties or (ii) receipt of external messages by internal com- ponents of the app. As a solution, they propose to harden 7. RELATED WORK the Android heuristics to determine the eligible senders and We survey related studies on Android testing and security. recipients of messages. Though we focus mainly on testing, we also highlight related Another proposal, by Cozzette et al. [2], is to revise In- research in the areas of verification and prevention. tent handling such that the system can only err on the Testing. Maji et al. [10] conduct an experimental evalu- safe side. Contrary to the current design, whereby a de- ation of the robustness of IAC in Android. In their experi- veloper may inadvertently create opportunities for another ments, they perform fuzz testing with illegal Intent inputs, app to inject a malicious Intent or intercept outgoing In- e.g. with blank or random action or data fields, random ex- tents, Cozzette et al. propose a model that disables all such tras, etc. Their results indicate that exceptional situations behaviors unless these are requested explicitly by the devel- are often handled poorly, and under certain conditions can oper. This does not remove integrity threats, however, as even cause the Android runtime to crash. erroneous handling of incoming Intents remains possible. Somewhat similarly, Sasnauskas and Regeher [17] develop Luo et al. study the WebView component, which enables a fuzzing framework for Intents with the goal of trigger- an app to embed a browser in its UI (cf. Section 2). They ing interesting bugs (including crashes) that have previously observe that WebView diverges from standard browsers in been unknown. Their fuzzing technique combines static that both sandbox protection and the client-side Trusted analysis with random test-case generation. Findings due to Component Base (TCB) are weakened, and identify secu- their system include crashes in dozens of core Google as well rity threats that arise as a consequence. They also propose as Google Play apps, which in some cases result in complete potential solutions to prevent such attacks. OS reboot. Yang et al. [21] present IntentFuzzer, a fuzzing tool that 8. CONCLUSION AND FUTURE WORK analyzes mobile applications for capability leaks (aka permis- sion redelegation). These occur if an app owns the permis- We have presented IntentDroid, a comprehensive test- sion to access a sensitive resource (or set of resources) and ing algorithm for (inbound) IAC integrity threats, which can be manipulated into performing such an access on be- is available as a commercial cloud service. IntentDroid half of another application that lacks the permission. Yang maintains a feedback loop, such that custom IAC parame- et al. report that 161 out of 2,000 Google Play apps they ters detected on the fly are later explored and tested. Path tested have this weakness. exploration is governed by efficient manipulation of boolean Ye et al. [22] create a fuzzer specifically for Activitys IAC parameters. IntentDroid currently tests for eight dif- that accept external MIME data. These are discovered via ferent IAC attack vectors. In our experiments over 80 top- analysis of the