MuTent: Dynamic Android Intent Protection with Ownership-Based KeyDistribution and Security Contracts

Pradeep Kumar D S1, Jaejong Baek2, Tiffany Bao2, Yan Shoshitaishvili2, Adam L Doupe2,Ruoyu Wang2, and Gail-Joon Ahn2

Arizona State University1{pradeepkumarst}@gmail.com

2{jbaek7, tbao, yans, doupe, fishw, gahn}@asu.edu

Abstract

Intents are the plain-text based message object usedfor ICC by the Android framework. Hence the frameworkessentially lacks an inbuilt security mechanism toprotect the visibility, accessibility, and integrity ofIntent’s data that facilitates adversaries to intercept ormanipulate the data.

In this work, we investigate the Intent protectionmechanism and propose a security-enhanced Intentlibrary µTent that allows Android apps to securelyexchange sensitive data during ICC. Differently fromthe existing mechanism, µTent provides accessibilityand visibility of Intent data by validating the receiver’scapability and provides integrity by using encryptionand the Arc security contract code. Especially, ICCis initiated by exchanging µTent and follows a novelownership-based key distribution model, that restrictsthe malware apps without permission from decipheringdata. Through the evaluation, we show that µTent canimprove the security for popular Android apps withminimal performance overheads, demonstrated usingF-Droid apps.

1. Introduction

Intents are messaging object in the Android platformused to coordinate an activity, start a service, oras payload carrying sensitive data, operations, andactions to be performed by the target component (forexample, the BroadcastReceiver or IntentService).Utilizing Intents without well-defined securitymechanism inevitably exposes the system to threats likebackdoors, which attackers can use to intercept sensitiveinformation. For example, CVE-2018-9489 [1] reportsan unintentional information leak, where the Android’sWiFi module leaks the MAC address of the device toall the registered component’s without validating thereceiver’s permissions.

There are mechanisms to prevent a malwarecomponent from receiving the Intent data. Thesemechanisms prevent Inter-Component Communication(ICC) attacks by statically analyzing the DEX filesand dynamically monitoring to detect securityvulnerabilities [2, 3]. SALMA [4] builds aMultiple-Domain-Matrix (MDM), and incrementallyanalyzes the App security in response to incrementalsystem changes. Barros et al. [5] present a staticprogram analysis where the developer can annotate theIntent data with security levels, thereby restricting dataflow across incompatible source and sink.

With these filtering techniques, we can protectIntent flow across apps, however, protecting Intentsdynamically from content pollution and informationconfidentiality through encryption of data have notbeen fully covered for practical use. For example,an intermediate component may pollute the Intent databy direct mutation or through reflection, thereby allthe information that is used and forwarded by thatsubsequent component will be corrupted. The resultis an epidemic propagation of a corrupted Intent whichwill be multiplied upon further propagation.

In terms of the confidentiality issue, EventGuard [6]proposes a mechanism to guard the information ina pub-sub environment through encryption. It usesa meta-service layer that connects the subscriber andpublisher based on the filter. However, EventGuardtreats every subscriber as equal with the samecapability. This may not be applicable for Android,since in Android every app (subscriber) shouldbe treated differently based on the capability ofapplication (i.e. security properties defined in theirAndroidManifest.xml and acquired at runtime by usergranting/revoking permissions). Thus, any changes inApp’s permissions make an impact on the capabilityof corresponding App’s component’s. Overall, thelack of a holistic security framework having bothintegrity and confidentiality is a primary challenge in

Proceedings of the 54th Hawaii International Conference on System Sciences | 2021

Page 7217URI: https://hdl.handle.net/10125/71490978-0-9981331-4-0(CC BY-NC-ND 4.0)

Table 1: Types of Android Intent Attack. [Note: Tr =Benign; Mr = Malware; Aa=Active Attack; Pa=PassiveAttack; Cb = Channel Based; Ib = Intent Based]

Receiver’s Type ModeVulnerability

TypeUIR Mr Leak Pa (Cb, Ib)PE Mr Leak (Aa, Pa) (Cb, Ib)IM Tr or Mr Mutation Aa (_ , Ib)

Android system to protect the Intents during ICC. Inthis paper, we propose µTent, a secure and pluggableIntent library supporting encryption of Intent data,an ownership-based key generation and distributionmechanism, and dynamic verification of receiver’scapability and access privileges.µTent has three enhanced security features:

(1) dynamically verifying the sender and receivercapabilities for subset property, i.e. the source (senderor publisher) component’s capability must have asubset relationship with the sink (receiver or subscriber)component’s capability; (2) µTents carry securitycontract code written in our own domain specificlanguage called Arc explained in §3.3, that will beverified dynamically before granting/revoking accessto the receiver; (3) µTents are encrypted and the keyis withheld by the µTent’s owner, receiver componentmust pass conditions (1) and (2) to receive the key.

In summary, µTent provides the followingadvantages: firstly, capability-based access guaranteesthat µTent is secure wherever it goes; secondly, the Arccontracts (called simply as contract) can control notonly the legal information flow in ICC but also the legaloperations such as accessibility and visibility that areallowed on the Intent data; finally, every µTent objectis dynamically encrypted by its owner, and makesany access satisfy the above two conditions to fetchthe decryption key from µTent’s owner. To the bestof our knowledge, µTent is the first holistic securityframework that handles dynamic Intent mutation andinformation confidentiality.

As a proof of our mechanism, we have implementedµTent as a pluggable Java Library, which can be usedby developer’s at the application layer by replacingAndroid’s Intent library.

2. OverviewIntent-based communication may not trust thepublishers and subscribers, and may not trust thetransit path as well. A study of 7,406 applicationsby Ali Feizollah et.al. [7] found that 91% of theapplications are using Android Intents to communicate

(a)

(b) Code.Figure 1: Unauthorized Intent Receipt Attack.

across components, among which 28.78% are implicitIntents, where the receiver component is decided by theAndroid framework, thereby creating a potential riskof leaking information to malicious components, and71.22% apps uses explicit Intents that may introducemutation attacks where the receiver component canmutate the Intent data consciously or fortuitously.

We present three types of common Intent-basedattacks (see Table 1), that actively or passively confrontsthe Intent data security, two Intent leak attacks and oneIntent mutation attack that impair the confidentialityand privacy of Android’s ICC. Unauthorized IntentReceipt (UIR) and Privilege Escalation (PE) are thepassive attack model where the malicious receiver (Mr)remains stealthy sneaking Intent information directlyor indirectly from the source. For example, theAndroid WiFi module (tested on AOSP v8.1.0_r70)leaks the device sensitive information such as (the WiFinetwork name, BSSID, local IP addresses, DNS serverinformation and the MAC address) to all registeredapplications running on that user device irrespectiveof the application’s capability (permissions declared inAndroidManifest.xml and actual permissions granted bythe user) (CVE-2018-9489 [1]). In privilege escalation,a malware component acquires sensitive informationindirectly through a privilege component by usingits loophole. In active mutation attack, the attacker(Tr) intercepts the transit Intent data and modifies theinformation that affects the behavior of the componentsfurther.

2.1. Motivating ExampleWe demonstrate our examples with the following fourcomponents: benign component A (acts as source)

Page 7218

(a)

(b) Code.Figure 2: Privilege Escalation Attack.

with capability Ca= (LOCATION, READ_CONTACTS), acrafted component B with capability Cb= (LOCATION,READ_CONTACTS), that can act either as benign (2.1.1)or as malware (2.1.2), the malware component C withcapability Cc= (INTERNET), and the benign componentD with capability Cd= (LOCATION, READ_CONTACTS).

2.1.1. Intent Leak Attacks. UIR - As shown inFigure 1 A broadcasts the Intent with sensitiveinformation (i.e., device locations) to B, (Figure 1b),using action ("NotifyLocationChange"). Now byregistering to the action ("NotifyLocationChange") themalware component C sniffs the transit Intent from A(shown in Figure 1a), thereby gaining access to thesensitive information.

PE - In this case C without location permissionindirectly accesses the location data through the benignB (Figure 2b 1 , 2 ). B receives the locationinformation from A (Figure 2b 3 ) and broadcasts it tothe C (Figure 2b 4 , 5 ).

2.1.2. Mutation Attack. This is a type of insideattack, where the receiver is a trusted componentperforming an active attack on the intent by modifyingthe data consciously or fortuitously and passing to othercomponents further. We demonstrate a similar examplein Figure 3a, (1) A receives the following details -sender and receiver account numbers, amount, and bankcode, (2) B validates the sender and receiver accountnumbers, bank code, and the amount before initiatingsending process, and (3) D processes the money transfer

(a)

(b) Code.Figure 3: Intent Mutation Attack.

from sender to receiver account. Here, B is performingmutation-attack by modifying the account number andthe amount using the hard-coded values or inputstaken from other side-channels [8], Figure3b. Now Dprocesses money transfer on the mutated data. This typeof attack introduces unpredictable security issues thatare difficult to capture using application capability orstatic analysis. Failure of data integrity and data securitycreates attacks such as man-in-the-middle attacks [9,10]where the attacker can modify the transit data that maylead to a catastrophe in the banking applications.

2.1.3. Challenges. The Intent flow defines thesource component from where the Intent originates andthe sink component of Intent. Android initiates ICC bycreating the Intent inside the receiver context. Sincewe focus on providing Intent-based ICC filtering, itbecomes challenging to restrict ICC from Intents beforecreating Intent inside the receiver’s context. Once Intentis created within receiver’s context the receiver obtainscomplete control over the Intent object by gainingaccess the Intent object through direct API or throughreflection, i.e., data once copied into the memory of anuntrusted application can be exported thereby failed toachieve data secrecy [11].

The channel-based attacks are handled by filteringthe receiver’s through capability subset mechanism(§3.4), i.e. source’s components capability (Cs) shouldbe subset of the subscriber’s capability (Cr) (i.e. Cs ⊆Cr)). This approach ensures the confidentiality andaccessibility, however the guarantee for integrity is notaddressed here.

On the other hand, the Intent-based mutationattack happens even if the receiver is benign. Thisproblem requires limiting the receiver from performing

Page 7219

Figure 4: µTent Life Cycle.malicious operations on the Intent data like mutating theinformation.

To this end, we identified three major challengesin protection against Intent-based attacks to ensureconfidentiality, accessibility and integrity: (1)encrypting the Intent object so that the maliciousreceiver cannot eavesdrop the Intent bypassing thevalidation process, (2) dynamically validating thecapability within the receiver’s context, (3) limitingmutation on Intent data.2.1.4. Approach and Assumptions. UIR in Figure1 and PE in Figure 2, the component A (publisher) hasa capability subset relationship with B (the subscriber)(i.e. Ca ⊆ Cb), therefore, B being the superset of A hasall capabilities that A has and hence we recognize B asbenign. Being benign B can access the Intent data fromA, although the operations on Intent data (i.e. mutation)are not guaranteed. On the other hand, the componentC does not have superset relationship with componentA or B (i.e. (Ca ∨ Cb) * Cc). Therefore componentC cannot even access the Intent, thus we recognize C asmalware.

The Intent-based mutation attack requires thedeveloper to send a runtime Arc contract along with theIntent specifying its mutable or immutable nature duringthe transit. The Arc contract imposes the permittedoperations and visibility restrictions of the receiverwithin the receiver’s context. The contract is addedduring Intent creation and cannot be modified later.

Currently, our model has limits to handle thefollowing types of leaks: 1) log leaks - leaking the dataextracted from the Intent object to the log channels; 2)creating a new Intent object by copying the data fromthe original Intent and distributing it further along thetransit path. µTent protects the Intent at object levelusing encryption and dynamic contracts rather than atthe object’s data level.

3. µTentIn this section, we present the design and architectureof µTent. µTent is a secure and pluggable Intentlibrary supporting encryption of Intent data withan ownership-based key generation and distributionmechanism and dynamic verification of receiver’scapability and access privileges. µTent encrypts theextras and data attributes, however, does not encryptaction, category, type, component that are used byAndroid framework for ICC, and the owner’s UniqueResource Identifier (URI) and Arc contract.

3.1. µTent Primitives

Each µTent has two parts, (1) the µTent owner (forencryption key generation and distribution, and receivercapability validation) and (2) the Arc contract definesadditional access restrictions/capabilities imposed onthe receiver. The owner [12] provides a logicalencapsulation boundary to the µTent object. Beforeinitializing the µTent at the receiver’s context, thereceiver’s context should be authorized by the µTent’sowner by validating the receiver’s capability and the Arccontract (if given).

Formally, the relationship between µTent andits corresponding owner (O) can be represented asµTent � O. The symbol � is known as within (ordominated by) relationship, says that the owner (O)encapsulates the µTent with a capability-based logicalboundary, protecting µTent from any unauthorizedaccess from outside the ownership boundary. Thereby,all access to the µTent must pass through itscorresponding owner (O). This ownership propertyensures that possession of a µTent object by a receiverdoes not imply permission to access the information ofthat µTent. Additionally, the Arc contracts control’s thelegal operations allowed on the Intent data.

3.2. µTent Life Cycle

ICC initiates µTent’s lifecycle by exchanging µTentacross component’s. Figure 4 shows various states inthe µTent’s lifecycle from the creation to the destructionof the µTent.

3.2.1. Creating µTent Owner. The pseudo code isgiven in Algorithm 1. It takes the µTent current context,the Arc contract, and the current timestamp from theenvironment. First the creation process verifies thecorrectness of the Arc version (mismatch in versionthrows an exception). Then the owner’s unique ID isgenerated UUID, and the timestamp (ts). The owner

Page 7220

Algorithm 1: Creating µTent OwnerInput: µctx: µTent Context InstantiatedInput: ARC: Arc ContractInput: ts: timestamp

1 ArcVersion← checkArcVersion(ARC)2 if ¬ArcVersion then3 throw version_error() //version mismatch4 UUID← genRandomUUID()5 OID← genOwnerID(ts, UUID)6 µo← createOwner(OID)7 µo← initOwner(ARC)8 Pk← genSecretKey() ∈ µo9 (µk ∈ µctx)← Pk

Output: µo: µTent Owner CreatedOutput: µk: µTent Secret Key from µoOutput: µobj: µTent owned-by µo

then initiate the call to generate a secret key (Pk). Thegenerated key (Pk) is stored into the owner µo.

3.2.2. Accessing µTent Object. The pseudo code isgiven in Algorithm 2. When µTent receives request forget/set methods of Intent data, the µTent validates thecurrent context capability and privileges. On successfulverification, the µTent will request the owner for thesecret key (Pk). This shared secret key is used by theµTent to decrypt the Intent data.

Algorithm 2: Accessing µTent ObjectInput: µobj: µTent ObjectInput: ARC: µTent’s Arc ContractInput: ts: timestamp

1 µo← µobj.owner()2 VERIFY← µo.verify(µctx, ARC, ts)3 if ¬VERIFY then4 throw Permission_Exception() //no permission5 µobj.invoke()6 VAL← Pk()← µo.KEY()

Output: VAL: Decrypted/Encrypted Value

3.2.3. Migrating µTent Object. The pseudo code isgiven in Algorithm 3. Migration process gets initiatedduring ICC: startActivity, sendBroadcast, startService,startActivityForResult, etc. Migration consists of threesteps: (1) the µTent sends a signal to its correspondingowner to wait till it validates the receiver’s contextbefore recreation. (2) The µTent’s data will be encryptedwith the secret key, (3) The secret key is purged fromthe µobj, (4) followed that, the owner ID is added toµobj, (5) finally, µobj is parceled and migrated from thecurrent context to the receiver’s context.

3.2.4. Recreating µTent Object. The pseudo codeis given in Algorithm 4. Inside the receiver’s context,first the µTent communicates to its source owner, bysending the Arc contract, receiver’s capability and timestamp. Upon successful verification, the owner will sendthe secret key to the µTent. On verification failure, theµTent will not get its decryption key.

Algorithm 3: Migrating µTent Objects’Input: µobj: µTent ObjectInput: ARC: µTent’s Arc ContractInput: µctx.parcel() : Initialize MigrationInput: ts: timestamp

1 µo← µobj.owner()2 VERIFY← µo.verify(ARC, ts)3 if ¬VERIFY then4 throw Migration_Exception() //no permission5 INIT-BROADCAST← µobj.onBroadcast(µo)6 ENCRYPT← µobj.encrypt()← Pk← µo.KEY()←µo.encrypt()

7 PURGE← µobj.purgeKey()← µo.purgeKey()8 BIND-OWNER← µobj.bindOwner(µo)9 PARCEL← µobj.parcel()

Output: PARCEL: Parceled µTent object

Algorithm 4: Recreating µTent ObjectInput: PARCEL: Parceled µTent objectInput: µobj: µTent ObjectInput: µrctx: µTent Receiver ContextInput: ARC: µTent’s Arc ContractInput: ts: timestamp

1 µo← µobj.owner()2 VERIFY← µo.verify(µrctx, ARC, ts)3 if ¬VERIFY then4 throw Unbox_Exception() //no permission to unbox5 µobj.KEY← Pk← µo.KEY()

Output: µobj.KEY: Key from OwnerOutput: VAL: Decrypted/Encrypted Value

3.2.5. Destroying µTent Object. µTent destructionstate pseudo code is given in Algorithm 5. Here, theµTent sends an notify signal to its owner. Followed by,purging the secret key, and µTent’s destroy signal to itscorresponding owner. The destroy signal removes theµTent’s dependency from its owner, and now the ownercan self-destruct itself.

Algorithm 5: Destroying µTent ObjectInput: µobj: µTent ObjectInput: µo: µTent OwnerInput: µobj.destroy(µo) : Initialize DestructionInput: ts: timestamp

1 SIGNAL-OWNER← µo.notify(ts)2 PURGE← µobj.purgeKey()← µo.purgeKey()3 KILL-OWNER← µobj.destroy(µo)

Output: KILL: µTent object is removedOutput: KILLopt: µo removed iff no dependent µobj

3.3. Arc Language Specifications

The Arc is a design by contract language, withbasic constructs for Android security. The Arcfollows annotation such as syntax similar to JML [13].The current Arc implementation supports eight basicconstructs: (1) @sameProcess; (2) @sameTask; (3)

@read; (4) @write; (5) ∧; (6) ∨; (7) ¬; (8)impl−−→.

The Arc grammar is given in Figure 5. Constraintsdescribe the receiver’s context, and the access keyword

Page 7221

is used to specify the accessibility. The meta variable Prange over the contracts. The meta variable OP describethe logical operators.

@sameProcess: It limits µTent’s visibility andaccessibility within the same process (source) thatcreated the µTent, thereby component’s from differentprocesses cannot access the µTent information. Bydefault, µTent is accessible across processes.

@sameTask: It ensures that the receiver’s task IDand task affinity (in case of BroadcastReceiver andIntentService) is same as the source’s task ID and taskaffinity. By default, µTent is accessible across task.

@read: It protects the µTent data from any future(unintended) modifications. Negation of read specifiesthat the µTent cannot be read by the receiver. For

example the Arc contract "¬@sameTask impl−−→¬@read"specifies no read constraint to the receiver’s’ belongsto different task. That is receiver’s from different taskcannot read the data. Under this condition the receivercan only forward/drop the µTent and cannot consumeany information from it as they are protected withencryption.

@write: It enables µTent data to get modified, bydefault µTent is writable. Negation of @write (i.e.¬@write) means that the µTent is read-only.

∧ | ∨ | ¬ : The logical represents general math logicfor AND | OR | NOT operation respectively.

impl−→: The implication operation can be expressed

as (X impl−−→ Y), where Y becomes the resultant for theoperations defined in (X). Y will be evaluated iff theoperation defined in (X) results true.

3.4. µTent’s Subset Properties

µTent follows subset property to classify thecomponent’s as either (1) Benign, or (2) Malware.By default µTent source is labeled as benign. Thereceiver is labeled as benign iff the sender’s capability(Cs) forms a subset of the receiver’s capability (Cr),i.e. Cs ⊆ Cr, else the receiver is labeled as malware,i.e. Cs * Cr. By default, empty permission (i.e.when an application doesn’t define any permissionsin AndroidManifest.xml) is considered as a specialpermission. Therefore, if the receiver’s has an emptycapability (Cr = {∅}) and the sender has read contactscapability (Cs = {READ_CONTACTS}) thenreceiver’s capability is not a subset of the sender’scapability (Cr 6⊆ Cs).

P ::= (contract (impl−→ access)opt)∗

contract ::= constraint (OP constraint)∗

constraint ::= @sameProcess| @sameTask

access ::= @read| @write

OP ::= ∧ | ∨ | ¬

Figure 5: Arc Grammar

4. EvaluationWe have implemented µTent as a pluggable Java Libraryfor Android (8.1+). µTent library contains 11 files andapproximately 2,000 lines of code. We present ourevaluation report for µTent tested using the followinghardware: Android 8.1.0 (Oreo, SDK Version = 27),OnePlus 3T device with Snapdragon 821 CPU and 6GBRAM.

4.1. Data Set

Our benchmark application consists of the followingcomponent’s: (1) Compo(n,∗) can be either activity orbroadcast receiver’s or Services, where n representsprocess/task/task-affinity to which the componentbelongs and ∗ represents component capability (Benign(P) or Malware (LP)).

We evaluated µTent’s accuracy by creating arepository of 288 applications (shown in Table 3)with total 276 vulnerable paths taken from existingbenchmarks [14,15] and added our own ICC applicationswith the following programming practices such as:data mutation, read-only, no-read, and encryption. Inaddition to the above benchmark, we have also testedµTent with the SEALANT benchmark, which consists of135 apps with total 59 vulnerable paths.

In our test, we fixed the Arc contract (i.e.DEFAULT ∧@read) for all the examples presented inTable 2. The rule DEFAULT represents the permissionsubset property (§3.4), encryption property (§3.2) ofthe µTent and "@read" constraint enforce the read-onlyproperty on the µTent within the receiver’s context.

The application set from (1-6) in Table 2 consists ofa total 72 apps demonstrating the scenario of sniffingbetween component’s across different process and task.In the application set (3,6), the receiver being benignperforms mutation attack on µTent data. Though suchattacks are generally assumed safe, in certain scenarioslike (§2.1) it is required to limit mutation in order toensure integrity of the data. Such attacks are classifiedas tricky ICC which µTent handles by using "@read"Arc contract limiting mutation of Intent data.The application set (7-12) in Table 2 consists of 162apps with 162 vulnerable paths. In total we have 210vulnerable paths demonstrating the scenario of UIR and

Page 7222

Table 2: Detailed Comparison

- Name[Tot.Apps] Covered Attacks Model (Component(1,∗) −−→Ln

Component(2,∗)) Arc Contract µT‡ SE§ FP FN

1 sameP1[6] UIR,PE Compo(1,P) −−→Lk1

Compo(2,P) arcc

2 sameP2[24] UIR,PE Compo(1,P) −−→Lk1

Compo(2,LP) arcc

3 sameP3[6] IM Compo(1,P) −−→Lk1

Compo(2,P) # [Im] arcc # �

4 sameT1[6] UIR,PE Compo(1,P) −−→Lk1

Compo(2,P) arcc

5 sameT2[24] UIR,PE Compo(1,P) −−→Lk1

Compo(2,LP) arcc

6 sameT3[6] IM Compo(1,P) −−→Lk1

Compo(2,P) # [Im] arcc # �

7 redel1[27] UIR,PE Compo(1,P) −→L1Compo(1,P) −−→

Lk2Compo(2,LP) arcc

8 redel2[27] UIR,PE Compo(1,P) −→L1Compo(1,P) −→

L2Compo(2,P) arcc

9 redel3[27] UIR,PE Compo(1,P) −→L1Compo(2,P) −→

L2Compo(3,P) arcc

10 redel4[27] UIR,PE Compo(1,P) −→L1Compo(2,P) −−→

Lk2Compo(3,LP) arcc

11 redel5[27] UIR,PE Compo(1,P) −−→Lk1

Compo(2,LP) −−→Lk2

Compo(3,P) arcc

12 redel6[27] UIR,PE Compo(1,P) −−→Lk1

Compo(2,LP) −−→Lk2

Compo(3,LP) arcc

13 InMut1[27] IM Compo(1,P) −−→Lk2

Compo(2,LP)⇒ [Im]−→L1Compo(3,P) arcc

14 InMut2[27] IM Compo(1,P) −−→Lk2

Compo(2,P) # [Im]−→L1Compo(3,P) arcc # �

Note:‡=MuTent; §=SEALANT; = provides property; # = does not provide property; Ln = safe paths;Lkn = vulnerable paths; # = tricky intent operations ⇒ = direct/indirect intent operations Im = Intent Mutation Attack; = False Negative (µTent); � = False Negative (SEALANT) arcc = [DEFAULT ∧ @read]

Table 3: µTent Evaluation.

Attacks Tot.Apps Tot. VulnerablePaths Blocked (µT) Blocked (SE)

(no.,%) (no.,%)

UIR 111 105 105(100%) 105(100%)PE 111 105 105(100%) 105(100%)IM 66 66 66(100%) 27(40.91%)Total 288 276 276(100%) 237(85.87%)

PE. µTent blocks all the 210 vulnerable path by usingits "DEFAULT" property of validating the sender andthe receiver’s capability as discussed in §3.4.

Finally, we have added a collections of 54 appsto demonstrate mutation-attacks (13,14). The attackscenario (13) has been filtered easily by µTent byvalidating the capability subset property, thereby themalware receiver Compo2,LP cannot access the data.However, in attack scenario (14) the benign componentis mutating the data. In order to handle such class ofattacks, we used the "@read" Arc contract that specifiesread-only operation to the receiver (Compo2,P), therebylimiting the receiver from modifying the data.

4.2. Effectiveness

Table 2 presents the detailed comparison between µTentand SEALANT [2]. The attack scenarios (3, 6, 14)demonstrates tricky operations performed by trustedcomponent’s, where the transit ICC path consists of only

Table 4: µTent Overall Impact (%).

Apps

Intent

Creation

Time(ms)

µTent

Creation

Time(ms)

µTent

Overall

Dif.(ms)

µTent

Overall

Impact(%)

Ads Droid 0.45 14.2 13.75 0.0046

Activity Diary 0.77 14.0 13.23 0.0044

Face Slim 0.75 9.75 9.0 0.0030

benign component’s, which creates difficulty to restrictaccess based on receiver’s capability and hence filteringonly based on the component’s capability may result ina False Negative outcome.

The other similar tools/methodology available inliterature are XmanDroid [16,17] (a policy based model)and Sparta [5] (a static tool to identify the taint-flow).XmanDroid uses application level policies to blockvulnerable paths. It demands the user to specify thepolicy defining the vulnerable ICC path. Absence ofpolicy makes XmanDroid to allow every ICC, that iswithout such policy all the component’s are assumedbenign by default.µTent differs from XmanDroid by performing

permission subset validation of the receiver by default(without requiring an explicit policy specification),and protecting the payload with an ownership-basedencryption model. µTent considers the followingapplication-level covert channels [18] such as:

Page 7223

Figure 6: Overall Creation Time Overhead

broadcasts, system services, or content providersthat uses Android’s Intent sharing as communicationmedium and not any other covert channels. Also in thispaper we are not considering the other operating-systemlevel or hardware-level covert channels [19, 20] suchas: file system, database, log, cache memory etc. µTentuses dynamic verification of the receiver based onreceiver’s capability and the Arc contract, rather thanstatic taint analysis of source-code such as Sparta,or static apk analysis for vulnerable paths such asSEALANT.

4.3. Performance

Table 3 shows the overall impact of the µTent. Weevaluate by analyzing the number of vulnerable pathspresent and the number of paths µTent’s can identifyas vulnerable, and can block by throwing exception.The test result is from the outcome of evaluating theµTent benchmark consisting of 288 total apps (§4.1).The benchmark consists of a total 276 vulnerable paths,out-of which µTent can identify and block 276 paths (i.e.100% success), and SEALANT has 85.87% accuracy byblocking 237 paths.

Additionally, we tested µTent with the SEALANTbenchmark, which consists of 135 apps with total 59vulnerable paths. In this test, µTent was able to identifyand block 112 apps (with an accuracy of 82.96%) and48 vulnerable paths (with an accuracy of 81.36%) thatconsists of redelegation attacks and Intent data access.

4.4. Creation Time Overhead

Since µTent object requires an additional dynamicowner creation along with a complex algorithm forencryption and key distribution, it becomes necessaryfor us to calculate the time taken to create a µTent so thatwe can calculate the overall impact µTent can imposeon an application. Hence in this section we discussthe average creation time and its impact ratio based onour current µTent library implementation. We testedµTent by modifying three open source projects takenfrom F-Droid, and modified the Intent with µTent library(shown in Table 4). On an average µTent took ∼11.5

Ads D

roid

Activ

ity D

iary

Face

Slim

0.000

0.001

0.002

0.003

0.004

Ove

rhea

d (%

)

Opensource Apps (F-Droid)Android's Intent time (%)Mutent time (%)Overall Overhead (%)

Figure 7: µTent Implementation Overhead

milliseconds (Figure 7) more than Android’s Intent thatis approximately equivalent to 0.005(%) overhead ina 300,000 milliseconds of an application runtime asshown in Figure 6.We tested µTent using two approaches: (1) usingCulebra - a record and play test environment [21] whereuser interactions can be recorded as python script andcan be played automatically, and (2) manual testing - bygiving the applications to three student volunteers fromour lab and asked them to interact with the applicationrandomly (without any pre-defined screen interactionorder). Even though µTent’s creation time is higherthan Android’s Intent, the overall impact percentageadded by µTent to an applications execution is trivial(i.e. ∼0.005%). Thus with this nominal impact oncreation time, during our testing the users have not feltany latency in the screen response and screen navigation.

5. Related Work

Detecting data-leaks and malicious component’s duringInter Component Communication (ICC) have alreadybeen explored for source code and DEX file. Theseapproaches combines static analysis and runtimepolicies at the OS level (i.e., requires modifying theframework or kernel code). However, µTent is designedand implemented as a pluggable Java Intent library tofilter the data-leaks and malicious component’s duringICC. Encrypting ICC payload is generally treated as aOS layer functionality, which µTent introduce as Intentproperty.

Static Analysis: SEALANT [2] provides a techniquethat combines static analysis of app code inferingvulnerable communication channels and runtimemonitoring of inter-app communication throughthose channels to prevent attacks. SALMA [4],presents self-protecting Android system using aMultiple-Domain-Matrix (a knowledge base), thatwill be updated incrementally and thereby enablingincremental analyzes upon changes to the system.FlowDroid [22] a static taint-analysis reduces false alarm

Page 7224

by detecting the data-leaks based on the context, flow,field and object-sensitivity. Amandroid [23] staticallydetects inter-component control and data flows amongmultiple component’s from either the same or differentapps. Since µTent’s objective is to prevent Intent-basedattacks by creating an Intent library we do not performstatic analysis like the above models; however µTent’sdynamic mechanism for adding contract to the Intenthelps to enable data integrity and to control accessibilityand visibility of the data. ComDroid [24] analyzes theDEX files to detect Intent-based attacks such as Intentspoofing, UIR and Intent vulnerabilities by performingflow-sensitive and intra-procedural static analysis.CHEX [25] approaches the detection problems suchas leak of private data or component vulnerability asdata-flow problem that helps to identify the potentialrisk from the existence of flow pattern. AnFlo [26]proposes a mechanism to detect anomalous sensitivedata flows in Android apps by grouping trusted appsbased on the categories identified from the appsfunctional descriptions. TERMINATOR [27] analyzesthe permission misuse by considering the order ofevents that require the time of an event and the securityvulnerability in the Android’s custom permissionmodel. In µTent every ICC call must have a validcapability to access the Intent data, thereby the flowgraph varies in par with the users permission decisionfor that application.

Policies & Filters: Kirin [28] detects the maliciousbehavior by certifying an app using kirin securityrules at install time. DREBIN [29] proposed a methodfor detection of Android malware by uses dynamicinferring of security patterns rather than manuallycrafted patterns [28]. TaintDroid [30], a data-leakdetection tool, suggested a fine-grained tracking ofprivate information and how it is actually used. µTent’scontext-based privacy using dynamic contracts wasinspired from the above works; during ICC everyµTent is controlled by a unique Trusted ComputingBase (TCB) that is created per object. Permissionre-delegation introduces a risk when an applicationwith permissions performs a privileged task for anapplication without permissions. The permissionre-delegation paper [3] proposed IPC inspection atOS level, that reduces a deputy’s (application withpermissions) privileges after receiving communicationfrom a malware application (app without privileges).Consequently, the Android’s permission system candeny a privileged API call from the deputy ifany application in the chain of influence lacks theappropriate permission(s). DroidCap [31] uses Binder

handles as capability tokens by associating Android’spermissions to the handle. DroidCap facilitatesprivilege separation between app’s component’s throughcompartmentalization of component’s into a logical appwith a subset of privileges. Maxoid [32] confinesthe delegates from leaking secrets by creating differentviews of the initiator’s state. The delegates mayupdate initiator private state or public state which theinitiator can selectively commit or discard to preventunwanted modifications by delegates. This may notbe directly applied to Intent data protection, sinceIntent communication creates a uni-directional datadistribution, where the shared Intent data cannot becontrolled by the initiator unless the data is representedas a URI. Aquifer [33] defines UI workflow policieswhere each participating application define its exportlist, a required list, and a workflow filter. Aquifier tracksthe workflow policies to control the interactions acrossdifferent applications who are participating to completethe task. Similarly, in µTent we compare the capabilityof an application before allowing the receiver to accessthe Intent data, since Intent’s are initiated within thereceiver’s context, we provide an additional encryptionmechanism to limit the receiver from accessing the datathrough reflection.

Encryption & Key Distribution: Srivatsa, etal. [6] provided routable attribute protection usingcontent-based routing where the publisher uses eventkey K(e) to encrypt, and subscriber with filter (f) useskey K(f) to decrypt, where K(f) is capability of asubscriber and hence treated equally. On the other hand,the µTent handles subscriber’s based on the capabilityand the Arc contract, rather based on subscription.

6. Conclusion

We have presented µTent, the secure and pluggableAndroid Intent Library written in Java, to securelyexchange intent data across component’s during ICC.µTent is the first holistic model to provide the dynamiccontrol of intents inside the subscriber’s context. Itdiffers from the earlier model in terms of providingdynamic encryption, ownership based key distribution,and verification of the receiver’s context using userdefined security contracts and receiver’s capability.Thereby with µTent, we enable application component’sto sensibly retain the control of their intent data after ithas been shared with the receiver during ICC.

References

[1] “Vulnerability Details : CVE-2018-9489..” https://www.cvedetails.com/cve/CVE-2018-9489.

Page 7225

https://www.cvedetails.com/cve/CVE-2018-9489https://www.cvedetails.com/cve/CVE-2018-9489

[2] Y. K. Lee, J. andg Bang, G. Safi, A. Shahbazian,Y. Zhao, and N. Medvidovic., “A SEALANT forInter-app Security Holes in Android.,” in Proceedings ofthe 39th ICSE, pp. 312–323, 2017.

[3] F. A.P., W. H.J., M. A., H. S., and C. E., “PermissionRe-Delegation: Attacks and Defenses.,” in USENIXSymposium, p. 22, 2011.

[4] M. Hammad, J. Garcia, and S. Malek, “Self-Protectionof Android Systems from Inter-ComponentCommunication Attacks.,” in 33rd ACM/IEEE ASE’18,p. 726–737, 2018.

[5] P. Barros, R. Just, S. Millstein, P. Vines, W. Dietl,M. d’Amorim, , and M. D. Ernst., “Static analysisof implicit control flow: Resolving Java reflectionand Android intents.,” in Proceedings of 30th ASE’15,p. 669–679, 2015.

[6] M. Srivatsa, L. Liu, and A. Iyengar., “EventGuard:A System Architecture for Securing Publish-SubscribeNetworks.,” in ACM TOCS, vol. 29, 2011.

[7] A. Feizollah, N. B. Anuar, R. Salleh, G. Suarez-Tangil,and S. Furnell., “AndroDialysis: Analysis of AndroidIntent Effectiveness in Malware Detection.,” in ElsevierComputers & Security, pp. 121–134, 2017.

[8] M. Heiderich, J. Schwenk, T. Frosch, J. Magazinius,and E. Z. Yang., “mXSS attacks: attacking well-securedweb-applications by using innerHTML mutations.,” inACM SIGSAC CCS’13, pp. 777–788, 2013.

[9] C. M. Stone, T. Chothia, and F. D. Garcia., “Spinner:Semi-Automatic Detection of Pinning without HostnameVerification.,” in 33rd ACSAC’17, pp. 176–188, 2017.

[10] “Man-in-the-Middle Flaw in Major Banking, VPN AppsExposes Millions..” https://www.darkreading.com/mobile/man-in-the-middle-flaw-in-major-banking-vpn-apps-exposes-millions/d/d-id/1330586.

[11] A. Nadkarni, B. Andow, W. Enck, and S. Jha, “PracticalDIFC Enforcement on Android,” in 25th USENIX’16,pp. 1119–1136, 2016.

[12] D. Clarke and S. Drossopoulou., “Ownership,encapsulation and the disjointness of type and effect.,”in 17th ACM OOPSLA’02, pp. 292–310, 2002.

[13] L. Burdy, Y. Cheon, D. R. Cok, M. D. Ernst, J. R.Kiniry, G. T.Leavens, K. R. M. Leino, and E. Poll,“An Overview of JML Tools and Applications.,” inFMICS’03, pp. 75–91, 2003.

[14] “ICC-Bench: Benchmark apps for static analyzinginter-component data leakage problem of Androidapps..” https://github.com/fgwei/ICC-Bench.

[15] “DroidBench 2.0: A micro-benchmark suite to assess thestability of taint-analysis tools for Android..” https://github.com/secure-software-engineering/DroidBench.

[16] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, and A.-R.Sadeghi., “XManDroid: A New Android Evolution toMitigate Privilege Escalation Attacks.,” in TechnischeUniversität Darmstadt, TR-2011-04, 2011.

[17] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer,A.-R. Sadeghi, and B. Shastry., “Towards TamingPrivilege-Escalation Attacks on Android.,” in NDSSSymposium, 2012.

[18] C. Marforio, H. Ritzdorf, A. Francillon, and S. Capkun.,“Analysis of the communication between colludingapplications on modern smartphones.,” in Proceedings ofthe 28th ACSAC’12, pp. 51–60, 2012.

[19] H. Okhravi, S. Bak, and S. T. King., “Design,Implementation and Evaluation of Covert ChannelAttacks.,” in IEEE International Conference onTechnologies for Homeland Security (HST), Waltham,MA, pp. 481–487, 2010.

[20] H. Ritzdorf, “Analyzing Covert Channels on MobileDevices.,” in Master Thesis. ETH Zürich, Department ofComputer Science, 2012.

[21] “Culebra: Generating Ready-to-Execute Scripts forBlack box testing..” https://github.com/dtmilano/AndroidViewClient/wiki/culebra.

[22] S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A. Bartel,J. Klein, Y. L. Traon, D. Octeau, and P. McDaniel.,“FlowDroid: precise context, flow, field, object-sensitiveand lifecycle-aware taint analysis for Android apps.,” inPLDI’14, pp. 259–269, 2014.

[23] F. Wei, S. R. X. O., and Robby., “Amandroid: A Preciseand General Inter-Component Data Flow AnalysisFramework for Security Vetting of Android Apps.,” inProceedings of ACM CCS’14, pp. 1329–1341, 2014.

[24] E. Chin, A. Porter, F. K. Greenwood, and D. Wagner.,“Analyzing Inter-Application Communication inAndroid.,” in Proceedings of the 9th MobiSys,pp. 239–252, 2011.

[25] L. Lu, Z. Li, Z. Wu, W. Lee, and G. Jiang, “CHEX:statically vetting Android apps for component hijackingvulnerabilities.,” in Proceedings of the ACM CCS,p. 229–240, 2018.

[26] B. F. Demissie, M. Ceccato, and L. K. Shar.,“AnFlo: detecting anomalous sensitive informationFlows in Android apps.,” in Proceedings of MOBILESoft,p. 24–34, 2018.

[27] A. Sadeghi, R. Jabbarvand, N. Ghorbani, H. Bagheri,and S. Malek., “A temporal permission analysis andenforcement framework for Android.,” in Proceedings ofthe 40th ICSE, pp. 846–857, 2018.

[28] W. Enck, M. Ongtang, and P. McDaniel, “OnLightweight Mobile Phone Application Certification.,”in Proceedings of the ACM CCS, p. 235–245, 2009.

[29] D. Arp, M. Spreitzenbarth, M. Hubner, H. Gascon,and K. Rieck, “DREBIN: Effective and ExplainableDetection of Android Malware in Your Pocket.,” inNDSS’14, pp. 23–26, 2014.

[30] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung,P. Mcdaniel, , and A. N. Sheth., “TaintDroid: Aninformation-flow tracking system for realtime privacymonitoring on smartphones.,” in 9th USENIX (OSDI’10),pp. 393–407, 2010.

[31] A. Dawoud and S. Bugiel., “DroidCap: OS Supportfor Capability-based Permissions in Android.,” in NDSSSymposium, 2019.

[32] Y. Xu and E. Witchel., “Maxoid: Transparently confiningmobile applications with custom views of state,” inEuroSys’15, pp. 1–16, 2015.

[33] L. Jia, J. Aljuraidan, E. Fragkaki, L. Bauer,M. Stroucken, K. Fukushima, S. Kiyomoto, andY. Miyake., “Run-time enforcement of information-flowproperties on Android,” in European Symposium onResearch in Computer Security, pp. 775–792, 2013.

Page 7226

https://www.darkreading.com/mobile/man-in-the-middle-flaw-in-major-banking-vpn-apps-exposes-millions/d/d-id/1330586https://www.darkreading.com/mobile/man-in-the-middle-flaw-in-major-banking-vpn-apps-exposes-millions/d/d-id/1330586https://www.darkreading.com/mobile/man-in-the-middle-flaw-in-major-banking-vpn-apps-exposes-millions/d/d-id/1330586https://www.darkreading.com/mobile/man-in-the-middle-flaw-in-major-banking-vpn-apps-exposes-millions/d/d-id/1330586https://github.com/fgwei/ICC-Benchhttps://github.com/fgwei/ICC-Benchhttps://github.com/secure-software-engineering/DroidBenchhttps://github.com/secure-software-engineering/DroidBenchhttps://github.com/secure-software-engineering/DroidBenchhttps://github.com/dtmilano/AndroidViewClient/wiki/culebrahttps://github.com/dtmilano/AndroidViewClient/wiki/culebra

IntroductionOverviewMotivating ExampleIntent Leak Attacks.Mutation Attack.Challenges.Approach and Assumptions.

TentTent PrimitivesTent Life CycleCreating Tent Owner.Accessing Tent Object.Migrating Tent Object.Recreating Tent Object.Destroying Tent Object.

Arc Language SpecificationsTent's Subset Properties

EvaluationData SetEffectivenessPerformanceCreation Time Overhead

Related WorkConclusion