Inside Job: Understanding and Mitigating the Threat of External Device Mis-Bonding on Android

Inside Job Understanding and Mitigating the Threatof External Device Mis-Bonding on Android

Muhammad Naveed1 Xiaoyong Zhou2 Soteris Demetriou1 XiaoFeng Wang2 Carl A Gunter1

1Department of Computer Science University of Illinois at Urbana-Champaign2School of Informatics and Computing Indiana University at Bloomingtonnaveed2 sdemetr2 cgunterillinoisedu zhou xw7indianaedu

AbstractmdashTodayrsquos smartphones can be armed with manytypes of external devices such as medical devices and credit cardreaders that enrich their functionality and enable them to beused in application domains such as healthcare and retail Thisnew development comes with new security and privacy challengesExisting phone-based operating systems Android in particularare not ready for protecting authorized use of these externaldevices indeed any app on an Android phone that acquirespermission to utilize communication channels like Bluetooth andNear Field Communications is automatically given the access todevices communicating with the phone on these channels

In this paper we present the first study on this new securityissue which we call external Device Mis-Bonding or DMBunder the context of Bluetooth-enabled Android devices Ourresearch shows that this problem is both realistic and seriousoftentimes an unauthorized app can download sensitive userdata from an Android device and also help the adversary todeploy a spoofed device that injects fake data into the originaldevicersquos official app on the phone Specifically we performedan in-depth analysis on four popular healthmedical devices thatcollect sensitive user information and successfully built end-to-end attacks that stealthily gathered sensitive user data and fedarbitrary information into the userrsquos healthmedical accountusing nothing but Bluetooth permissions and public informationdisclosed by the phone Our further study of 68 relevant device-using apps from Google Play confirms that the vast majority ofthe devices on the market are vulnerable to this new threat Todefend against it we developed the first OS-level protection calledDabinder Our approach automatically generates secure bondingpolicies between a device and its official app and enforces themwhen an app attempts to establish Bluetooth connections with adevice and unpair the phone from the device (for resetting theBluetooth link key) Our evaluation shows that this new techniqueeffectively thwarts the DMB attacks and incurs only a negligibleimpact on the phonersquos normal operations

I INTRODUCTION

With the rapid progress in smartphone technologies andtheir unprecedented popularity come increasingly diverse andinnovative uses of these technologies Todayrsquos smartphoneshave become a platform not only for calls entertainment

and navigation but also for such critical activities as personalfinancial management and healthcare These new applicationsoften rely on the hardware not already built into the smartphoneand therefore need an external device to work together with thephone through Bluetooth Near-Field Communication (NFC)and other channels A prominent example is smartphone-enabled healthcare devices such as blood-glucose meters [10][11] and Electrocardiography (ECG) sensors [1] Such devicesare typically sensors or other data-gathering mechanisms whichleverage the smartphone to preprocess the information collectedfrom a patient before delivering it to more capable systemssuch as web services This utilization of the smartphone ageneral mobile computing system helps reduce the cost ofthose activities but also brings in new security and privacychallenges as the phonersquos security mechanism is not designedfor protecting these external devices

External device protection on Android More specifically letus take a closer look at Androidrsquos security design Its permissionand sandbox security model mainly aims at protecting thephonersquos local resources such as GPS SD-card etc Eachof these resources is guarded by one or more permissionsand can only be used by the Android applications (apps forshort) granted the appropriate permissions by the user Bycomparison no permissions are assigned to an external deviceAll Android can control here is the channel that links thephone to the device such as Bluetooth NFC Audio port etcThe problem is that many devices could all share the samechannel and many apps could all claim the permission to usethat channel for different purposes As a result access to anexternal device often becomes hard to control in the presenceof those ldquoinsidersrdquo (unauthorized apps with the permission onthe devicersquos communication channel)

As an example consider a blood-glucose meter that mea-sures a patientrsquos blood-sugar concentration and reports the resultto an app running on her smartphone through a Bluetoothchannel Only that app should be allowed to communicatewith the device But this access control cannot be enforcedon todayrsquos Android which lets any app with the Bluetoothpermission talk to the meter Note that this problem cannot beaddressed by the standard Bluetooth security mechanism [44]as it only ensures that the blood-glucose meter is paired withan authorized smartphone not an authorized app running onthat phone

Our work In this paper we report our first-step study on thisemerging security challenge which we call external DeviceMis-Bonding (DMB) particularly its threat to Bluetooth devices

Permission to freely reproduce all or part of this paper for noncommercialpurposes is granted provided that copies bear this notice and the full citationon the first page Reproduction for commercial purposes is strictly prohibitedwithout the prior written consent of the Internet Society the first-named author(for reproduction of an entire paper only) and the authorrsquos employer if thepaper was prepared within the scope of employmentNDSS rsquo14 23-26 February 2014 San Diego CA USACopyright 2014 Internet Society ISBN 1-891562-35-5httpdxdoiorgdoi-info-to-be-provided-later

Our research shows that this DMB threat is indeed realistic andserious Specifically we thoroughly analyzed four high-profilesmartphone-enabled healthcare devices including a BodymediaLink Armband [3] (monitoring a userrsquos daily activity pattern)an iThermometer [13] a Nonin Onyx II Pulse Oximeter [15](monitoring a patientrsquos pulse and Oxygen saturation) and anEntra Health System Blood-Glucose Meter [11] These devicesare very popular and all of them except iThermometer are FDAapproved Class II medical devices However we found that thelack of a secure bonding between them and their correspondingapps leaves these devices vulnerable to different types of DMBattacks In particular in a data-stealing attack an unauthorizedapp on the authorized phone can stealthily download thedata these devices gather from a patient using nothing butits Bluetooth permission and side-channel information fordetermining the right moment for the download This mayhappen when such a device is present and the official app thatis the one the user expects to connect to the device is in factnot connected to it In a data-injection attack the maliciousapp again with a Bluetooth permission only even breaks thedevice-level Bluetooth security the app stealthily unpairs thephone from an authorized external device and pairs it with amalicious device to feed falsified medical data into the originaldevicersquos official app Demos of the attacks are posted online [6]

As the current design of Android does not provide anymeans to bond an app to an external device individualdevice manufacturers are left with no option but to developtheir own approaches to authenticate their official apps totheir devices This could be challenging given that thesedevices are often simple sensors and may not have muchresources to perform authentication operations such as runningcryptographic functions To understand how pervasive theproblem is we further conducted a measurement study inwhich we analyzed 68 official apps responsible for a widespectrum of Android external devices sampled from GooglePlay and confirmed that none of them are protected by anyapp-device authentication mechanism

Given the grave consequences of a DMB attack (compro-mises of the confidentiality and integrity of critical user data)and the credible threat it poses (the pervasiveness of vulnerabledevices) serious effort needs to be made to address this issueTo this end we present the first OS-level solution calledDabinder Dabinder works as an Android service keepingtrack of the identities of individual external devices and theapps that initiate the first Bluetooth connections with them rightafter they are paired with the phone Based on this observationa security policy is generated to tie the app to the device whichforms a bond that cannot be broken without the userrsquos consenta different app is not allowed to connect to the device nor canit unpair the phone from the device unless this access-controlpolicy is overruled by the user We implemented Dabinder andevaluated our prototype against the attacks on these popularhealthcare devices which demonstrates its effectiveness inmitigating the threat and negligible impacts on the phonersquosnormal operations We released the code of Dabinder as anAndroid 422 r1 patch which can be downloaded here [5]

Contributions We summarize the contributions of the paperas follows

bull New understanding We made the first attempt to

understand the threat of Android device mis-bondingin the context of Bluetooth bonds Our study revealsthe gravity of the threat that could lead to leaks ofsensitive user data or compromise of its integrity aswell as the prevalence of the issue among popularsmartphone-enabled devices

bull New techniques We developed the first techniquesto mitigate the threat Our approach automaticallygenerates security policies for protecting the bondingbetween an external device and its authorized appand effectively enforces the policies without impedingnormal operations on the phone

bull Implementation and evaluation We implemented ourdesign and evaluated its effectiveness and performance

Roadmap The rest of the paper is organized as followsSection II introduces the background information of our studyparticularly the generality of the device mis-bonding problemSection III elaborates our security analysis on smartphone-enabled Bluetooth devices Section IV presents the designimplementation and evaluation of our protection mechanismSection V discusses the limitations of our study and follow-upresearch Section VI compares our work with related priorresearch and Section VII concludes the paper

II EXTERNAL DEVICE MIS-BINDING

In this section we first explicate the threat of Androidexternal device mis-bonding at a high level and then clarifythe scope of our research and its underlying adversary model

A Background

The fundamental cause of the DMB problem is the inad-equacy of the Android security model in protecting externaldevices Here we provide background information about thesedevices and the way the Android security mechanism works

External devices Increasingly smartphones are used to en-hance healthcare financial management and services in othercritical domains For this purpose they often need to worktogether with specialized external devices helping preprocessthe data gathered by the devices and relaying the outcome tovarious service providers In particular smartphones today areextensively used with different medical devices for patient careand monitoring fitness health education and research [43]Examples of related health devices include WiFi or Bluetoothbased blood pressure monitor [20] ECG device [1] muscle fa-tigue monitor [19] pulse oximeter [15] heart rate monitor [21]thermometer [13] lifestyle monitor [3] [8] [9] and many othersThese devices utilize smartphones to analyze and display dataand to communicate with their corresponding web servicesThe data here is often considered sensitive as it describes anindividualrsquos health status and activities In addition to healthcaredata smartphone-enabled devices are also utilized to work onother private user information For example the Square Readercollects a userrsquos credit-card data through a phonersquos audio portand NFC devices are widely used in Europe to accept paymentsthrough phones

As a leading mobile operating system (with 75 of marketshare [2]) Android is the main platform that supports these

2

external devices Its security design therefore becomes crucialfor protecting sensitive user data involved in the operations ofthese devices

Android security model At the center of Android securityis its application sandboxing and permission model EachAndroid app is confined within its own sandbox and needspermissions to access sensitive resources including cameraaudio location network etc In particular some of theseresources (eg audio network Bluetooth NFC and others)can serve as channels to connect a phone to external devicesTo acquire the permissions to use the resources an app needsto explicitly request (using AndroidManifestxml) from thephonersquos user during its installation

This security model is actually built upon Linuxrsquos kernellevel protection (process separation and file system accesscontrol) Each Android app runs as a Linux user with a uniqueuser ID which naturally separates its operations and datafrom those related to other users under the Linux user-basedprotection Sensitive system resources are usually mapped tospecial Linux groups such as inet gps etc An app grantedwith the permission to use a resource is assigned to thatresourcersquos Linux group Every member within that group (withthat permission) is equally entitled to operate on that resource

B Mis-bonding Threat

The problem As we can see here the Android securitymodel only controls the access rights on the channel usedfor communicating with an external device (such as BluetoothNFC audio port) not the device itself As long as an appacquires a permission for this channel it automatically gainsaccess to any device that is connected through the channel Thisis because all apps with the same permission are affiliated withthe same Linux group so they have the same privilege on theresources shared within the group including the channel (egBluetooth) Android does not care how this channel is usedand which party an app talks to Also all information relatedto an external device (such as Bluetooth pairing data) is alsoshared within the group members which could be exploited bya malicious member to compromise the integrity of the datareceived by the official app of the device (Section III-B)

As an example consider a medical device that commu-nicates with its Android app using Bluetooth To make thishappen the smartphone hosting the app first needs to pairwith the device which forms a bond between the phoneand the device This pairing process yields a set of bondinginformation which allows these two devices to connect to eachother automatically in the future The bonding informationincludes the external devicersquos MAC address and its UniversalUnique Identifier (UUID) together with a secret link keyfor authentication and encrypted communication (when thedevices decide to do so) Note that such a bond relation is onlyestablished on the device level there is nothing to prevent anunauthorized app (with Bluetooth permissions) on an authorizedphone from connecting to the device This permission alsomakes the app a member in the net_bt_admin group As aresult the unauthorized app is given the privilege to break thebonding with an authorized medical device and pair the phonewith a malicious one configured with the formerrsquos bonding

information so as to feed fake medical data into a patientrsquosmedical record (Section III-B)

Given the limitations of the Android security model devicemanufacturers are on their own to address this security riskOne thing they can do is to design a way to secure thecommunication between the device and its official app Aninstance we are aware about is the Square creditcard reader [18]which connects to a smartphone through its audio port Itsearly version is vulnerable because every app with audiopermission can read from it The later one comes with anencryption capability the reader encrypts the data (usingAES) collected from a credit card using a hard-coded keyand transmits the ciphertext through the phone to the webMost other devices however do not provide any app-devicelevel protection as confirmed in our measurement study(Section III-C) possibly due to the fact that most of themare simple sensors without sufficient computing resources tosupport cryptographic operations These devices can upload thedata to the online service through the smartphone which alsoprovides an interface for the user to see and analyze their dataEncrypting this data in the device and just using the phone as acommunication relay would severely affect the usability of thedevice as the user would not be able to use her phone to seeher data All the devices we analyzed have apps that displaythe user data on the smartphone Hence the treatment adoptedby Square does not seem to be suitable for these devices

Scope and adversary model In our research we conducted apreliminary study on this under-researched yet critical securityproblem As the first step our study focuses on Bluetoothhealthcare devices which are becoming increasingly popularin recent years The security risks we discovered and the newtechnique we built are expected to be extended to other typesof external devices though further studies are certainly neededhere to better understand their related security issues

We assume that a malicious app is present on the victimrsquosAndroid phone with both the Bluetooth and Bluetooth Ad-minstration permissions These two permissions are claimedby almost all the Bluetooth-capable apps For a data-injectionattack in which a malicious party clones the target device wealso assume that the fake device can be placed close to thevictimrsquos phone (within 100 meters)

III ATTACKS AND MEASUREMENT

In this section we report on our study that aims at betterunderstanding the magnitude of the device mis-bonding threatTo this end we built end-to-end attacks on popular smartphone-enabled medical devices and further measured the pervasivenessof the security risk discovered as elaborated below

Healthcare devices As mentioned before our study focuseson Bluetooth devices Specifically we analyze four popularhealthcare devices All of them except the iThermometer areFDA approved Class II medical devices [16] in the categoryof X-ray machines infusion pumps etc which are used todeal with real patient care and life critical information Thefirst three devices either have their online services availableor are capable of synchronizing the information they collectwith other cloud based health-services Here is more detailedinformation about these devices

3

bull Bodymedia Wireless LINK Armband [3] is one of themost popular activity monitoring systems which hasbeen used in over 120 clinical studies [23] It utilizesfour different sensors to collect data about the userrsquosmotion temperature perspiration etc for accuratecalculation of calories burned and monitoring of sleeppatterns The output of the device can be displayedby a mobile app running on Android or iOS andfurther synchronized to an activity manager websiteDisclosure of the data can leak out the userrsquos healthstatus and daily activities

bull Nonin Onyx II 9560 Pulse Oximeter [15] is one ofthe best wireless finger pulse oximeters Along witha smartphone app it enables clinicians to remotelymonitor blood-oxygen saturation levels and pulse ratesof the patients with chronic diseases such as ChronicObstructive Pulmonary Disease (COPD) or asthma [16]The device uses Bluetooth to connect to the smartphonewhich can deliver the data to the health provider onlinehealth services or stored locally for later analysis Thedata collected here is also critical for understandingthe patientrsquos status and choosing an effective treatmentThis device is Microsoft HealthVault1 certified [16]

bull Entra Health System MyGlucoHealth Blood-GlucoseMeter [11] is one of the most popular glucose mon-itoring devices It comes with a complete diabetesmanagement system (including testing at home) up-loading data to the online account through its Androidapp which helps a patient manage her disease andshare this data with her health provider Glucose levelsdetermine the amount of insulin to be injected into thepatientrsquos body which is private and also life-critical awrong amount of injection can have severe implicationsincluding death [31] Along with FDA this device isalso approved by CE2 and is fully HL73 compliant [7]

bull iThemometer [13] is an electronic thermometer thatworks with Android through Bluetooth for personalhealth or long-distance monitoring of elderly personsor babies The body temperature is an indicator forlife-threatening conditions like infection

All these devices involve the userrsquos critical data whoseconfidentiality and integrity is important to her health and well-being In the presence of the malicious insider app howeverwe show that such data becomes extremely vulnerable to theDMB threat

A Data-Stealing Attacks

In our research we investigate the feasibility of data-stealingattacks on Bluetooth devices in which a malicious app runningon the victimrsquos phone attempts to steal sensitive data collectedby the target device The attack turns out to be more complicatedthan it appears to be particularly depending on the nature ofa device the malicious app needs to capture a small timewindow during which the device is on and in proximity under

1Microsoft HealthVault is a free online service for personal health informationmanagement

2CE Mark is medical device approval mechanism in Europe3HL7 ndash Health Level Seven International ndash is a globally interoperable

standard for health information exchange

the competition of the official app that also wants to make aconnection to the device Here we describe how we addressedsuch technical challenges and designed end-to-end attacks onreal devices

Fig 1 Data-stealing Attack

Attack strategies Given the BLUETOOTH and BLUETOOTH_ADMIN permissions a malicious app appears to have all itneeds to steal data from these healthcare devices and merelybecause Android does not mediate which app is supposedto connect to the devices In practice however the situationis much more subtle than it appears to be at a first look amalicious app must not be oblivious to the fact that the targetdevice could or could not be in proximity and even when theyare for some of them one needs to push a button or take someactions to activate their Bluetooth services Specifically theBodymedia armband is activated a few seconds after it is puton onersquos arm the iThemometer has such a button on it theNonin pulse oximeter turns on when one inserts her fingerinto the device and turns off once she takes out her fingerand the MyGlucoHealth meter has a button for activating theBluetooth and the meter turns off automatically after sendingdata to the phone Also complicating the attack is the presenceof the official app Once the official app establishes a socketconnection with the target device the malicious app cannotdirectly talk to the device before this connection is torn downand vice versa

A straightforward solution is an opportunistic strategy inwhich the malicious app either periodically invokes the servicediscovery protocol to find out whether the target device is in itsvicinity or blindly makes repeated connection probes hopingto get to the device as soon as it shows up However neitherof these approaches works well in practice due to increasedpower usage of Bluetooth radio a power-consuming practicethat is usually suggested against [53] For instance a user maykeep the Bluetooth communication off to save power Thenwhen she wants to use it she runs a Bluetooth-capable appthat automatically turns on Bluetooth A malicious app usingthis strategy must repeatedly enable Bluetooth to discover thetarget device this consumes more battery power than expectedand could also be noticed by the user given the presence ofthe Bluetooth sign on the phone

In our research we adopt a lightweight and stealthy strategyto perform the surveillance Simply put the execution of thedevicersquos official app is a strong indication that the device is inaction and also within the connection range of the target deviceBased on this observation the malicious app can keep checkingwhen any of the target apps launches an event that can be used

4

to trigger an attempt to catch the window of opportunity Specif-ically our app which works as a service in the backgroundperiodically runs the Android API getRunningTasks() toget the app running in the foreground in constant time O(1)This needs an additional permission GET_TASKS Alternativelywe can use getRunningAppProcesses() which does notneed any permission but returns a list of running processes inan unspecified order that the malicious app needs to traversein search for the target app which takes O(n) running timewhere n is the number of concurrently-running processes on thephone The same result can be achieved by executing the Linuxcommand ps After the malicious app determines that one ofthe target apps is in the foreground it attempts to establish aBluetooth connection with its respective device

A catch here is that when the official app is in com-munication with the target device the malicious app cannotconnect to it To get the data the malicious app needs toconnect to the device right before this legitimate connection isestablished right after it completes or during some disruptionof the connection Below we summarize these options

bull Pre-connection The official apps of these devices onceexecuted often need the userrsquos intervention to startthe communication with their devices For exampleall the apps for the MyGlucoHealth iThermometerand the Bodymedia armband have a soft button thatneeds to be pushed to initiate the connection Theseapps can also be configured to attempt automaticconnections to their respective devices as soon asthey are launched Therefore in order to capture datafrom the target device the malicious app should be inposition to exploit the time gap between the moment itdiscovers that the target app is running and the momentwhen the legitimate connection is established (afterthe soft button is pushed or the automatic connectiongoes through) The likelihood of this succeeding iscontingent on how frequently the malicious app checkscurrently-running processes ie its sampling rate formonitoring the official app

bull Post-connection After discovering the running officialapp the malicious app can simply wait until itsconnection ends and then immediately connect to thedevice This strategy avoids aggressive monitoring ofthe official app the malicious app can keep a slowsampling rate as long as it can still detect the targetduring its execution There is a risk however that theuser turns off the target device before exiting its appWhen this happens the adversary loses the chance toget data at that specific point

bull Disruption The malicious app can disrupt the legiti-mate apprsquos communication by deactivating Bluetoothon the phone It can then reactivate the channeland immediately make a connection to the targetdevice During this attack the user might observe thedisruption and have to manually click the button onthe app again to resume data collection The approachmakes the attack less stealthy but more reliable ingetting the data from the target device

Here we elaborate how we utilize these techniques to launchdata-stealing attacks on the healthcare devices

The attacks In our study we execute the data-stealingattacks on all four healthcare devices To prepare for theattacks we analyzed the code of these devicesrsquo official appsand their Bluetooth traffic captured using hcidump [12] tofacilitate our understanding of their protocols (for talkingto the devices) and further built these protocols into themalicious app During its operation the malicious app calls thegetBondedDevices() API to get a list of external devicesalready paired with the phone and their bonding informationincluding the name the MAC address and the UUID of thedevice of interest Using such information the malicious appmakes RFCOMM connections to the device to downloadsensitive user data

The attack strategy we implement includes asurveillance component that periodically calls the APIgetRunningTasks() to monitor the execution of thedevicersquos official app twice per second With this implementationour app can keep a low profile incurring on average aroundonly 3mW of extra power consumption In the meantimegiven that human interventions (clicking on a button after theapp is activated) can take seconds our app stands a goodchance of capturing the time window before the official appestablishes a connection to its device In case automaticconnection is configured on the target apps there is a racecondition on the socket establishment To make sure that we donot miss the opportunity to capture data when a target app islaunched our design incorporates both the pre-connection andthe post-connection strategies as soon as the malicious appfinds that the target app is running it first makes a connectionattempt if not successful the app listens for the asynchronousACTION_ACL_DISCONNECTED event broadcasted by theOS which notifies the app once a low level ndash(AsynchronousConnection-Less (ACL)ndash connection with a remote deviceends and then tries to connect to the target device again if thedevice is the one disconnected and the disconnection is notcaused by the malicious app itself If either the pre-connectionor post-connection attempt succeeds the malicious apprequests and captures the data from the appropriate externalBluetooth device sends them to the adversary and closes theconnection to make it available to the legitimate app

It is particularly tricky when the official app is configured toautomatic connections once the pre-connection attack succeedsthe malicious app rapidly finishes its operations and releases thesocket that is almost instantly captured by the legitimate appThis causes the OS to miss reporting the DISCONNECT eventand the consecutive CONNECT Hence when the legitimateapp releases the socket the malicious app believes that thedisconnection is initiated by itself As a result it skips the post-connection opportunity and thus misses the new data the devicecollects during the period of the legitimate apprsquos connectionTo address this issue we designed the malicious app to checkwhether enough time elapses from the moment it sends outa disconnection request to when it receives a disconnectionevent from the OS if so the app believes that the event itgets is about another app and then goes ahead to make anotherconnection attempt

We run the malicious app on a Nexus 4 development phonerunning JellyBean (42) together with all target devicesrsquo appsWe evaluated the effectiveness of the data-stealing attack byobserving the success rate when the apps were configured to

5

initiate automatic connections to their respective devices oncelaunched This is the worst case scenario as this operationis much faster than its alternative where the user must clicka button to initiate such connections hence the window ofopportunity is smaller for the pre-connection attempt Our studyshows that the malicious app is often successful in capturingthis window The experimental results are presented in Table I

For the Bodymedia armband device we found that in 100pre-connection trials the malicious app managed to connect 99times to the device get the sensitive data and send them to aremote server The case that the connection failed was attributedto a device de-synchronization issue that rendered even theofficial app unable to connect to it We achieve this high successrate because the Bodymedia Link Armband mobile app doessome pre-processing operations before attempting to connectto its device which gives enough time for the malicious appto perform its operations and release the socket The successrates were also high for other apps except for iThermometer(eg 42 out of 100 trials) due to its apprsquos prompt response inestablishing Bluetooth socket connections When the maliciousapp won the race the authorized app failed to connect but itautomatically retried after 10 seconds and succeeded as thisinterval was often enough for the malicious app to finish its taskand release the socket The post-connection attacks succeededmost of the time except for the glucose meter MyGlucoHealthas long as the devices were switched off after the official appsstopped MyGluooHealth automatically turns itself off aftersending data to its app to save its battery power so none ofthe post-connection attacks on it succeeded We also tried thedisruption strategy which also worked allowing our app todiscontinue the official apprsquos connection and get the healthdata A problem with this attack strategy as discussed beforeis that the legitimate connection needs to be interrupted whichcould be noticed by the user

Power consumption evaluation A rough estimation of thepower consumption of different surveillance strategies isimportant for understanding the stealthiness of the maliciousapp because this activity dominates all of its operations in termsof the time interval that it has to run We tested the differentoptions we had We evaluated getRunningTasks (thestrategy we implemented in the malicious app) and its alterna-tives including calling getRunningAppProcesses() andmaking repeated attempts to connect to or check the existence ofthe target Bluetooth device We ran the app using each strategyindependently for 10 minutes The average power consumptionof the strategy under scrutiny is illustrated in Table II Asdepicted the one we decided to adopt (getRunningTasks)turned out to be both much more efficient and stealthier (as theBluetooth sign appears on the screen only when it is supposedto be ie when the the official app is running) We furthercompared the power consumption of this strategy with that oftwo popular apps as described in Table III As we can see hereour surveillance strategy has a comparable power-consumptionlevel (3mW) as those apps (1 to 18mW) Accurate powerconsumption measurement is not required to do this evaluationwe only need rough relative power measurement The softwarewe used for the power consumption evaluation provides accuratemeasurement for a very limited number of phones and roughmeasurements for all Android phones This rough measurementsuffices for this evaluation

Target Device Pre-connection Post-connectionBodymedia LINK Armband 99100 100100

iThermometer 42100 100100Nonin Pulseoximeter 99100 92100

myGlucoHealth 100100 0100

the device turns off few seconds after sending data to the phone

TABLE I Success rate of data-stealing attack This tabledepicts the successful connections made by the malicious app

on 100 trials

Technique Avg Power Consumption Sampling RategetRunningAppProcesses() 8mW 2 sampless

getRunningTasks() 3mW 2 samplessconnect() 17mW 018 sampless

startDiscovery() 15mW 0054 sampless

TABLE II Average power consumption over 10 minutes persurveillance technique using PowerTutor[53]

B Data-Injection Attacks

In addition to the threat of the data-stealing attacks wefound that the presence of the insider the malicious app onthe phone also makes it possible to inject fake data into thedevicersquos official app and its online account for the user Morespecifically this attack works as follows

1) The malicious app first uses its Bluetooth permissionsto collect part of the bonding information for the targetdevice and delivers the information to the adversary

2) The adversary clones the device using the bondinginformation (MAC address UUID and device name)and places the clone in the neighborhood of theoriginal device or other places where the user maycome close With a standard Class 1 Bluetooth devicethe clone can stay as far as 100m from the phone

3) When the user gets into the clonersquos Bluetooth trans-mission range the malicious app resets the link key (inthe presence of secure communication) by unpairingthe phone from the original device and pairing it withthe clone then it invokes the target app (if it is notalready running) The clone then talks to the officialapp and transmits falsified data to the app

4) To make the attack stealthy the malicious app canchoose to pair the phone back with the original deviceafter the attack thus the phone user will not noticethat her device has been unpaired This succeeds mostof the time as the PIN for most Bluetooth devicesis either ldquo0000rdquo or ldquo1234rdquo [51] It should be notedthat the original Bluetooth device does not need to bediscoverable for pairing as long as its MAC addressis known Moreover most of the new devices withBluetooth 21+ use Secure Simple Pairing (SSP) [28]which does not need any user intervention for pairing

Technique Avg Power ConsumptionFacebook 18mW

getRunningTasks() 3mWGmail 1mW

TABLE III Average power consumption over an hourComparison between our surveillance technique and 2 popular

applications using PowerTutor[53]

6

Fig 2 Normal Scenario Fig 3 Adversary injecting fake data

To make this attack happen we need to address a fewtechnical challenges particularly how to clone the originaldevice how to stealthily reset the link key when secureconnections are in use and how to connect to the spoofeddevice in the presence of the original one Here we elaboratethese problems and our solutions

Device spoofing To clone a Bluetooth device all an attackerneeds is the target devicersquos name MAC address and UUIDAs discussed before such information can be easily obtainedby calling Androidrsquos getBondedDevices() method ofBluetoothAdapter class [24] which gives a list of devicespaired with the phone and their bonding data In our experimentwe ran SpoofTooph [25] on a Linux laptop that masqueradedthe original device using its name MAC and class (ie UUID)The spoofed device can be placed wherever the user may comeclose if the official app of the original device does not have asoft button for activating its Bluetooth connections An examplehere is the Bodymedia armband in automatic connection modeOtherwise the adversary needs to set it up in the vicinity ofthe original device The presence of two devices with the samename MAC and UUID is hard to detect as Bluetooth scannersshow only one of them Also the spoofed device can be muchfurther away from the userrsquos phone than the original device(even outside the door) and still ensure the success of the attackwhich we elaborate later in this section

Link key reset What gives trouble to this data-injectionattack is the link key stored in the operating system thatthe malicious app cannot get The link key is used toencrypt Bluetooth packets when the devicersquos official appinvokes createsecureRfcommSocket Without knowingthis piece of information the clone cannot talk properlywith the app This is not always a problem an app canconnect to its device without encryption protection (throughcreateInsecureRfcommSocket) and even some devicesthat offer encryption may not provide adequate securityConsider the Nonin pulse oximeter as an example Its appfirst tries secure connections but if this attempt fails the appautomatically switches to the insecure channel to ensure that thecommunication can still go through However for the devicethat always sticks to the secure channel an attacker needs away to circumvent the defense provided by the link key

Here is our strategy if we cannot get the link key wecan simply replace it setting it to one known to our spoofeddevice Given the Bluetooth and Bluetooth_ADMIN

permissions the malicious app can easily unpair the phonefrom any Bluetooth device by calling the API IBluetoothwhich removes the current link key shared with the deviceTo enable the official app to talk to the clone however weneed to pair it with the spoofed device This operation sets anew link key for the clone which requires the user to entera PIN to authenticate her phone to the device (Note that thePIN here is for device-device authentication not app-deviceauthentication) The PIN itself is not a big issue as the clonewill accept whatever it receives4 The problem is that there isno public Android API for programmatically entering the PINThe phone userrsquos intervention seems inevitable

A close look at Android source code however showsthat the OS has a hidden interface that allows programmaticentering of a PIN All we need to do here is to find away to use it The APIs provided by Android communicatewith different system services through IPC (Inter-ProcessCommunication) calls based on those servicesrsquo interfacesspecified by Android Interface Definition Language (AIDL)Actually a method setPin() under Android IBluetoothAPI (Androidrsquos private API for Bluetooth services) can beused to programmatically input the PIN The problem is thatthis interface is not open to ordinary apps In our researchwe managed to get this interface by using a technique [22]that retrieves the AIDL description of the method from theAndroid source code and then compiles it together with thecode of the malicious app As a result the interface becomesvisible to the app Through the interface a PIN can thenbe automatically entered for a Bluetooth pairing To avoidshowing any user interfaces that might arouse suspicion fromthe phone user the app performs this pairing operation whenthe screen is off which can be determined without requestingany permission [54] We provide a demonstration of this attackon a web page [6]

Connection race Another technical challenge comes fromsome appsrsquo soft buttons which needs to be clicked by thephone user to initiate their Bluetooth communication with thedevices All four device apps we studied can be set in thisldquobuttonrdquo mode In this case automatic triggering of those appsrsquoBluetooth connections is difficult Therefore we have to placethe clones somehow close to their original devices (withintens of meters) in hopes that when the user starts running the

4After the attack if the malicious app wants to restore the pairing with theoriginal device oftentimes a default PIN (0000 or 1234) works just fine [51]

7

official apps they will mistakenly talk to the clones This turnsout to be pretty realistic we found that we can set the spoofeddevice in a way that it almost always wins this connection raceas elaborated below

A Bluetooth device typically waits for a smartphone toinitiate a connection During this waiting process it continuesto switch between two modes page sleep where it sleeps tosave power [35] and page scan where it wakes up to look forconnection requests This process is called paging Let Tsleep

be the time interval between two scans and Tscan the durationof a scan Obviously a larger Tscan and a smaller Tsleep lead tomore power consumption but are more likely to timely respondto the phonersquos connection requests According to Bluetoothspecifications [35] [26] these parameters are supposed to beset such that 1125ms le Tsleep le 256s and 10625ms leTscan le Tsleep For most Android external devices includingall those used in our research their parameters are chosenfor power saving and cannot be modified by the user Theadversary however can be more aggressive In our researchwe used the Linux configuration tool hciconfig to set theseparameters for the Bluetooth dongle on our attack laptop toTscan = 1125ms and Tsleep = 128s and ran this spoofeddevice against all four healthcare devices We found that theclone almost always won such connection races This happenedeven when the original device was more powerful than the clonein terms of radio signal strengths For example Nonin pulseoximeter [15] is a Class I Bluetooth device with a 100mWradio and a range up to 100m whereas clone was Class IIwith a 25mW radio and a range up to 10m even under sucha disparity the clone always managed to first connect to thephone even behind a wall and 7m away

The attacks In our research we implemented the attack andevaluated them on our NEXUS 4 phone (Android 42 15GHzquad-core CPU and 2GB memory) and the medical devicesThe experiments were conducted in the presence of both theoriginal devices and their clones (a VM with Intel Core i7 CPU(shared) 1GB memory a Bluetooth 20 dongle) though thisis unnecessary when these devicesrsquo apps are in the automaticconnection mode that enables the malicious app to trigger themto automatically connect to the clones whenever the phoneuser comes close to the spoofed devices To make our attacksrealistic we deliberately placed the original devices closer tothe phone (0 feet) than the spoofed ones (20 feet away with awall in-between) Among all 100 executions of the official appsthe phone was always first connected to the clones despitetheir larger distance from the phone The results are presentedin Table IV Note that in the presence of secure connectionsthe phone cannot talk to the original device after the resetof the link key When this happens however the phone willget a notification of connection failure if the response fromthe original device comes first In our experiment we neverobserved such a notification each time the phone alwayssmoothly established a connection with the clone

In all the tests our app first unpaired the phone fromthe original device and then paired it with the clone usinga random PIN as an input All these unpairing and pairingattempts succeeded Once a connection was established weobserved that the spoofed device easily dumped fake data intothe official app this data was displayed on the phone or theweb page for the userrsquos account A demo is posted online [6]

Distance of cloned device 1 ft 20 ft

Number of observations 100 100Distance of original device 0 ft 0 ft

No of times original device responded 0 0No of times cloned device responded 100 100

with a wall in between

TABLE IV Data-injection attack launched 1ft and 20ft awayfrom the victimrsquos phone with the original device touching thephone In both cases the experiments were repeated 100 times

Total apps 90Apps not using Bluetooth (eliminated) 2Device apps with sensitive information 68Device apps with insensitive information 20

TABLE V Sampled apps

C Measurement of the DMB Threats

As discussed before the DMB problem comes from thelack of a bonding between an Android external device andits official app In the absence of OS-level protection thisthreat can only be addressed by the app-device authenticationdeveloped by individual device manufacturers The design andimplementation of such an authentication mechanism howevercan be nontrivial which could raise the cost of the devicesTo find out whether such a security measure has alreadybeen taken in practice we performed a measurement studythat analyzed a relevant set of apps from Google Play Ourstudy for which we give details below reveals that all of theselected apps are actually vulnerable indicating that the DMBproblem is indeed realistic and serious Given the pervasivenessof vulnerable devices and challenges in fixing them (whichcould require modifying their hardware) an OS-level solutionbecomes inevitable (Section IV)

App collection To collect relevant official apps for differ-ent Bluetooth devices we searched Google Play for thosecompatible with Google NEXUS 4 using the following termsldquoBluetooth Door Lockrdquo ldquoBluetooth Healthrdquo ldquoBluetooth MedicalDevicesrdquo and ldquoBluetooth Meterrdquo All together these queriesgave us 90 apps For each of these apps we manually inspectedits descriptions to determine whether it received sensitive userdata from its device Among these 90 apps 68 involved someprivate user information such as the heart rate blood pressurebody temperature glucose level daily activities and so on assummarized in Figure 4

Methodology and analysis To avoid purchasing all those 68devices which is too expensive we analyzed their code to findout whether they included any app-device authentication Thisanalysis was done both automatically and manually as follows

We first decompiled all the 68 apps and searched forauthentication-related programming structures Authenticationshould be based upon a secret which was not hard-codedinto any of those apps given the fact that from two indepen-dent downloads of the same app we always got the samecode and data Therefore such a secret should either comefrom some external inputs of the app particularly its userinterfaces web communication or internal memory files oris generated by cryptographic operations In our study we

8

Fig 4 Classifications of the sampled apps Some of themcollect information in multiple categories

inspected all such potential sources of authentication secrets(Table VI) to determine whether their outputs affected theinputs of the apprsquos Bluetooth communication particularly thatof BluetoothSocketwrite which transmits data to thedevice through a Bluetooth socket connection

We ran a script that used grep to locate the APIs relatedto those sources and identified the apps where such APIs onlyappeared within public libraries For example we found thatfor most apps their cryptographic APIs (provided by JavaJCE Bouncy castle and spongycastle [14] [4] [17]) wereall included in shared libraries such as Google ads Twitterauthentication OAuth etc Those libraries are used for specificpurposes getting ads or performing web-based authenticationfor example It is unlikely that they be used for authenticatingthe app to its Bluetooth device Therefore we removed all theapps that did not have any of those APIs outside the publiclibraries There were 48 such apps among all we collected

For the remaining 20 apps we manually inspected all theoccurrences of these ldquosuspiciousrdquo APIs (Table VI) in theircode We looked at the functions where the calls to the APIswere made It turned out that they were all used for thepurposes having nothing to do with app-device authenticationFor example most reads from memory files appeared in thecrash-handling mechanisms and most cryptographic operationswere performed on the SQL queries on web databases Wealso found that HttpClient was used in the functions forsharing tweets or getting the userrsquos workout data from the webNone of these API outputs were propagated to the inputs ofthe apprsquos Bluetooth communication

We further installed all the 68 apps and manually inspectedtheir user interfaces None of them asked for passwordsPINs etc for authenticating themselves to their correspondingdevices

AuthenticationMethods

LibrariesFunctionsused

Total Apps with app-device authentica-tion

Crypto egjavaxcryptobouncycastle

9 0

Internal storage egopenFileInput()

15 0

Web communica-tion

eg HttpClient 5 0

UI for app-deviceauthentication

Manual 0 0

TABLE VI Manual analysis on 20 apps The other 48 appswere automatically filtered out by the locations of their

suspicious APIs

Summary of the findings As discussed above we foundno evidence that any of these 68 apps which were relevantapps in Google Play performed any app-device authenticationTable VI summarizes our findings The 48 apps we removedautomatically either did not have any suspicious APIs orhad such APIs in their shared libraries including those foradvertising web authentication crash analysis etc For the 20apps we manually analyzed 9 called cryptographic APIs intheir own code 5 invoked web APIs and 15 read from memoryfiles Also for all the 68 apps we studied none had userinputs for app-device authentication Again none of these appsgenerated any data flow that affected the inputs of Bluetoothcommunication functions

Our study also shows that most of these apps supportedsecure Bluetooth communication 42 apps utilized securesocket only 12 worked under both secure and insecurecommunications and the rest utilized insecure communicationonly This indicates that most of the devices processing sensitiveuser data do take privacy protection seriously However thepresence of malicious apps with the Bluetooth permissions onAndroid renders such device-device authentication insufficientfor protecting private user information

IV ANDROID DEVICE BINDING CONTROL

Our security analysis of existing Android Bluetooth devicesshows that most of them are completely unprotected fromthe mis-bonding attacks Although theoretically each devicemanufacturer can provide its own app-device authenticationto address the problem this requires upgrading not only itssoftware (the app) and also the hardware (the external device)thus making the device more expensive Also this case-by-case fix renders the quality of security protection for differentexternal devices hard to control Therefore we believe that abetter solution is to enhance Android to provide an OS-levelaccess control that bonds each device to authorized app(s)In this section we elaborate our design and implementationof such a technique called Dabinder and evaluation of itsefficacy Dabinder assumes that underlying Android OS is notcompromised The protection mechanism (namely Dabinder isdeveloped on framework layer of Android OS

A Overview

We built Dabinder to effectively control app-device bondingin both pairing and communication stages and to minimize

9

Fig 5 Bluetooth Subsystem and our defense mechanismDaBinder is built into AdapterService and checks the interactionbetween apps and Bluetooth devices It only allows authorizedapp to access Bluetooth device and keeps bonding policy in asecure storage Reference Monitor and Bonding Policy blocks(both shown in light-blue) constitute Dabinder

user involvements in setting access-control policies Here wedescribe a high-level design that achieves these two goals

Architecture Figure 5 illustrates the architecture for Blue-tooth socket communication on Android 42 which includesDabinder components (Reference Monitor and Binding Pol-icy database) To pair a device programmatically the sys-tem calls setPairingConfirmation and setPin orsetPassKey of BluetoothDevice To unpair a devicethe app uses the API removeBond Alternatively it can invokethe settings program to control the Bluetooth adapter In bothcases an IPC request needs to be sent to AdapterServiceto control the Bluetooth device Once a bond (pairing) isestablished the app can make a socket connection to accessthe device To this end again it first needs to talk to theBluetoothAdapater to get a list of paired devices Fromthis list the app identifies the target device (MAC) and furtherrequests a socket through the object BluetoothDeviceThis request is also delivered using an IPC through theIBluetooth interface to AdapterService which cre-ates the socket for the connection

In our design the whole security mechanism is builtinto AdapterService including a component that controlssocket establishment (within an authorized app-device pair5)and one that manages the unpairing operation (which can onlybe performed by an authorized app6) Such access controlsare based on a set of security policies that unambiguouslybonds a device to its authorized app which are generatedautomatically by the system from what is observed from thephonersquos Bluetooth operations

How it works Here we explain how Dabinder works Oncethe device is activated it is paired with its authorized app bythe phone user This pairing operation is observed by Dabinderwhich then generates a bonding policy that associates eachdevice (name MAC and UUID) to its official app (that is its

5App-device pair is our terminology for creating a bond between an app andBluetooth device as opposed to conventional Bluetooth pairing which createsa bond between the phone and the device

6Authorized app The app that has already established bond to the device

Linux user ID or UID) Whenever Android receives a Bluetoothsocket-connection request from an app the policy enforcementmechanism checks whether the app is associated in the bondingpolicy to the device it is trying to talk to if the app is not on thedevicersquos bonding policy the request is denied otherwise it isallowed to proceed In this way our mechanism defeats the data-stealing attacks Also Dabinder runs an unpairing controller tomanage the operations to dissolve a pairing relation betweenthe phone and a device in the absence of the bonding policybetween the device and the app that requests such an operationthe app is considered to be unauthorized and its unpairingattempt is stopped As the data-injection attack is contingenton resetting the link key for the phone-device communicationit cannot work without unpairing the phone from the originaldevice Therefore such an attack cannot go through

B Design and Implementation

Here we present the detailed design of Dabinder which weimplemented in our research on a Galaxy NEXUS 4 phonewith Android 42 As described before our design includesmechanisms for generating and maintaining security policiesand for enforcing these policies during phone-device pairingand app-device connection establishment All these mechanismswere implemented within AdapterService

Policies identification Critical to Dabinderrsquos mission is thesecurity policies on the legitimate bond between an app andan external device Such a policy can certainly be manuallyspecified but it is highly desired that it can also be automaticallygenerated without the userrsquos intervention if she prefers todo so In our design this policy-identification operationis performed within AdapterService when our policyenforcement mechanism inspects a pairing request and itsfollow-up connection request if an app is the first one tomake a socket connection to the device after the device ispaired with the phone our mechanism automatically adds thisapp-device relation to a policy database as a new bondingpolicy

To securely and persistently maintain these policies inthe system AdapterService keeps a Bluetooth MACAddress and UID mapping in the SettingsSecure key-value storage which is persistent and read-only to the appsand can only be modified by the phone user or a sys-tem program The user can manage these policies fromBluetoothManagerService through a user interfacebuilt upon two functions exposed by AdapterServiceaddDevApp and removeAppDev In particular she canexplicitly declare an exemption policy for a device thusallowing it to be accessed by any app

Connection control To communicate with an externaldevice an app needs to establish a connectionwith it through a Bluetooth socket Such a socketis created by the system through a call to theBluetoothDevice APIs createRfcommSocketcreateRfcommSocketToServiceRecordcreateInsecureRfcommSocket orcreateInsecureRfcommSocketToServiceRecordA straightforward solution here is to instrument these APIs inorder to control the creation of Bluetooth sockets The problemis that such mediation actually happens in the user land inside

10

individual appsrsquo address space As a result there is no guaranteethat it cannot be circumvented Also such a policy compliancechecking needs an additional IPC to AdapterService toget the policies from the system Instead in our researchwe modified AdapterServiceconnectSocket asystem function all these APIs have to invoke for policycompliance checking and enforcement Whenever the functionis called it first searches the policy database for the deviceaccording to its MAC address If the device is found ourenforcement mechanism continues to look for its relatedbonding policies In case the app does not appear on anyof them (ie the device has been connected before and isnot exempted from the bonding protection) we considerthat a policy violation is detected and the request is deniedOtherwise connectSocket returns a socket and allocatesthe corresponding resources such as file descriptors for theconnection

This policy enforcement is implemented on the Androidframework layer Apparently the app including native codesuch as createBondNative and removeBondNativemay still touch the Bluetooth device on the Linux layer asillustrated in Figure 5 In our research we inspected theBluetooth interface on Linux and found that it is actuallyincluded in the Linux group bluetooth For the app withBLUETOOTH_ADMIN and BLUETOOTH permissions it canget into the groups net_bt_admin and net_bt but notbluetooth As a result it will not be able to directly accessthe Linux Bluetooth resources even through its native code dueto the Linux access control Under all circumstances the appneeds IPC calls to transfer the execution to a system processin order to use kernel resources Therefore we conclude thatour protection mechanism cannot be circumvented even by thenative code

Unpairing control In the presence of secure Bluetoothcommunication a malicious app needs to first unpair thephone from the original device before pairing it with theclone to reset the link key To prevent this unauthorizedunpairing Dabinder interposes on the function removeBondwithin AdapterService Whenever an unpairing requestis received from the IBluetooth interface our mechanismchecks it against the bonding policy retrieved from the policydataset if the app that sends the request is not the authorizedone on the policy this request is denied Alternatively wecan pop up an interface on the phone to alert the user to theunpairing request and allow the operation to proceed with herpermission

A problem here is that some devices do not use secureBluetooth communication which enables the spoofed deviceto talk to the official app even without knowing the link keyFortunately our measurement study shows that most of devicescollecting sensitive user data do support encrypted communica-tion (Section III-C) though some of them can also automaticallyswitch to the insecure one when the secure connection fails Toaddress this issue Dabinder provides an optional policy throughwhich the phone user can require that any communication with acertain device must be encrypted In case the policy is violated(that is a device is switching to the insecure communication)we can choose to stop the communication and alert the userfor further instructions This happens in AdapterServicewithin the method connectSocket which checks whether

Functions Original Dabinder DelaysBluetoothSocket 0031700059 ms 0035300153 ms 00036 msconnectSocket 631670147098 ms 865152142201 ms 233482 msremoveBond 0531901863 ms 0549301822 ms 0017ms

TABLE VII Dabinder performance evaluation (meansd)

SEC_FLAG_AUTH and SEC_FLAG_ENCRYPT on flag areset

C Evaluation

We evaluated our implementation to understand its effec-tiveness in protecting the communication with external devicesand its performance impacts on the phonersquos normal operationsAll the experiments were conducted on the Galaxy Nexusphone with a Dual-core 12 GHz Cortex-A9 and 1GB memoryAndroid 42 operating system and BlueDroid stack

Effectiveness To understand the effectiveness of our approachwe ran it against all the data-injection and data-stealing attacksdiscussed in Section III All these attack attempts were thwartedSpecifically for all the data-stealing attacks Dabinder stoppedthe malicious app from making socket connections to the targetdevice as these connections violated the policy it automaticallydetected during the pairing stage of the phone When it comesto the data-injection attacks our implementation blocked allthe attempts to unpair the phone from the devices and thereforedefeated the attacks when the secure communication was inuse Also our approach denied the establishment of a socketfor insecure connection required by the Pulse Oximeter app

Performance We further evaluated the performance ofDabinder comparing the execution times for establishingsockets and unpairing a device with and without its policyinspection and enforcement Specifically we measured theperformance of a set of functions using the code instrumentedbefore and after their executions The results are illustrated inTable VII

Here BluetoothSocket creates a Bluetoothsocket connectSocket builds a socket connectionand removeBond unpairs the phone from a device As wecan see from the table for all these functions the delay ismainly caused by connectSocket about 23ms on averageIt should be noted that only 8 devices can have Bluetoothconnection simultaneously to a smartphone Moreover aphone cannot have more than 30 RFCOMM sockets activeat the same time as RFCOMM have only 30 channels [27]For external devices they typically can accommodate onlyone or two connections Actually all data from the device isdownloaded through a single Bluetooth connection Thereforethis 23ms delay will not bring in any noticeable inconvenienceto the phone user

V DISCUSSION

External device mis-bonding is an emerging security chal-lenge for mobile operating systems Our study reveals its seriousconsequences and makes a first step toward mitigating thisthreat However what we have done has just scratched thesurface of this problem domain Further efforts are needed

11

to better understand the problem and come up with effectivesolutions Following we discuss two examples of possible futureresearch on this issue

Mis-bonding problems on iOS and other channels Thefundamental cause for the DMB problem is that Android doesnot differentiate devices attached to the same channel andtherefore cannot bind an app to a device Other mobile OSesmay have the same issue In particular iOS does not seem toprovide any means for tying an app and a device together nordoes it control the access to different devices through otherchannels Further research on this OS platform could lead tointeresting findings Also we have not explored other channelson the phone For example NFC is increasingly used forconnecting financial apps to external devices for the operationssuch as payment Apparently the same mis-bonding problemalso exists on this channel it is possible that an app only needsto get the NFC permission to access an NFC-enabled deviceeven if the app is not authorized to do so If this is true thoseNFC devices can also be subject to the data-stealing attacksdescribed in Section III-A More investigations are needed tounderstand this threat

Bonding control In our research we developed a techniquethat controls the binding between an app and a Bluetooth deviceThe same idea could be applied to other channels and OSesFor example if device mis-bonding indeed becomes a problemfor NFC we might be able to establish a relation betweenan NFC device and its app and ensure that such a relationwill not be broken without the phone userrsquos consent Also incase iOS is found to be vulnerable to the DMB threat a newbonding control mechanism becomes imperative for protectingthe external device attached to iPhone iPad and iPod Follow-upwork on this direction is certainly important

VI RELATEDWORK

Health Device Security The prior works on the security issuesof health devices are the most closely related to our workRahman et al [46] identified several vulnerabilities on Fitbita wireless wearable fitness device which can be leveraged toinject data into the device and launch a denial of service attackagainst it Li et al [38] look into the security weaknesses ofglucose monitoring and insulin delivery systems and proposedthe technologies for protecting those devicesrsquo operations usingrolling-code and body-coupled communication Also Marti etal [39] lay out a few necessary requirements for building asecure mobile health care system All such prior work focuseson the security problems of a specific health device or thecommunication protocol it uses whereas our research aims atunderstanding the security implications of the way Androidhandles its external devices in the presence of malicious appsrunning on the phone

Android Permission Android permission system has beenunder scrutiny for years [42] [47] [41] [33] [30] [45] [41][29] [40] Much has been proposed to extend this securitymodel allowing the phone user to selectively grant permissionsto apps [40] deny those with dangerous permission combina-tions [34] utilize app-defined fine grained access control [42] orleverage IPC provenances for security protection [32] Howeverall these prior approaches are designed to guard a phonersquos local

resources In contrast little has been done on mobile OSes toprotect the external devices that connect to smartphones Inparticular on Android an app that acquires the permissionsto use a channel (eg Bluetooth NFC etc) is automaticallygranted the access to any device attached to this channel Thereis nothing to bind a device to its authorized app This problemcould be mitigated by SE-Android [49] through labeling theapp and the device and design of a security policy to link themHowever this all depends on the knowledge of the device andapp in advance and a careful setting of the right policy whichoftentimes needs the help from the expert Also SE-Androidhas not been extensively used Its utility in the presence ofdiverse applications of Android phones is still not clear

Bluetooth Security Bluetooth is a short-range wireless com-munication technology designed to replace the serial cable linksWith its increasing utilization by different devices ndash includinghealth devices remote car control activity monitoring etc ndashsecurity and privacy concerns are running high Since Bluetooth21 link-layer encryption is required and cannot be turnedoff but encryption and authentication alone cannot addressall issues with Bluetooth Prior research [50] summarizesseveral traditional Bluetooth attacks eg Bluesnarfing Bluetbuggin Bluejacking etc Further security analyses have yieldeddiscoveries of many weaknesses in Bluetooth systems orprotocols which enable the adversary to crack keys PINs [36][48] perform Man-in-the-Middle attacks [37] and propagatemalware [52] etc Different from all such prior research ourstudy focuses on the way mobile OSes handle Bluetooth devicesinstead of the Bluetooth system and the protocol themselvesThis has never been done before to the best of our knowledge

VII CONCLUSION

Smartphones are becoming increasingly sophisticated withtheir functionalities enriched by assorted external devices suchas Bluetooth headsets medical devices creditcard readers etcThis new development however also brings in new security andprivacy challenges The OSes these phones use particularlyAndroid are not designed to protect the secure interactionbetween an external device and its authorized app As aresult oftentimes any app with the permissions to use thecommunication channels utilized by such a device such asBluetooth NFC Audio port etc automatically gain the accessto the device even if it is not authorized to do so

In this paper we reported the first study on this external-device mis-bonding threat which we found to be both realisticand serious Particularly our in-depth analysis on four popularhealth devices including a Bodymedia Armband a thermometera Pulse Oximeter and a Glucose meter shows that all ofthem are vulnerable to different types of DMB attacks Ina data-stealing attack the malicious app with the Bluetoothpermissions can download sensitive user data from the deviceswithout being noticed using the side-channel informationrevealed by Android to determine the right moment to attackIn a data-injection attack the app can collect the pairinginformation of the target device and reset the link key whichenables an adversary to place a spoofed device that masqueradesthe medical device and injects the fake data into the phoneuserrsquos medical accounts All these attacks can succeed evenin the presence of Bluetooth secure communication which isdesigned for protecting device-device communication not the

12

interaction between a device and an app Our measurementstudy which analyzed 68 device apps randomly sampled fromGoogle Play further demonstrates that most existing devicesare vulnerable to this DMB threat

To mitigate the threat we developed a new OS-level protec-tion mechanism called Dabinder Our approach automaticallyidentifies the binding relations between an app and its externaldevice from the phonersquos activities and then uses such relationsas security policies These binding policies are enforced duringthe phonersquos runtime Whenever an unauthorized app attemptsto connect to an external device or unpair the phone fromthe device Dabinder detects and blocks the attempts Ourstudy shows that this new approach works effectively againstBluetooth DMB attacks and incurs a negligible performanceimpact

Our study on the DMB threat here focuses on Bluetoothand therefore is only a first step toward understanding andmitigating this new security issue Follow-up investigations onthe problem in a broader context are important and expectedto happen in the near future

ACKNOWLEDGMENT

We thank our shepherd William Enck and the anonymousreviewers for their comments This work was supported in partby NSF CNS 09-64392 (NSF EBAM) and HHS 90TR0003-01(SHARPS) The authors with Indiana University were supportedin part by the NSF CNS-1017782 CNS-1117106 CNS-1223477and CNS-1223495 The views expressed are those of the authorsonly We also thank Holly B Cogliati (EPFL) for proofreading

REFERENCES

[1] Alivecor ecg [httpwwwalivecorcom][2] Android accounts for 75 percent market share [http

wwwzdnetcomandroid-accounts-for-75-percent-market-share-windows-phone-leapfrogs-blackberry-7000015496]

[3] Bodymedia link armband [httpwwwbodymediacom][4] Bouncycastle library [httpwwwbouncycastleorg][5] Dabinder android open source httpsgithubcomDabinderAndroid

extDroidgit[6] Demos for our attacks [httpssitesgooglecomsiteedmbdroid][7] Entra health systems myglucohealth [httphealth2concomsource

gbmf frontendcompanyshow59][8] Fitbit one [httpwwwdigifitcomfitbitindexasp][9] Fitbit zip [httpwwwdigifitcomfitbitzip]

[10] Foracare testngo [httpwwwforacarecomglucometer-Testngohtml][11] Foracare testngo [httpwwwmyglucohealthnet][12] hcidump httpwwwlinuxcommandorgman pageshcidump8html[13] ithermometer [httpwwwithermometerinfo][14] Java cryptography extension [httpwwworaclecomtechnetworkjava

javasedocumentationindexhtml][15] Nonin onyx ii pulseoximeter [httpwwwnonincomPulseOximetry

FingerOnyx9560][16] Nonin onyx ii pulseoximeter specs [httpwwwnonincomproducts

aspID=39ampsec=2ampsub=9][17] Spongycastle library [httprtyleygithubiospongycastle][18] Square up [httpssquareupcom][19] Tmg muscle fatigue monitor [httpwwwtmgsi][20] Withings blood pressure monitor [httpwwwdigifitcomwithings-

blood-pressure-monitorindexasp]

[21] Zephyr heart rate monitor [httpwwwzephyr-technologycomproductsbioharness-3]

[22] Getting ibluetooth instance httpsnipplrcomview49526 2011[23] Bodymedia puts a spin on the ordinary testing procedure httpblog

bodymediacompage6 2012[24] Android bluetoothadapter class httpdeveloperandroidcomreference

androidbluetoothBluetoothAdapterhtml 2013[25] Spooftooph httpwwwhackfromacavecomprojectsspooftoophhtml

2013[26] S Bluetooth Specification of the bluetooth systemversion 20 4

november 2004[27] S Bluetooth Rfcomm with ts 0710 Bluetooth SIG 2003[28] S Bluetooth Bluetooth core specification version 21+ edr Specification

of the Bluetooth System 2007[29] S Bugiel L Davi A Dmitrienko T Fischer A-R Sadeghi and

B Shastry Towards taming privilege-escalation attacks on android In19th Annual Network amp Distributed System Security Symposium (NDSS)Feb 2012

[30] M Conti V T N Nguyen and B Crispo Crepe context-relatedpolicy enforcement for android In Proceedings of the 13th internationalconference on Information security ISCrsquo10 pages 331ndash345 BerlinHeidelberg 2011 Springer-Verlag

[31] C Daniels Why is too much insulin bad [httpwwwlivestrongcomarticle423665-why-is-too-much-insulin-bad]

[32] M Dietz S Shekhar Y Pisetsky A Shu and D S Wallach QuireLightweight provenance for smart phone operating systems In 20thUSENIX Security Symposium San Francisco CA Aug 2011

[33] W Enck P Gilbert B-G Chun L P Cox J Jung P McDaniel andA N Sheth Taintdroid an information-flow tracking system for realtimeprivacy monitoring on smartphones In Proceedings of the 9th USENIXconference on Operating systems design and implementation OSDIrsquo10pages 1ndash6 Berkeley CA USA 2010 USENIX Association

[34] W Enck M Ongtang and P McDaniel On lightweight mobile phoneapplication certification In Proceedings of the 16th ACM conferenceon Computer and communications security CCS rsquo09 pages 235ndash245New York NY USA 2009 ACM

[35] M Handy and D Timmermann Time-slot-based analysis of bluetoothenergy consumption for page and inquiry states

[36] M Jakobsson and S Wetzel Security weaknesses in bluetooth InTopics in Cryptology CT-RSA 2001 pages 176ndash191 Springer 2001

[37] D Kugler man in the middle attacks on bluetooth In FinancialCryptography pages 149ndash161 Springer 2003

[38] C Li A Raghunathan and N K Jha Hijacking an insulin pumpSecurity attacks and defenses for a diabetes therapy system In e-HealthNetworking Applications and Services (Healthcom) pages 150 ndash 1562011

[39] R Marti J Delgado and X Perramons Security specification andimplementation for mobile e-health services eee 00241ndash248 2004

[40] M Nauman S Khan and X Zhang Apex extending android permissionmodel and enforcement with user-defined runtime constraints InProceedings of the 5th ACM Symposium on Information Computerand Communications Security ASIACCS rsquo10 pages 328ndash332 NewYork NY USA 2010 ACM

[41] M Ongtang K Butler and P McDaniel Porscha policy oriented securecontent handling in android In Proceedings of the 26th Annual ComputerSecurity Applications Conference ACSAC rsquo10 pages 221ndash230 NewYork NY USA 2010 ACM

[42] M Ongtang S McLaughlin W Enck and P McDaniel Semanticallyrich application-centric security in android In Proceedings of the 2009Annual Computer Security Applications Conference ACSAC rsquo09 pages340ndash349 Washington DC USA 2009 IEEE Computer Society

[43] E Ozdalga A Ozdalga and N Ahuja The smartphone in medicinea review of current and potential use among physicians and studentsJournal of medical Internet research 14(5) 2012

[44] J Padgette K Scarfone and L Chen Guide to bluetooth security NISTSpecial Publication 800121 2012

[45] G Portokalidis P Homburg K Anagnostakis and H Bos Paranoidandroid versatile protection for smartphones In Proceedings of the

13

26th Annual Computer Security Applications Conference ACSAC rsquo10pages 347ndash356 New York NY USA 2010 ACM

[46] M Rahman B Carbunar and M Banik Fit and vulnerable Attacksand defenses for a health monitoring device CoRR abs130456722013

[47] A Shabtai Y Fledel and Y Elovici Securing android-powered mobiledevices using selinux IEEE Security amp Privacy 8(3)36ndash44 2010

[48] Y Shaked and A Wool Cracking the bluetooth pin In Proceedings ofthe 3rd international conference on Mobile systems applications andservices MobiSys rsquo05 pages 39ndash50 New York NY USA 2005 ACM

[49] S Smalley and R Craig Security enhanced (se) android Bringingflexible mac to android In Preceding of Network and Distributed SystemSecurity Symposium 2013

[50] C A Soto A menu of bluetooth attacks [httpgcncomarticles20050720a-menu-of-bluetooth-attacksaspx] 2005

[51] D Spill and A Bittau Bluesniff Eve meets alice and bluetooth InProceedings of USENIX Workshop on Offensive Technologies (WOOT)2007

[52] S Toyssy and M Helenius About malicious software in smartphonesJournal in Computer Virology 2(2)109ndash119 2006

[53] L Zhang B Tiwana R Dick Z Qian Z Mao Z Wang and L YangAccurate online power estimation and automatic battery behavior basedpower model generation for smartphones In HardwareSoftwareCodesign and System Synthesis (CODES+ISSS) 2010 IEEEACMIFIPInternational Conference on pages 105ndash114 2010

[54] X Zhou S Demetriou D He M Naveed X Pan X Wang C AGunter and K Nahrstedt Identity location disease and more Inferringyour secrets from android public resources In Proceedings of the 2013ACM Conference on Computer and Communications Security CCS rsquo13pages 1017ndash1028 New York NY USA 2013 ACM

14

Introduction

External Device Mis-Binding

Background

Mis-bonding Threat

Attacks and Measurement

Data-Stealing Attacks

Data-Injection Attacks

Measurement of the DMB Threats

Android Device Binding Control

Overview

Design and Implementation

Evaluation

Discussion

Relatedwork

Conclusion

References

Our research shows that this DMB threat is indeed realistic andserious Specifically we thoroughly analyzed four high-profilesmartphone-enabled healthcare devices including a BodymediaLink Armband [3] (monitoring a userrsquos daily activity pattern)an iThermometer [13] a Nonin Onyx II Pulse Oximeter [15](monitoring a patientrsquos pulse and Oxygen saturation) and anEntra Health System Blood-Glucose Meter [11] These devicesare very popular and all of them except iThermometer are FDAapproved Class II medical devices However we found that thelack of a secure bonding between them and their correspondingapps leaves these devices vulnerable to different types of DMBattacks In particular in a data-stealing attack an unauthorizedapp on the authorized phone can stealthily download thedata these devices gather from a patient using nothing butits Bluetooth permission and side-channel information fordetermining the right moment for the download This mayhappen when such a device is present and the official app thatis the one the user expects to connect to the device is in factnot connected to it In a data-injection attack the maliciousapp again with a Bluetooth permission only even breaks thedevice-level Bluetooth security the app stealthily unpairs thephone from an authorized external device and pairs it with amalicious device to feed falsified medical data into the originaldevicersquos official app Demos of the attacks are posted online [6]

As the current design of Android does not provide anymeans to bond an app to an external device individualdevice manufacturers are left with no option but to developtheir own approaches to authenticate their official apps totheir devices This could be challenging given that thesedevices are often simple sensors and may not have muchresources to perform authentication operations such as runningcryptographic functions To understand how pervasive theproblem is we further conducted a measurement study inwhich we analyzed 68 official apps responsible for a widespectrum of Android external devices sampled from GooglePlay and confirmed that none of them are protected by anyapp-device authentication mechanism

Given the grave consequences of a DMB attack (compro-mises of the confidentiality and integrity of critical user data)and the credible threat it poses (the pervasiveness of vulnerabledevices) serious effort needs to be made to address this issueTo this end we present the first OS-level solution calledDabinder Dabinder works as an Android service keepingtrack of the identities of individual external devices and theapps that initiate the first Bluetooth connections with them rightafter they are paired with the phone Based on this observationa security policy is generated to tie the app to the device whichforms a bond that cannot be broken without the userrsquos consenta different app is not allowed to connect to the device nor canit unpair the phone from the device unless this access-controlpolicy is overruled by the user We implemented Dabinder andevaluated our prototype against the attacks on these popularhealthcare devices which demonstrates its effectiveness inmitigating the threat and negligible impacts on the phonersquosnormal operations We released the code of Dabinder as anAndroid 422 r1 patch which can be downloaded here [5]

Contributions We summarize the contributions of the paperas follows

bull New understanding We made the first attempt to

understand the threat of Android device mis-bondingin the context of Bluetooth bonds Our study revealsthe gravity of the threat that could lead to leaks ofsensitive user data or compromise of its integrity aswell as the prevalence of the issue among popularsmartphone-enabled devices

bull New techniques We developed the first techniquesto mitigate the threat Our approach automaticallygenerates security policies for protecting the bondingbetween an external device and its authorized appand effectively enforces the policies without impedingnormal operations on the phone

bull Implementation and evaluation We implemented ourdesign and evaluated its effectiveness and performance

Roadmap The rest of the paper is organized as followsSection II introduces the background information of our studyparticularly the generality of the device mis-bonding problemSection III elaborates our security analysis on smartphone-enabled Bluetooth devices Section IV presents the designimplementation and evaluation of our protection mechanismSection V discusses the limitations of our study and follow-upresearch Section VI compares our work with related priorresearch and Section VII concludes the paper

II EXTERNAL DEVICE MIS-BINDING

In this section we first explicate the threat of Androidexternal device mis-bonding at a high level and then clarifythe scope of our research and its underlying adversary model

A Background

The fundamental cause of the DMB problem is the inad-equacy of the Android security model in protecting externaldevices Here we provide background information about thesedevices and the way the Android security mechanism works

External devices Increasingly smartphones are used to en-hance healthcare financial management and services in othercritical domains For this purpose they often need to worktogether with specialized external devices helping preprocessthe data gathered by the devices and relaying the outcome tovarious service providers In particular smartphones today areextensively used with different medical devices for patient careand monitoring fitness health education and research [43]Examples of related health devices include WiFi or Bluetoothbased blood pressure monitor [20] ECG device [1] muscle fa-tigue monitor [19] pulse oximeter [15] heart rate monitor [21]thermometer [13] lifestyle monitor [3] [8] [9] and many othersThese devices utilize smartphones to analyze and display dataand to communicate with their corresponding web servicesThe data here is often considered sensitive as it describes anindividualrsquos health status and activities In addition to healthcaredata smartphone-enabled devices are also utilized to work onother private user information For example the Square Readercollects a userrsquos credit-card data through a phonersquos audio portand NFC devices are widely used in Europe to accept paymentsthrough phones

As a leading mobile operating system (with 75 of marketshare [2]) Android is the main platform that supports these

2














3
















4











5









on 100 trials















6










7


















8










9 0


15 0

Web communica-tion

eg HttpClient 5 0


Manual 0 0


suspicious APIs





A Overview


9














10








C Evaluation





V DISCUSSION


11




VI RELATEDWORK





VII CONCLUSION



12




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References














3
















4











5









on 100 trials















6










7


















8










9 0


15 0

Web communica-tion

eg HttpClient 5 0


Manual 0 0


suspicious APIs





A Overview


9














10








C Evaluation





V DISCUSSION


11




VI RELATEDWORK





VII CONCLUSION



12




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References
















4











5









on 100 trials















6










7


















8










9 0


15 0

Web communica-tion

eg HttpClient 5 0


Manual 0 0


suspicious APIs





A Overview


9














10








C Evaluation





V DISCUSSION


11




VI RELATEDWORK





VII CONCLUSION



12




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References











5









on 100 trials















6










7


















8










9 0


15 0

Web communica-tion

eg HttpClient 5 0


Manual 0 0


suspicious APIs





A Overview


9














10








C Evaluation





V DISCUSSION


11




VI RELATEDWORK





VII CONCLUSION



12




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References









on 100 trials















6










7


















8










9 0


15 0

Web communica-tion

eg HttpClient 5 0


Manual 0 0


suspicious APIs





A Overview


9














10








C Evaluation





V DISCUSSION


11




VI RELATEDWORK





VII CONCLUSION



12




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References










7


















8










9 0


15 0

Web communica-tion

eg HttpClient 5 0


Manual 0 0


suspicious APIs





A Overview


9














10








C Evaluation





V DISCUSSION


11




VI RELATEDWORK





VII CONCLUSION



12




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References


















8










9 0


15 0

Web communica-tion

eg HttpClient 5 0


Manual 0 0


suspicious APIs





A Overview


9














10








C Evaluation





V DISCUSSION


11




VI RELATEDWORK





VII CONCLUSION



12




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References










9 0


15 0

Web communica-tion

eg HttpClient 5 0


Manual 0 0


suspicious APIs





A Overview


9














10








C Evaluation





V DISCUSSION


11




VI RELATEDWORK





VII CONCLUSION



12




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References














10








C Evaluation





V DISCUSSION


11




VI RELATEDWORK





VII CONCLUSION



12




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References








C Evaluation





V DISCUSSION


11




VI RELATEDWORK





VII CONCLUSION



12




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References




VI RELATEDWORK





VII CONCLUSION



12




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References




ACKNOWLEDGMENT


REFERENCES



































13











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References











14

Introduction


Background

Mis-bonding Threat






Overview


Evaluation

Discussion

Relatedwork

Conclusion

References

Inside Job: Understanding and Mitigating the Threat of External Device Mis-Bonding on Android

Documents

Transcript of Inside Job: Understanding and Mitigating the Threat of External Device Mis-Bonding on Android