BadBluetooth: Breaking Android Security

Mechanisms via Malicious Bluetooth Peripherals

Fenghao Xu∗ , Wenrui Diao†‡ , Zhou Li§ , Jiongyi Chen∗ , Kehuan Zhang∗
∗ The Chinese University of Hong Kong
Email: {xf016, cj015, khzhang}@ie.cuhk.edu.hk
† Shandong University, Email: [email protected]
‡ Jinan University
§ University of California, Irvine, Email: [email protected]

Abstract—Bluetooth is a widely used communication tech- connected with each other and controlled by a phone through
nology, especially under the scenarios of mobile computing and Bluetooth.
Internet of Things. Once paired with a host device, a Bluetooth
device then can exchange commands and data, such as voice, Bluetooth has also become a lucrative target for adversaries
keyboard/mouse inputs, network, blood pressure data, and so on, due to its features like data sensitivity, transmission in the
with the host. Due to the sensitivity of such data and commands, open air, and data handling in the kernel space. Recent years
some security measures have already been built into the Bluetooth have seen lots of Bluetooth-related CVEs [11] resulting in
protocol, like authentication, encryption, authorization, etc. system crashes, information leakage or privilege escalation on
the target device. Besides the typical threats like data sniffing
However, according to our studies on the Bluetooth protocol as
well as its implementation on Android system, we find that there and weak pairing pass/PIN code, many vulnerabilities are
are still some design flaws which could lead to serious security caused by bugs in Bluetooth stacks, like kernel drivers, which
consequences. For example, it is found that the authentication could lead to code injections, arbitrary code execution, remote
process on Bluetooth profiles is quite inconsistent and coarse- crash, etc [31], [38], [40]. There are also studies related to
grained: if a paired device changes its profile, it automatically privacy issues. For example, Naveed et al. [34] discovered that
gets trust and users would not be notified. Also, there is no strict an unauthorized app could steal sensitive data by connecting
verification on the information provided by the Bluetooth device wrongfully to a third-party Bluetooth device.
itself, so that a malicious device can deceive a user by changing
its name, profile information, and icon to be displayed on the To get a deeper understanding of Bluetooth security, we
screen. conducted a systematic study on Bluetooth at the logic level,
including the underlying assumptions of the adversary model,
To better understand the problem, we performed a systematic device authentication, authorization, and security policies.
study over the Bluetooth profiles and presented three attacks
Particularly, we focus on the Android platform due to its
to demonstrate the feasibility and potential damages of such
Bluetooth design flaws. The attacks were implemented on a prevalence and its support of countless Bluetooth applications
Raspberry Pi 2 device and evaluated with different Android OS and services. In the end, we identified several new Blue-
versions ranging from 5.1 to the latest 8.1. The results showed tooth vulnerabilities even in the latest Android version. These
adversaries could bypass existing protections of Android (e.g., vulnerabilities are mainly associated with Bluetooth profile,
permissions, isolations, etc.), launch Man-in-the-Middle attack, which is a standard interface about a particular Bluetooth
control the victim apps and system, steal sensitive information, functionality (e.g., audio transmission) but never thoroughly
etc. To mitigate such threats, a new Bluetooth validation mecha- evaluated from the security perspective. For example, we found
nism was proposed. We implemented the prototype system based the current Android system assumes that a Bluetooth device
on the AOSP project and deployed it on a Google Pixel 2 phone for only would support a fixed set of profiles, but this assumption
evaluation. The experiment showed our solution could effectively
is invalid because a malicious Bluetooth device actually can
prevent the attacks.
change its claimed profiles dynamically. As a result, several
existing measures become insecure. For example, Android
I. I NTRODUCTION system will not check and notify users about the changes of
device profiles, thus a device could first pair with the host using
As a wireless communication technology, Bluetooth has a benign function/profile and then switch to another profile
been adopted by a variety of electronic products including and steal information without being identified. We also found
personal computers, smartphones and IoT devices, because that the Bluetooth device authentication is too coarse-grained
of its technical advantages in short-range data exchange. and permissive, and most profiles, including the ones created
Especially, given the context of IoT, smart devices could be dynamically, will be trusted by default once the user chooses to
pair with that device. Even worse, the process of pairing with
the device could be fully hidden to the user (see Section III
Network and Distributed Systems Security (NDSS) Symposium 2019 for more details).
24-27 February 2019, San Diego, CA, USA
ISBN 1-891562-55-X The newly discovered vulnerabilities can lead to severe
https://dx.doi.org/10.14722/ndss.2019.23482 attacks on user’s privacy. To demonstrate the potential security
www.ndss-symposium.org implications of these vulnerabilities, we devise several concrete
attack examples under the name of BadBluetooth. In one
attack, a malicious Bluetooth device could switch from a Application
legitimate profile to the Human Interface Device (HID) profile
stealthily. With such an HID profile, the malicious device could
emulate the behavior of a Bluetooth keyboard and a Bluetooth RFCOMM SDP ... GATT SCO/eSCO
mouse by injecting keystroke and mouse movements and click ATT (Audio)
events. Consequently, it is able to change phone configurations,
bypass security protections, and install malicious apps without
L2CAP
being detected. In another attack, a malicious Bluetooth device
could change its profile to Personal Area Networking (PAN)
stealthily, then launch a Man-in-the-Middle attack to sniff the Host Controller Interface (HCI)
network traffic or inject spoofing packets (like DHCP/DNS
replies pointing them to malicious servers). Bluetooth Controller

Such vulnerabilities are not bugs caused by programming

mistakes. Instead, they are rooted from the incorrect perception Fig. 1: Bluetooth Stack.
and assumptions on the Bluetooth communication. To mitigate
the security threats, we design a new validation mechanism
named Profile Binding. It enforces a fine-grained control for
the Bluetooth profiles and prevents the unauthorized changes of Bluetooth profile and connection mechanisms in details. Then,
profiles. We implemented and deployed our solution on Google we describe how Bluetooth functionalities are supported by
Pixel 2. The evaluation result showed that it can prevent the Android and how the risks are managed.
BadBluetooth attack effectively with negligible overhead.
A. Bluetooth Overview
Contributions. We summarize the contributions of this paper
as follows: Bluetooth was proposed as a wireless technology standard
to enable short-range data exchange, which was invented two
• New vulnerabilities. We investigated the design and decades ago. It has been gaining wide popularity among end-
implementation of Bluetooth on Android system and users: the forecast shows near 10 billion Bluetooth devices
identified several vulnerabilities, such as the wrong will be in use by 2018 [7], covering a variety of device types,
assumptions on device profiles, coarse-grained device including PC, mobile phone, smartwatch, car, medical appli-
authentication and authorization mechanisms, as well ances, etc. Comparing to another popular wireless standard,
as deceivable and vague user interface. i.e., Wi-Fi, which is designed for wireless local area network
(WLAN), Bluetooth is more user-centric, supporting wireless
• New Attacks. To demonstrate the feasibility and secu- personal area network (WPAN) and requiring minimum con-
rity implications of our newly discovered vulnerabili- figuration efforts. Currently, Bluetooth standard is managed
ties, we came up with several new attacks under real- by the Bluetooth Special Interests Group (SIG), and the latest
istic settings. These attacks can bypass existing data specification is Bluetooth 5.0.
isolation mechanisms of Android, causing information
leakage, changes of system security settings, etc. We Bluetooth Stack. We illustrate the abstracted Bluetooth stack
implemented and evaluated them on different Android in Figure 1. In essence, Bluetooth stack is a multi-layer
phones ranging from Android 5.1 to the latest Android architecture including the lower physical and link layers, the
8.1. middleware layer and the application layer [6]. The lower
• Defense and Evaluations. We proposed a fine-grained layers are implemented by Bluetooth chips, including radio
device profile management mechanism to mitigate the controller, baseband controller, etc. They communicate with
security threats. Also, we implemented it on Android “host”, i.e., the operating system running on the device,
8.1 and demonstrated it could address the threats through Host Controller Interface (HCI). The protocols in the
effectively. middleware layer are all implemented by the host. Different
from other communication technology like Wi-Fi, Bluetooth
Roadmap. The rest of this paper is organized as follows. protocols do not rely on the widely adopted TCP/IP stack. The
Section II gives the necessary background about Bluetooth. base-level protocol for the middleware layer is Logical Link
Section III describes the Bluetooth design flaws found in our Control Adaptation Protocol (L2CAP), which can be treated as
research. Section IV overviews the attacks against Android, TCP for Bluetooth stack. It manages the connection between
and Section V describes these attacks in details. We evaluate two Bluetooth devices, which implements features like QoS,
our attacks under real-world settings in Section VI. Our flow-control, fragmentation and reassembly mechanisms. A
defense solution is presented in Section VII. Section VIII suite of application-oriented protocols are devised on top
discusses some advanced topics, and Section X concludes this of L2CAP. For example, Radio Frequency Communications
paper. (RFCOMM) is used to generate the serial data stream, which
can replace the transmission of data over serial ports. Service
II. BACKGROUND Discovery Protocol (SDP) broadcasts the services (e.g., headset
capability) supported by the host device and the associated
In this section, we introduce the relevant background about parameters (e.g., device identifier) to other devices, in order to
Bluetooth. We first overview Bluetooth stack and describe establish the connection. To enable more efficient data trans-

2
mission, audio transport can be supported using Synchronous its own stack, named Bluedroid or Fluoride. For normal
Connection-Oriented (SCO) channel, without using L2CAP. users, they could perform Bluetooth related operations through
The application layer defines the functionalities offered to Android Settings (a system app). To interact with Bluetooth
users. stack, both an Android third-party app and the Settings app
could invoke android.bluetooth APIs to communicate
Starting from the Bluetooth 4.0, a technology named
with a system process, which is packaged as an app and
Bluetooth Low Energy (BLE) was incorporated, which aims to
located at packages/apps/Bluetooth. This system app
reduce the power consumption for new devices in healthcare
implements various Bluetooth services and profiles. Receiving
and home entertainment. New protocols like Generic Attribute
the request from the upper-level Android app, it further invoke
Profile (GATT) are included to facilitate BLE modes.
into the native Bluetooth stack code, located at system/bt.
Bluetooth Profile. To regulate the communication between
Bluetooth Permission. Since the Bluetooth communication
heterogeneous Bluetooth devices manufactured by different
may involve sensitive data, the access to the Bluetooth
vendors, the concept of Bluetooth profile was proposed, which
functionalities on Android is mediated by a set of
is characterized by a general functionality of a device. Each
permissions. A third-party app can initiate the discovery
profile contains settings to bootstrap the communications, like
of nearby Bluetooth devices or change the Bluetooth
the formats of user interface and dependencies of protocols. So
settings if the BLUETOOTH_ADMIN permission is granted.
far, there are more than 30 profiles standardized by Bluetooth
Further, with BLUETOOTH permission, the app can perform
SIG [10]. The most commonly used profile is Headset Profile
Bluetooth communication with another device, such as
(HSP), which specifies how a Bluetooth headset can be used
requesting and accepting connections. The protection levels
with mobile phones. It relies on SCO channel to encode the
for both two permissions are normal, which means any
audio and RFCOMM protocol to transfer AT commands [8] for
third-party app claiming them will be auto-granted without
control capabilities like answering a call. A device can claim a
reminding users. Since Bluetooth discovery may reveal
subset of profiles but the implementation must be compatible
the location of the user, from Android 6.0, if an app
with the standard.
requests to scan nearby devices, it has to declare either
Bluetooth Connection. Before the connection is established the dangerous-level ACCESS_COARSE_LOCATION or
between two Bluetooth devices, one device should be in the ACCESS_FINE_LOCATION permission. By default, the
discoverable mode, which can choose to respond to an inquiry pairing process needs the user’s interaction. However, a
from the other nearby device with information like device system app can avoid this with a granted signature-level
name, device class, list of services (profiles) and technical permission BLUETOOTH_PRIVILEGED.
information (e.g., manufacturer). Each device has a unique Note that, the BadBluetooth attack described in this paper
48-bit MAC address but it is usually not used in the above does not require any dangerous-level or signature-level
process. Instead, a friendly name defined by the manufacturer permissions (see details in Section IV).
or the user is displayed. However, if the inquiry initiator knows
the address of another device, the inquiry has to be answered.
III. D ESIGN W EAKNESSES
After the information is exchanged, a pairing procedure
would be executed to authenticate the remote device and pro- The existing mechanisms around Bluetooth security focus
tect the communication against eavesdroppers. Pairing usually on proving the identity of the remote device (through pairing),
involves certain user interactions to confirm the identity of the ensuring the confidentiality of the communication (through
remote device. Such a process could require a user to enter a encryption), and restricting the capabilities of the untrusted
PIN presented by the remote device or compare the numerical apps on the host (through permission). These mechanisms
code on the displays of both devices, for example. If pairing work under the assumption that the remote device is trust-
is successful, a shared secret named link key is created to worthy, say, its manufacturer or the owner certifies the device
encrypt their communications, and both devices are said to functionalities responsibly. However, such an assumption is
be bonded. If both devices memorize the pairing information not always true. More specifically, our study reveals that an
and the secret, they can connect to each other without going adversary could manipulate the profiles on a remote device in
through pairing again in the future. an unexpected way and use it as a stepping-stone to attack
the paired Android phone, casting severe threats to the phone
One thing to pay attention is that the communication for the owner.
two bonded devices is profile-centric: after retrieving necessary
information from SDP, one device has to take additional step This new problem rises mainly because the security model
to connect to the profile of the other one before using its defined by the Bluetooth stack is coarse-grained, focusing on
functionality (the first becomes initiator and the latter becomes the device level. The problem is further complicated due to
acceptor). In addition, two devices can maintain multiple the issues underlying the design of the Bluetooth framework
channels under different profiles. For example, a user’s phone on the host, e.g., Android. Below we list five key issues and
could connect to the headset profile and the keyboard profile elaborate the potential security implications for each of them.
of a single Bluetooth device at the same time.
Weakness #1: Inconsistent Authentication Process on Pro-
files. Before two devices are bonded, a user could verify the
B. Android Bluetooth
identity of the remote device with an array of measures, like
The early Android versions used Linux’s BlueZ stack as comparing the displayed PINs. However, the best practices
its Bluetooth stack. Since Android 4.2, Google developed regarding how profiles should be verified are not clear, since

3
they are never documented by Bluetooth core specifications.
As such, the device and host vendors have to come up with
ad-hoc ways for profile authentication, and mechanisms differ
significantly among these vendors or even profiles. Taking
Android as an example, the profiles are not listed during the
pairing process and are only visible to the user and adjustable
later (see Figure 2). If the device makes changes on the
profiles, it still gets trusted since pairing has already done,
and the user will not be immediately notified. Regarding how
the profile channels are set up, some require user interactions
(e.g., File Sharing) while some can be done silently through
an app (e.g., Internet Access). As such, a device can contain
adversarial functionalities without revealing them to the user
in the beginning. For instance, a headset re-programmed by
an adversary could enable Human Interface Device (HID)
profile after being paired with a phone and send unauthorized Fig. 2: Bluetooth Menu of Android (Google Pixel 2). The area
keystrokes (see Section V-A). in the red square shows the connection status - left one is
disconnected, right one is connected. The area in the purple
Weakness #2: Overly Openness to Profile Connection. To square lists the profiles currently in use, which can be adjusted
better align with the Bluetooth specifications, a Bluetooth stack by the user.
typically supports many profiles (e.g., 15 for Android 8.0 [2]).
What’s problematic here is that a pro-active approach is usually
taken by the host, like Android: once the bond is created, the
host will try its best to connect to all the profiles claimed by comparison or PIN input method become impossible. In this
the remote device, without explaining the risk to the user or case, Android phone will not prompt to users. By manipulating
letting her vet the connections. Even though the user could the device configuration, this feature could be leveraged to pair
disconnect certain profiles later in the device detail menu (see with a Bluetooth device silently.
Figure 2), such a decision is not memorized by the host. The
connections will be re-established when the devices are paired Weakness #5: No Permission Management for Profile. As
next time. described in Section II-B, Android restricts whether an app can
access a Bluetooth device through a set of permissions. How-
Weakness #3: Deceivable and Vague UI. When a user ever, such a permission framework turns out to be too coarse-
browses the list of paired Bluetooth devices, he could see grained and mis-aligned with profiles. In particular, not all
the name and the icon of the device (example shown in profiles are equally sensitive but which profile can be accessed
Figure 2), which is given by the device during the pairing is not regulated under the current permission framework. For
process. Though the information should be relevant to the instance, the profile regarding the Bluetooth keyboard (i.e.,
core functionality of the device, there is no way to certify HID) should only be accessible to a system process. How-
they are authentic. Previous research shows that a malicious ever, when a third-party app is granted BLUETOOTH_ADMIN
device can choose the same name as another validated device’s, permission, the keyboard becomes accessible automatically.
to trick the user during pairing [34]. In this work, we found Therefore, the app can further utilize the keyboard to inject
the icon can be manipulated as well for the same purpose. inputs and take control of the phone and we demonstrate a
In fact, Bluetooth specification has defined a list of Class working attack in Section V-A (the goal here is similar to
Device/Service (CoD) numbers [5] and each CoD number is the attack proposed by Fratantonio et al. [25] but our attack
associated with one icon reserved by Android. By changing the enables far more operations). So far, the protection on the
CoD number, the adversary can select the icon to be presented. critical profiles relies on removing the relevant code from the
Another issue with Android UI is the lack of Bluetooth- public APIs. However, we found a third-party app can still
relevant information. For example, only two events relevant access those profiles through Java reflection.
to Bluetooth are prompted in the notification bar: one showing Though the issue of coarse-grained Bluetooth permission
that the Bluetooth of the host is turned on, and another showing has been mentioned by Naveed et al. [34], the focus is dif-
that a remote device is connected. None of them reveals the ferent. In particular, their work shows the permission does not
status of profiles. prevent an unauthorized app (Bluetooth permission granted) to
tamper the bond of an authorized device on the same phone.
Weakness #4: Silent Pairing with Device. Pairing is supposed The issue we studied here regards profile.
to have user to verify device identity, unless the bond has been
successfully set up before. However, we found pairing can be IV. ATTACK OVERVIEW
completely hidden to the user even for the first-time setup.
When pairing request is sent from the device side, Android The goal of our research is to explore and understand
system will pop up the pairing dialog for user confirmation. how the Bluetooth peripherals can gain high privileges and
However, if the phone initiates this process, there might be no compromise user privacy in smartphones. Particularly, we
notification presented. Specifically, when the device has neither focus on the Android platform due to its prevalence and its
display ability nor input ability (e.g., headset), the pairing support of countless Bluetooth applications and services. In
falls into “Just Works” mode [6], because both numerical this section, we first introduce the adversary model in our

4
attacks. Then we describe the attack primitives and procedures. Bluetooth Bluetooth Android
In Section V, we further explore how the attacks are achieved Device App (on the phone) Phone
in real-world scenarios.
Detect phone status

A. Adversary Model
Find suitable
In this study, we make two basic assumptions. We first as- attack time

sume a malicious app with Bluetooth permissions has been in- Request pair
stalled on the victim smartphone. Being granted with the Blue- Pair
tooth permissions BLUETOOTH and BLUETOOTH_ADMIN
Inform peripheral
which are the standard and common permissions for typical
Bluetooth apps, the malicious app will be able to estab- Change profiles
lish the bond and connecting the profiles with Bluetooth to malicious
devices stealthily. Note that, since both BLUETOOTH and Perform connect
BLUETOOTH_ADMIN are just the normal-level permissions,
Connect Connect
the OS or Google Play will grant them to the malicious app
without user confirmation. Therefore, this malicious app could Launch attacks

be disguised as any type of apps, not just a Bluetooth app. As

we will show later, such a malicious app can exploit the vul- Change profiles Destroy the
to normal evidence
nerable designs in existing Android OS and Bluetooth devices
and elevate its capabilities. For example, without requesting
sensitive permissions or breaking the sandbox, it can capture Fig. 3: Attack Flow. The existence of the dotted line depends. If
the UI of other apps and steal sensitive information. the device is not paired yet, the app can request pair stealthily.
We also assume a Bluetooth device has been compromised
and its firmware now contains malicious code. Adversaries
can achieve this goal in several different ways. For example,
they can first compromise the SDK of Bluetooth devices, Then, the app creates the bond with the malicious device and
which is similar to the attack of XcodeGhost [49]. Besides, set up the profile channel. After that, the app issues commands
Bluetooth devices may be hacked by previous owners, sellers to the device to carry on the attack. We carefully design the
or during the shipping process. What is more, the adversaries attack flow to avoid any user interaction, making it hard to be
may be able to exploit the security weakness of Over-The- observed.
Air upgrading mechanism [22], especially with the help of
the malicious app previously installed. We have studied the Attack Primitives. We first describe the four attack primitives
technical documents of popular Bluetooth chip-sets, including that enable our attack. The design weaknesses discussed in
Nordic [37], Silicon Labs [32], TI [27], and found that their Section III are listed along with each primitive.
firmware verification is mainly to guarantee the transmission
• Changeable Profile (Weakness #1, #2, #3). To hide
integrity (like CRC checksum, Hash values, etc), and there
certain profile from the user (e.g., HID profile), we
is no integrity check based on digital signatures. For CSR,
instruct the device to add the profile after pairing, and
another major Bluetooth chip-sets vendor, we do not have ac-
remove it after the attack is completed. This could
cess their technical document [43], but according to messages
be achieved by programing the device to broadcast
from developers on GitHub [41], their OTA “protocol seems to
the service record related to the profile using SDP.
do challenge-response with a shared key rather than properly
Realizing the change of profiles is difficult from
signing the firmware”, which might be insecure if adversaries
the user’s perspective: the device detail menu (see
could get the key via reverse engineering (and it would be left
Figure 2) would keep the same until the new profile
for future studies).
is connected or the bond is reset. In addition, which
A large number of previous works on Bluetooth security profile is added is not shown in the notification bar.
focus on the vulnerabilities residing in the communication
protocols and implementation of the software stack. Different • Changeable Icon (Weakness #3). Device icon is an
to those works, we study the fundamental design flaws, which important indicator to help user know the functionali-
are much more difficult to fix. ties of the Bluetooth device. However, it can be easily
changed when the device modifies the CoD number.
To notice, previous works attacking the design flaw of Table I shows the icons we use to mislead user. The
Bluetooth stack or framework require the similar adversary CoD number is composed of two fields. The first field
capabilities [34]. In Section VIII, we will discuss more about describes the Major Device Class. And the second
the model and expansion of attacks. field describes the optional Minor Device Class or the
Major Service Class, which can be set to all 0. If the
B. Attack Procedure CoD number is not recognized by Android, a general
Bluetooth icon will be displayed.
Figure 3 illustrates the high-level attack procedures. We
assume the malicious app is running at the background on • Silent Pairing (Weakness #4). Previous research [34]
user’s smartphone. The attack could be launched when the and app developers [14] also constructed the
screen is turned off, which indicates that the user is not around. similar primitive. However, they rely on an

5
 TABLE I: Bluetooth Device Icons. Attack Phases. To deceive the user that the device is innocu-
ous when pairing, the device can pretend to be a smart speaker
Icon CoD Class Description
or temperature sensor by using related icons and friendly
names. The whole pairing process could also be completed
0x100 Computer stealthily. To communicate with the app, the device could use
0x200 Phone RFCOMM (regulated by Serial Port Profile), which is widely
0x404 Audio/Video-Wearable Headset
adopted by app-device communication and no profile will show
up in the menu of device details. Below we elaborate our attack
0x418 Audio/Video-Headphones
flow.
0x500 Peripheral
0x540 Peripheral-Keyboard
1) After the malicious app starts, it runs as an
Android background service or a scheduled job.
0x580 Peripheral-Pointing device
This service waits until the user is not around, by
0x600 Imaging checking whether the phone screen is off through
0x000 General Bluetooth PowerManager or whether the time is at midnight.
2) If needed, the app will turn on Bluetooth through
the API BluetoothAdapter.enable()
API (setPairingConfirmation()), which and search for the other malicious device. After
is protected with the signatured permission Android 6.0, such scanning process requires
BLUETOOTH_PRIVILEGED since Android 6.0. ACCESS_COARSE_LOCATION permission.
In contrast, our attack does not require such API However, it’s not compulsory for our attack
use. As described before, we configure the remote because the app could use the pre-stored device
device to work under the “Just Works” pairing address directly and this will not result in Bluetooth
mode. Then, the app can invoke just one API named scanning. As a result, the app could do silent pairing
createBond() using the identifier (MAC) of the to stealthily create a bond.
device. Therefore, there is no manual confirmation 3) Now the device is waiting for the commands from the
involved. app. Those commands are transmitted either through
an in-band channel (e.g., Bluetooth RFCOMM chan-
• Connecting Sensitive Profile (Weakness #5). Our nel) or an off-band channel (e.g., an Internet server
attack relies on exploiting sensitive profiles on the connected by both).
phone, which are supposed to be hidden from a third- 4) Once receiving the commands, the device enables the
party app. However, those profiles can be still ac- attack-specific profile. Since the corresponding profile
cessed regardless of the protection. Normally, Android on the phone is sensitive, the app can use the profile
assumes the app creates a proxy class to operate connection primitive to establish the profile channel.
on a profile, which encapsulates the IPC binder to In some scenarios, the device can take the first action
the Bluetooth system process. The proxy classes of to initiate the connection, and we discuss them in
the sensitive profiles are not public, but when we details in Section V. The malicious device and the app
program our app using framework.jar from a real then leverage the capabilities of the enabled profile
phone instead of android.jar from Android SDK to attack the victim, like exfiltrating sensitive data.
[1], we can directly use the non-public classes and 5) Finally, the device could disable the used profile or
methods, including the proxies of the hidden profiles. terminate the connection. Moreover, the app could
For example, as shown in the following code snippet, also unpair with the device using removeBond()
we invoke getProfileProxy() with a profile API to avoid the victim’s attention.
type INPUT_DEVICE as its parameter. If succeed,
we can receive the proxy object whose class is V. ATTACKS
BluetoothInputDevice. This class is non-public
and has a method connect(). Our app could invoke In this section, we explore what kinds of attacks could
this method to establish a channel to the input profile be achieved under the general attack model described in the
of the remote device. previous section. First we overview the supported Bluetooth
profiles on Android and the ones we exploit. Then we demon-
1 final BluetoothDevice mDevice = strate three types of concrete attacks through profile abuse.
mBtAdapter.getRemoteDevice("MAC");
2 private BluetoothInputDevice mProfile; Exploited Profiles. Table II lists the profiles supported by
3 mBtAdapter.getProfileProxy(this,new Android [2] with the corresponding usage scenarios. We do
BluetoothProfile.ServiceListenner()
4 { @override
not list the transport-layer profiles like Bluetooth Network
5 public void onServiceConnected(int Encapsulation (BNEP), Object Exchange (OBEX) in this table
profile,BluetoothProfile proxy){ since they are used to support other profiles and do not directly
6 mProfile=(BluetoothInputDevice) handle user information. In the list, Health Device Profile
proxy; (HDP) and Serial Port Profile (SPP) are used to carry data
7 mProfile.connect(mDevice); for normal user apps, which can not be leveraged to attack the
8 } phone directly. Device ID Profile (DIP) helps SDP broadcast
9 ... extra device information. The remaining profiles are evaluated
10 },BluetoothProfile.INPUT_DEVICE); for conducting our attack, and we identify three profiles which

6
 TABLE II: Android Supported Profiles TABLE III: HID Report Format
Keyboard Modifier Key Regular Keys
Name Description Usage
Mouse Button Array X Relative Y Relative Wheel
HID Human Interface Device Keyboard
PAN Personal Area Networking Network Hotspot
HFP/HSP Hands-Free/Headset Wireless Headset
receive the input and handle it. As such, our attack breaks the
SAP SIM Access Car Kit
app sandbox mechanism.
MAP Message Access Car Kit
PBAP Phone Book Access Car Kit
HID Report. When advertising the HID service, the SDP
OPP Object Push File Transfer
A2DP Advanced Audio Distribution Wireless Speaker
record contains a particular attribute - HID descriptor which
AVRCP Audio/Video Remote Control Remote Media Controller
tells the client (i.e., the phone) how to parse the payload packet.
DIP Device ID Extra Device Information
After the connection is established, the device could send a
HDP Health Device Blood Pressure Kit certain type HID report to generate a global input event on
SPP Serial Port App-specific the phone.
In our attack, we leverage the HID descriptor to support
standard mouse and keyboard functions on attack device. The
corresponding HID report data format is shown in Table III.
Bluetooth Connect In a HID report, the header specifies the report type, and
App the remaining bytes are the payload. For keyboard data, the
Privacy
payload has several key bytes and one byte bit-array for
Apps Apps
Inject input events modifier keys like “Right Control” key. For mouse data, the
payload contains X-Y axis, wheel movement data and an
Android OS
extra button bit-array. Later on, we can specify these fields
Mouse/Keyboard
to perform our attacks.
Fig. 4: HID Attack. The external device can inject input events. Attack Strategy. Next, to construct a real attack, we still need
The malicious app could steal sensitive data with the help of to address some technical challenges. Below we describe the
the device. challenges and our strategies to tackle them:

• Adaptive Attack. To position the mouse precisely on

the targeted item, a challenge here is to determine
could be leveraged – Human Interface Device (HID), Personal the position of mouse pointer. Since different phone
Area Networking (PAN), and Hands-Free/Headset (HFP/HSP). brands and Android versions usually have different UI
In the following, we introduce their capabilities and the attack layout, in attack phase 3, the malicious app will also
scenarios enabled by abusing them. collect the UI information via android.os.Build
and notify the device to activate the matched payload.
Demo. The following attacks are demonstrated with demos
On the other hand, the attack device itself can also
posted at https://sites.google.com/view/bluetoothvul/. We used
retrieve phone related information (e.g., phone brand)
Google Pixel 2 equipped with Android 8.1 in the demo.
through the SDP record of the phone. Moreover, due to
the uncertainty of initial pointer position, we move the
A. Human Interface Device pointer to left-bottom as the origin point by sending
The Human Interface Device (HID) Profile enables the enough mouse movement reports.
functionality of input devices like keyboard or mouse connect-
• Input Capability. By constructing the HID input
ing to a phone. It is designed to facilitate the user to operate her
report, we can freely move the mouse or inject
phone with an external input device. For example, some people
a key event on the phone. What’s more, we
may project their phones to an external monitor and type text
found that Android defines various functional
on it. With this capability equipped, a Bluetooth device is able
keys [4] like “Home”, “Back”, and “Volume
to perform nearly any operations a real user can do on the
Control” besides normal letters. So it is possible
phone. More specifically, Android provides the fully functional
to utilize these keys to enhance our attacks. In
keyboard and pointing device (e.g., mouse) support through
detail, when the phone receive the HID report, it
HID [3], and we can construct a input sequence equivalent to
will first parse the report payload into a Linux
any user action (e.g., mouse click can be treated as user touch).
input event based on the previous provided HID
Figure 4 illustrates the flow of our attack. The Bluetooth descriptor. Then, for keyboard, there exists an
device plays the acceptor role which is responsible for broad- mapping relationship between Linux input key code
casting SDP services. The installed malicious app initiates the and Android defined key event, which can be found in
connection process to connect the HID profile on the remote /frameworks/base/data/keyboards/Generic.kl
device. After the connection is established, this device gains of Android source code. We then adjust our HID
full control over the input channel by sending HID reports. descriptor to enable these special keys usage. We
To notice, the input from the device is global to the Android summarize some functional keys which can be
phone, meaning that any running app and home screen can applied in our attack in Table IV [4]. What is more,

7
 TABLE IV: Android Functional Keys ment. For example, after Android 6.0, all dangerous-level
permissions should be granted at runtime by user confirmation.
Linux Key Code Name Description (effect on Android)
And many security and privacy policies are controlled by the
system settings. There is no way for a normal app to modify
KEY ENTER Enter Key (click) the critical settings or perform a cross-app operation. However,
KEY TAB Tab Key (select item) by equipping with an external HID device, we can arbitrarily
KEY SYSRQ Screenshot control what we want just like normal user interaction.
KEY COMPOSE Menu Key (open menu for current app)
KEY POWER Power Key (open/close screen) For example, we can grant all the dangerous permissions
KEY WWW Explorer (launch browser app) to our app thus causing continuous damage when the device is
KEY PHONE Call (launch phone app) disconnected. And we can invade other apps by force stopping,
KEY MAIL Envelope (launch mail app) uninstalling, or injecting input events on them. Moreover, we
KEY ADDRESSBOOK Contacts (launch phone book app) are able to install another malicious app. Modifying the critical
KEY HOMEPAGE Home Key system setting preferences is easy as well. Before the attack,
KEY BACK Back Key
we could choose the proper payload which contains the UI
layout and item position information based on the Android
version and phone brand. However, the user may personalize
common shortcuts like copy (KEY CTRL+KEY C) their phone and legitimate apps may have various appearance.
and paste key (KEY CTRL+KEY V) combination To handle this problem, we could use the previous attack to
are available as well. And we also found that even get the screenshot and perform the image analysis locally or
without the mouse capability, we can simulate the remotely to get the precise layout in order to attack them
moving or clicking task by sending KEY TAB to accordingly.
select a certain item on the screen and KEY ENTER
to perform the click operation. This approach could And through our experiment, we could even shutdown or
make our attack stealthier and quicker. reboot the phone by simulating the click of the power button.
In detail, if we send KEY POWER and wait a short period
• Output Capability. Keyboard and mouse only pro- till sending the button release event, which simulates the long
vides input ability. However, if the attacker wants to press of power button, the power manage menu will pop up.
do more advanced attacks, output ability is neces- After that, we can select the shutdown or restart menu item.
sary. In other words, if we can obtain the view of
phone’s UI, we can simulate full interaction capability Attack: Beyond the Phone. Besides being the interface to help
of a user. Indeed, we found that there is a key the user process the daily tasks, the phone can also be used
named KEY SYSRQ which stands for screenshot in the as data vault, keeping user’s identity information or storing
standard key code scheme, which will truly capture the token for many applications. Therefore, if the attacker
the phone screen on Android. Thus, we can inject takes control of the phone, he may steal stored token like
this key to Android phone resulting in generating a a verification code in a text message or log himself into a
global screenshot. Besides, another way to capture website through remembered password. He may also abuse the
output is to select the texts on some views and victim identity like sending spam emails. He can even open the
then send “copy” shortcut to copy the text. Next, camera and capture the surrounding environment thus severely
the app can read the text from system clipboard by breach the victim’s privacy.
using ClipboardManager. The limitation of this
method is that not all the texts are selectable and Limitations. Some attack operations, like capturing the screen-
the information can be gathered is much less than a shot of foreground apps, will fail when the phone is securely
screenshot image. locked (for locking without PIN/Pattern, the attack still works
through simulating swiping screen). Though our attack can
As a result, with these abilities, the attack could introduce inject keyboard and mouse input, unlocking the phone would
severe consequences to the victim. We summarize them with be impossible if the user chooses PIN code that we do not
three high-level categories as follows. know beforehand or enables other strong login mechanisms.
A subset of operations are still effective under the locking
Attack: Information Stealing. Since we can capture screen- scenario, like powering off the phone and turning on the
shot globally, which can cover any foreground application in camera. To notice, the following two attacks are still effective
the screen, we can steal very sensitive information from normal even when the phone is securely locked.
or system app like private emails and messages, phone books,
etc, and send them out of the phone. For example, we can B. Personal Area Networking
grant our app the WRITE_EXTERNAL_STORAGE permission
using the input ability and fetch the screenshot then send them Next, we investigate how the network communication can
out via Internet (a normal permission). Or we can use input be tampered by exploiting the Personal Area Networking
ability to transfer them through another app like Web Browser (PAN) profile, which manages the networking functionality
(open a malicious uploading website) or Email. Finally, the through Bluetooth channels. This profile relies on BNEP
app can delete the screenshot to destroy the evidence. protocol and defines 3 roles - Network Access Point (NAP),
Group Ad-hoc Network (GN), and PAN User (PANU). A
Attack: App and System Controlling. Most security mech- common use case is that one device who has an additional
anisms on Android phone are enforced with user’s involve- network resource like smartphone can act as a NAP to forward

8
 A mechanism we want to mention here is the network
resource priority on Android. As we know, the Android phone
can use Wi-Fi and cellular network to access Internet beyond
Bluetooth. So if multiple network sources appear, Android will
Bluetooth Connect to NAP automatically choose one through an internal ranking scheme.
App
Through our investigation, we found Bluetooth network has
Apps Apps
Malicious DNS
the highest base score than other frequently used network types
(Wi-Fi and cellular data). What is more, Android will conduct
Android OS
a connectivity testing (e.g., ping a google website) before the
Network Access Point
final decision and deduct points if the testing fails. So we
can easily manage the network to select our Bluetooth NAP
(a) Device as NAP as long as the testing is passed, which naturally holds if the
device owns Internet access ability.
The whole process can be done in the background even
Bluetooth Connect to NAP when the phone is securely locked. And we noticed that even
App
when the phone is unlocked and used by the user, our attack
only introduces an inconspicuous change in the notification
Apps Apps
Download data bar, if a Wi-Fi connection has been established (a small mark
on Wi-Fi icon). If the phone does not use Internet initially, we
Android OS
can enforce it as well. In summary, through this attack, we can
Personal Area Network User
force all the Internet traffic on the phone to go through our
(b) Device as PANU
device. As a result, we can intercept sensitive information or
do the spoofing attack.
Fig. 5: PAN Attacks. Figure (a) shows that the device can sniff
and spoof traffic of the phone. Figure (b) shows the device can Attack: Network Consumption. From another angle, the
consume the host network bandwidth without permission. phone can also act as a NAT and share its network resource
via Bluetooth. So in this attack, the device claims its iden-
tity as a PANU and try to connect and share the phone’s
network. Ideally, Android ought to forbid such connection
by default and require user interaction. In reality, opening
Ethernet packets and provide DHCP service usually at the the Bluetooth tethering could be easily done by an app
same time. The other device will be the PANU to share the without any privileged permission granted. The API we used is
network bandwidth of the NAP. Both roles are supported by setBluetoothTethering() of BluetoothPan class.
Android but there is no protection mechanism in place to To notice, this setting is global which is effective for all the
prevent a malicious app or device from abusing these roles. external devices as well. Again, this implies the problematic
We construct two attacks as shown in Figure 5. implementation of Bluetooth management on Android.

Attack: Network Sniffing and Spoofing. Since the phone As a result, once the app enables that setting, the device can
could access Internet via the Bluetooth device, it is possible try to connect to the phone NAT. With that, the device could
to provide the NAP service on the device side and do the send out collected information or receive data for firmware
network Man-in-the-Middle attack. In this attack, we enable updating. Besides, the device can consume the network mali-
the standard NAT service on the device and wait for the ciously to cause extra data usage.
connection from the phone. Once the phone is connected, the
Bluetooth device would receive all the Ethernet packets carried C. Hands-Free
by BNEP from the phone and pass it to a pre-build virtual
bridge. The bridge can then forward the traffic to a remote Bluetooth supports audio transmission in two means. As
entity if the device has its own Internet access component. shown in Section II, the first one is to transfer the audio
Then we can intercept all the traffic on that bridge. Note that signal natively by SCO channel. The latter one utilizes packets
accessing Internet can be achieved via a embedded sim card to distribute the audio data (Advanced Audio Distribution -
(cellular network), wired or wireless Internet connection of the A2DP). Headset Profile (HSP) and Hands-Free Profile (HFP)
device itself. Many IoT devices like smart speakers have built are two typical profiles relying on SCO channel, while we
in such capability. And for the case that the device itself cannot focus on HFP since it supports more features than HSP and
access the Internet, it can still sniff a part of traffic like login has been widely adopted nowadays. A headset device imple-
request which contains sensitive information. menting HFP allows user to perform operations (e.g., make
phone calls) by issuing the commands without touching the
After establishing the Bluetooth network connection, the phone. Also, the device could receive the telephony audio and
phone (PANU) will query for the networking settings from answer phone calls using HFP. Therefore, when a malicious
the NAP. The DHCP server on the virtual bridge can listen for device implements HFP, it will be able to manipulate the audio
this query and return a malicious DNS server address. This input and receive the audio output of the phone. Figure 6 shows
DNS server could be a public server owned by the attacker or how an attacker can abuse these profiles to compromise user’s
just built upon the device. privacy.

9
 Bluetooth Connect to HF
App

Apps Apps
Incoming calls
Outgoing calls
Android OS Voice command
Hands-Free Unit

Fig. 6: HFP Attack. After connection, the Bluetooth device

can control the incoming and outgoing calls. Also, it can inject
voice command if Google Assistant is enabled.

Attack: Telephony Control. HFP defines two roles - Audio

Gateway (AG) and Hands-Free Unit (HF). AG like a cellular
phone can transfer the telephony status and open SCO con-
nection for streaming the voice to HF (typically a headset).
And the HF could issue several commands like accepting,
rejecting an incoming call or terminating the current call, etc.
In this attack, the device will claim the HF role, and wait for Fig. 7: Experimental Devices.
connection from the phone. Initially, AG and HF will establish
a RFCOMM channel to exchange the handshake message and
phone status using various AT Command. Then based on the
telephony situation, the device may send command to answer, VI. I MPLEMENTATIONS AND E VALUATIONS
reject or terminate an incoming call. What is more, the device
is able to dial arbitrary number resulting in a outgoing calls. In this section, we introduce the technical implementations
of our attacks and discuss its scope.
All the functions mentioned above could be done on
a locked Android phone. Under our attack model, we can Hardware Setup. We used a Raspberry Pi 2 (900MHz quad-
successfully force the phone to connect to the HFP-enabled core ARM CPU with 1GB memory) as the attack device, as
device thus taking over the telephony function. For example, shown in Figure 7. It runs Raspbian, a customized Linux OS.
the device can record an incoming call and answer with Also, a CSR8510 Bluetooth USB dongle is attached because
prepared voice file. no built-in Bluetooth chip is on Raspberry Pi 2. In practice, a
bare-metal device equipped with low-cost Bluetooth chip [9]
Attack: Voice Command Injection. Besides the telephony is sufficient to launch our attacks. The smartphone used as the
function, we found the HFP can also trigger the Google Voice host is Google Pixel 2 equipped with Android 8.1.
Assistant. And by default, this Google service will allow
Bluetooth headset to send voice command even when the
phone is securely locked. In the attack, we first trigger the Implementations. We implemented a prototype of attack
assistant and open the audio connection. Then we can inject program (for Raspberry Pi 2) with around 1,100 Python lines
any voice command it supports. However, we found the voice of code. Our implementation was mainly based on the Py-
feedback is carried by A2DP rather than HFP SCO channel. Bluez [16] package which encapsulates the build-in BlueZ [12]
So the device could claim the A2DP profile at same time and (Linux Bluetooth protocol stack) of Raspbian and could man-
once connected, the phone will send the voice feedback to age the system Bluetooth resources. The main feature provided
the device. As a consequence, the attacker is able to inject by PyBluez is to establish an L2CAP or RFCOMM connection.
commands and steal information through the voice channel Also, some open-source softwares or libraries are integrated
stealthily. into our attack program for specific purposes. In details, the
HID attack was implemented utilizing raw L2CAP channel
directly. To the PAN attack, tcpdump [18] and dnsmasq [13]
D. Other Profiles are used to sniff network traffic and set up DHCP/DNS servers.
In the HFP attack, we used pulseaudio [15] to handle the
Besides the profiles we tested above, SIM Access (SAP), audio processing and ofono [17] to verify the feasibility of this
Message Access (MAP), Phone Book Access (PBAP) and attack. In the real attack, we used raw RFCOMM to achieve
Object Push Profile (OPP) are potential targets. However, those it.
profiles require the Bluetooth device to be the initiator and
the phone to be the acceptor, which is opposite to the attack Besides, a malicious Android app is needed to assist
flow described before (see Section IV-B). As a result, the launching the BadBluetooth attack. Its functionality is simple,
user will be notified when the Bluetooth device requests to mainly for connecting to the Bluetooth device. We invoked
connect under those profiles and the request has to be approved Android hidden APIs to implement such a requirement, as
manually, making the attack less stealthy. illustrated in Table V.

10
 TABLE V: Attack Implementations on Android Third-party
Settings App
Apps App
Attack Invoked APIs Framework

HID BluetoothInputDevice.connect()
PAN BluetoothPan.setBluetoothTethering()
BluetoothPan.connect()
HFP BluetoothHeadset.connect()
PAN
HID
Adapter Pairing Profile Connection
...
Service Monitor Binding Policy Service Controller
TABLE VI: Attack Results DB

Bluetooth
Process
Phone Brand OS Vulnerable

Google Pixel 2 AOSP Android 8.1 Yes

Google Nexus 6 AOSP Android 7.1 Yes‡ Bluetooth
Google Nexus 6 AOSP Android 6.0 Yes‡ Stack Kernel

Sony Xperia XZs Sony Official Android 8.0 Yes‡

Samsung Galaxy S7 Samsung Official Android 7.0 Yes‡
Huawei P10 Huawei Official Android 8.0 Yes‡∗ Fig. 8: Overview of the Profile Binding mechanism. The black
Meizu M3 Note Meizu Official Android 5.1 Yes‡∗ lines show the original communication flow, while the white
blocks and blue lines represent our defense framework.
‡ :Exclude Network Consumption Attack
∗ :Exclude Voice Command Injection Attack

Architecture. Figure 8 illustrates the updated architecture of

Scope of Attacks. To evaluate the scope of our attacks, we the Android Bluetooth subsystem that deploys our defense
selected the other 6 Android phones equipped with different framework. This framework contains three main modules:
Android OSes (from Android 5.1 to the latest Android 8.1) Binding Policy DB, Pairing Monitor and Connection Con-
and tested the attacks against them. In our experiment, Google troller. In the original design of the Bluetooth subsystem,
Voice Assistant is only available on the phones equipped any upper-layer apps including Settings app (under user’s con-
with Google Service Framework (GSF). Therefore, the voice trol) could communicate with the Android Bluetooth process
command injection attack was not tested on Huawei P10 and through IPC requests. For example, an app can initiate the pair-
Meizu M3 Note. Besides, we found the WRITE_SETTINGS ing using AdapterService.createBond() or establish
permission is needed to launch network consumption attack the profile connection through various ProfileService.
except Google Pixel 2 (Android 8.1). Except for the above
two attacks, all the other attacks were successfully launched After deploying our defense, any unauthorized pairing
on all phones as listed in Table VI. and connection intent will be prohibited. The pairing mon-
itor module integrated into AdapterService will create
binding policies for Bluetooth devices. Then the connec-
VII. P ROFILE B INDING FOR A NDROID tion controller module performs a policy validation in each
ProfileService.
The design flaws of the Bluetooth stack and the BadBlue-
tooth attacks described in this paper should be fixed timely. In Note that, all three defense modules are integrated within
this section, we propose a lightweight solution named Profile the Android Bluetooth process, which ensures every pairing
Binding for Android, which provides a fine-grained control for or connection intent from upper layer will be checked. All
the Bluetooth profiles and better visibility of profiles to user. Bluetooth Java APIs regarding pairing and profile connecting
will finally fall into this system process. Though there exist
native Bluetooth functions like createBondNative() and
A. Overview connectHidNative(), it is still impossible to bypass our
The high-level idea of our protection mechanism is to defense through native code. According to our investigation as
enhance the control of Bluetooth profiles and prevent the well as mentioned in [34], only the Bluetooth process has the
unapproved changes of profiles. In particular, we bind the privileged permission to access the underlying Bluetooth stack
device with a permitted profile list and prohibit other profile directly, which is protected by the Linux user-based access
connections. In practice, when processing a pairing request, the control mechanism.
system will prompt a selection list containing the advertised
profiles of the external Bluetooth device for the user to Workflow. The defense is implemented around the binding
approve. After that, the system will create a binding policy policy which is generated in the Bluetooth pairing phase.
based on the user’s selection, and further mediate every profile As described before, either the phone or the device could
connection intent to enforce the policy checking. initiate the pairing. For the former case, both third-party
apps and the user (through Settings app) will finally in-
As a result, this mechanism could let user vet the device voke the API AdapterService.createBond() with
profile and prevent unnoticed profile changing. Meanwhile, the target device’s MAC address. In the latter case, when
the silent pairing weakness is immediately addressed since the the Android Bluetooth process receives an external pairing
pairing process could not be hidden to the user anymore. request, the callback function sspRequestCallback() or

11
pinRequestCallback() of AdapterService will be
called.
For both pairing cases, our defense framework will pop up
a dialog showing the profiles declared by the Bluetooth device
(extracted from its SDP records). After the user selects the
permitted profiles manually, a policy record which binds the
user’s choice (a profile list) with the device (MAC address)
will be inserted into the policy database. Therefore, our
scheme supports the user to vet the device explicitly and
prevents the silent pairing behavior. The policy associated with
each device will be validated whenever ProfileService
receives a connection intent. If the profile type indicated by
the connection appears in the policy record of the target
device, this connection request will be approved and sent to
the Bluetooth stack. Otherwise, this connection request will be
rejected. As a result, the BadBluetooth attack will be prevented
because a malicious device could not hide or change its profile
without user permission.

B. Implementation Fig. 9: Pairing dialog example of our defense. This dialog is

Our proposed defense solution could prevent the BadBlue- shown when a pairing process happens.
tooth attacks and address the current Android Bluetooth weak-
nesses in the meantime. In the following parts, we describe
the improvements to each weakness and the corresponding
technical implementations of each module. C. Defense Coverage
As discussed in Section V-D, for some profiles like OPP,
Pairing Monitor (Weakness #1, #2, #4). The pairing monitor the device may initiate the connection without broadcasting
module inspects both the incoming and outgoing pairing in SDP. It is out of the scope of our defense, because, in the
requests. Then it fetches the device SDP to generate the profile original mechanism of the Android Bluetooth stack, it will
candidate list. After that, as shown in Figure 9, it presents a notify the user appropriately. Alternatively, our scheme can
multi-choice dialog for user confirmation. We also remove the unify all profiles by showing them together at the pairing (no
original system dialog (if it exists) and merge with ours to matter the device claims or not). However, such design is not
enhance the user experience. Finally, we save the permitted user-friendly as a long list will be shown to the user every
profiles as a bitmap associated with the device using the time. So, we did not follow this approach.
Settings.Secure storage, which cannot be modified by
third-party apps. Through this approach, we prevent silent
pairing and provide a fine-grained control method for users. D. Evaluation
To evaluate the defense effect and corresponding overhead,
Connection Controller (Weakness #1, #2, #5). This module we conduct several experiments on Google Pixel 2, which has
locates profile by ProfileService to enforce the policy a 2.35 GHz processor and 4GB memory with our modified
validation. We adopt the whitelist approach to restrict the AOSP Android 8.1.
connection. Specifically, only if the device (MAC address) is
registered in the policy database and the desired profile is set Effectiveness. To examine the effectiveness of the profile
to be allowed, this connection could pass through. Otherwise, binding mechanism, we launched all the attacks described in
it gets denied immediately. Moreover, to unpair a device, the Section V on the phone. We found that all the pairing process
Adapter.removeBond() will be invoked. In this case, we is monitored and prompted to users, and only explicitly granted
will remove the device policy record accordingly. profiles can be connected. Therefore, the BadBluetooth attack
is completely mitigated by our defense framework.
Settings App (Weakness #1, #3). To enhance the usability
for users, we also create the updateProfile method on Performance. Pairing to an external device is adjusted to be
the policy database and only expose it to the Settings app noticed by the user, and our system should not cause prominent
(protected by privileged permission). Therefore, the user could delay of UI-transition. In the meantime, the performance of
adjust the profile preference (binding policy) later. Moreover, normal operations should not be impacted. Given that the
to provide more meaningful information and reveal potential policy validation is supposed to be most time-consuming
risk, we modify the Bluetooth icon mechanism. In our scheme, among all the introduced components, we instrumented the
the device icon is chosen by its “behavior”. Specifically, it is connect() methods and measured the execution time delay
always the job of supporting profiles of a device to determine for certain profile connection (HID, PAN, and HFP). Our
the icon. If a device claims more than one profile, the most measurement process excludes the native function execution.
“dangerous” one will be presented. We define the danger level For each profile connection, we conducted the test 10 times.
as: HID > PAN > HFP > Others. The results are shown in Table VII. We can see the delays

12
 TABLE VII: Profile connection evaluation. (mean/std) Future Directions. Firstly, we plan to investigate the attack
feasibility of above mentioned app-based BadBluetooth. Be-
ProfileService Class Original Defense Delays Total∗ sides, Bluetooth firmware updating is also an appropriate entry
(µs) (µs) (µs) (µs) point to study Bluetooth security. We will consider them as
HidService 494.9/63.0 605.5/49.0 110.6 2546.0/589.4 future directions.
PanService 235.8/45.8 460.4/43.1 224.6 1890.5/420.5
HeadsetService 473.5/62.4 522.2/66.5 48.7 2359.3/326.1
In this work, we mainly focused on Android platform.
∗ :From
However, the exposed weaknesses and problems may still
upper-layer API call to connection completion (original Android exists on other OS platforms like iOS, Windows or Linux. For
OS).
example, through a preliminary study on these platforms, we
found none of them provides a good solution to the UI issue.
Windows relies on the CoD number instead of the real profiles.
are from 48.7µs to 224.6µs, which is hardly perceivable. iOS does not display icons when scanning nearby devices, and
Comparing with the total time cost (from upper layer API some Linux versions use a unified Bluetooth icon for all types
calls to connection completion), the delay is less than 12%. of devices. Therefore, users may have to face difficulties in
figuring out the real identity of a Bluetooth device. What is
more, the profile authentication problems could still exist due
VIII. D ISCUSSION to the vague Bluetooth specifications. Similar to the attacks on
Android, a malicious insider could leverage the potential flaws
We first discuss the limitations of our attack in this section. to launch attacks. The complete attack implementations rely
Then we describe other adversary models to be considered on the specific Bluetooth resource management mechanisms
to expand BadBluetooth attack. In addition, we believe the on different platforms. Therefore, it would also be a potential
weaknesses we discovered are not just limited to a single research direction to study in the future.
device or a single OS. Therefore, in the long run, the protection
should not only rely on the platform-specific implementations Bluetooth Design. Though the concrete attacks could be
but also need to reconsider the design of Bluetooth stack. mitigated, the fundamental design weaknesses discovered in
this paper cannot be addressed by Android itself. We believe
Responsible Disclosure. Before the submission, we have these design weaknesses should be fixed on Bluetooth specifi-
reported our findings to the Android security team responsibly. cations in the long run. Looking through the whole Bluetooth
They acknowledged the problems and are developing the specification, it puts many efforts to the functional diversity,
corresponding solution. We will work further with them to transmission performance, and so forth. However, the security
better understand the issues underlying Bluetooth design and requirement is neglected to some extent and mainly relies on
develop new defense mechanisms accordingly. the implementation of device vendors.

Limitations and Extensions of BadBluetooth. Our adversary We believe it is not a correct understanding that the
model requires both a malicious device and a colluded app to Bluetooth device or host should be treated as one single
successfully launch the BadBluetooth attack. Here we discuss entity in the current Bluetooth standard. The reason is that the
other scenarios when some components are not controlled modern smart device like smartphone involves multiple parties
by attacker initially. If we assume only the malicious app is and could play a role of the platform for the installed apps
installed on the victim smartphone, then the app is able to which could share all Bluetooth resources. Also, we believe
discover and exploit nearby devices through Bluetooth channel. the profile-level authentication is necessary, and some kinds
For example, a vulnerable Bluetooth device (e.g., has Blue- of standard verification procedure should be added.
tooth driver or application code bugs) may be compromised Moreover, the device name and displayed icon is usually
to install malicious profiles or remotely controlled by the app. the only indicator for end users to distinguish the device. As a
In another example, the firmware updating process could be result, users may naively trust a device based on such indicator
leveraged to compromise a Bluetooth device (as mentioned in when doing pairing or connection operations. However, neither
Section IV). As a result, the attack is still feasible when there the device name nor the icon is reliable. The OS usually shows
are vulnerable Bluetooth devices. the icon just based on the claimed device type no matter what
profiles it contains. Therefore, we think there should be a better
We implemented the attacks using Raspberry Pi 2, a dedi-
mechanism to help users to verify the device.
cated device as the Bluetooth peripheral. However, we found
the host like smartphone itself could also be programmed like
an external device since its underlying Bluetooth controller has IX. R ELATED W ORK
the same capabilities. The difference is that an app located in In this section, we review the previous studies about the
the user space can only access limited APIs provided by the security issues on Bluetooth and peripheral devices.
OS. Through taking advantage of smartphone Bluetooth stack,
attacks are still possible without a physical device, which leads Bluetooth Security. The early works on Bluetooth security
to a more general threat model. For example, we note that focused on the vulnerabilities underlying the protocols and
future Android version plans to bring the HID device ability implementations. The early versions of Bluetooth have been
to normal app [26]. As a result, an app might be able to make a found to suffer from attacks like sniffing [40], man-in-the-
phone behave like a mouse or a keyboard. Therefore, it brings middle attack [31], PIN cracking [38], etc. On the Android
the risk that a malicious app controls its host phone to attack platform, Naveed et al. [34] discovered the security issue
another connected phone through the Bluetooth channel. of external device mis-bonding. The issue could enable an

13
unauthorized app downloading sensitive user data from an machine. Recently, Tian et al. [46] carried out a comprehensive
Android device. The similar vulnerabilities also exist on the survey on the research in USB security. The study suggests
iOS platform [21]. Different from them, our attacks aim to most of the USB attacks abuse the trust-by-default nature
break Android system by abusing various Bluetooth profiles. of the USB ecosystem and only a comprehensive defense
BlueBorne [19] is an attack vector discovered in 2017 which solution expanding multiple layers would success in practice.
contains 8 zero-day Bluetooth vulnerabilities across multiple We believe many issues residing in USB ecosystem also
platforms. This attack could penetrate and take control over exist in the Bluetooth ecosystem in similar fashions, and the
targeted devices, even without pairing to the attacker’s device. research in the Bluetooth domain could leverage the outcomes
While, our attacks don’t rely on any software bugs. from the USB domain.
Some recent research concentrated on the security of
Bluetooth Low Energy (BLE). For exmaple, Kolias et al. [29] X. C ONCLUSION
indicated that BLE Beacon devices are susceptible to a variety Bluetooth is an essential technique for short-distance and
of attacks, including Beacon hijacking, user profiling, presence low-power communications and becomes more popular with
inference, etc. Sivakumaran et al. [39] found some BLE the advent of the Internet of Things. The security of Bluetooth
devices allow unauthenticated reads and writes from third devices plays a critical role in protecting user’s privacy
party devices. Also, Sławomir et al. [28] demonstrated several and even personal safety. In this paper, we performed a
possible attacks on the GATT (Generic Attribute Profile) layer systematic study over the Bluetooth profiles and discovered
of the Bluetooth stack, and Ryan et al. [36] presented several five design weaknesses. We further presented a series of
techniques for eavesdropping BLE conversations. attacks to demonstrate the feasibility and potential damages
In addition, some research has demonstrated the feasibility of such flaws on Android, including stealing information,
of user tracking exploiting Bluetooth. Das et al. [23] found app controlling, network sniffing, voice command injection,
majority of the fitness trackers use unchanged BLE address etc. Besides, we designed a defense solution on Android to
while advertising, making it feasible to track users. Korolova effectively prevent such attacks. Moreover, we believe these
et al. [30] achieved cross-app user tracking through advertising newly discovered flaws are not just limited to a specific OS
packets broadcasted by nearby BLE-enabled devices. As a version. Broad Android versions are vulnerable, from 5.1 to the
defense, Fawaz et al. [24] proposed a new device-agnostic latest 8.1, and similar problems may also appear on other OS
defense system, called BLE-Guardian, that protects the pri- platforms. These flaws are rooted from the widely incorrect
vacy (device’s existence) of the users/environments with BLE understandings and assumptions on the Bluetooth stack. We
devices/IoTs. believe they should be just the tip of the iceberg, and the
Bluetooth standard still needs a thorough security review.
In this paper, we target the latest Bluetooth stack and
discover several high level design weaknesses which could lead
to attacks causing severe consequences. These design flaws are ACKNOWLEDGEMENT
not bounded to a specific platform or OS version. We thank anonymous reviewers for their insightful com-
ments. This work was partially supported by National Natural
Peripheral Devices and Security. In addition to Bluetooth, Science Foundation of China (Grant No. 61572415), and the
previous works also reveal that many other peripheral devices General Research Funds (Project No. 14208818 and 14217816)
can be exploited to attack their host computers easily, with established under the University Grant Committee of the Hong
USB peripherals gaining the most attention. Wang et al. [48] Kong Special Administrative Region, China. Wenrui Diao was
introduced attacks targeting the physical USB connectivity supported in part by the Fundamental Research Funds for the
between a smartphone and their computers. Maskiewicz et Central Universities (No. 21618330).
al. [33] presented a case study of the Logitech G600 mouse,
demonstrating the feasibility of attacking airgapped periph-
erals. More recently, Su et al. [42] exploited the electrical R EFERENCES
properties of USB hubs and achieved crosstalk leakage attacks. [1] “Android Hidden API project on GitHub,” https://github.com/
anggrayudi/android-hidden-api, Accessed: May 2018.
In 2014, Nohl et al. [35] proposed a comprehensive USB
[2] “AOSP Bluetooth Services,” https://source.android.com/devices/
attack vector named BadUSB. They showed by registering a bluetooth/services, Accessed: May 2018.
BadUSB device with multiple device types, it is possible to [3] “AOSP Input Overview,” https://source.android.com/devices/input/, Ac-
take any action on the host without authorization. To address cessed: May 2018.
this issue, Tian et al. [47] presented a defense solution named [4] “AOSP Keyboard Device,” https://source.android.com/devices/input/
GoodUSB. They designed a permission model and a mediator keyboard-devices, Accessed: May 2018.
to manage the risks during the enumeration phase of the [5] “Bluetooth Baseband Assigned Number,” https://www.bluetooth.com/
USB protocol. This model is based on the insight that a specifications/assigned-numbers/baseband, Accessed: May 2018.
device’s identity should rely on the end user’s expectation [6] “Bluetooth Core Specification,” https://www.bluetooth.com/
of the device’s functionality. A series of research on the specifications/bluetooth-core-specification, Accessed: May 2018.
attack and defense of USB peripherals are conducted following [7] “Bluetooth-enabled Devices Worldwide in 2012 and 2018,”
this direction, including USBFILTER – a packet-level USB https://www.statista.com/statistics/283638/installed-base-forecast-
bluetooth-enabled-devices-2012-2018/, Accessed: May 2018.
firewall [45], and ProvUSB – an architecture for block-
[8] “Bluetooth Headset Profile,” https://www.bluetooth.org/DocMan/
level provenance for USB storage devices [44]. Also, Angel handlers/DownloadDoc.ashx?doc id=158743& ga=2.24560186.
et al. [20] proposed a virtualization-based solution, which 1866324813.1527819756-910667369.1527819756, Accessed: May
attaches peripheral devices to a logically separate, untrusted 2018.

14
 [9] “Bluetooth Product on TI,” http://www.ti.com/wireless- [32] S. Labs, “An1045: Bluetooth over-the-air device firmware update
connectivity/simplelink-solutions/bluetooth-low-energy/products.html, for efr32xg1 and bgm11x series products,” https://www.silabs.com/
Accessed: May 2018. documents/login/application-notes/an1045-bt-ota-dfu.pdf.
[10] “Bluetooth Profiles Overview,” https://www.bluetooth.com/ [33] J. Maskiewicz, B. Ellis, J. Mouradian, and H. Shacham, “Mouse Trap:
specifications/profiles-overview, Accessed: May 2018. Exploiting Firmware Updates in USB Peripherals,” in Proceedings of
[11] “Bluetooth related CVEs,” https://cve.mitre.org/cgi-bin/cvekey. the 8th USENIX Workshop on Offensive Technologies, WOOT ’14, San
cgi?keyword=bluetooth, Accessed: May 2018. Diego, CA, USA, August 19, 2014., 2014.
[12] “Bluez - Official Linux Bluetooth Protocol Stack ,” https://www. [34] M. Naveed, X. Zhou, S. Demetriou, X. Wang, and C. A. Gunter, “Inside
bluetooth.com/specifications, Accessed: May 2018. Job: Understanding and Mitigating the Threat of External Device Mis-
Binding on Android,” in Proceedings of the 21st Annual Network and
[13] “Dnsmasq Homepage,” http://www.thekelleys.org.uk/dnsmasq/doc. Distributed System Security Symposium (NDSS), San Diego, California,
html, Accessed: May 2018. USA, February 23-26, 2014, 2014.
[14] “Programmatically pair Bluetooth device without the user entering [35] K. Nohl and J. Lell, “BadUSB–On accessories that turn evil,” Black
pin - Stack Overflow,” https://stackoverflow.com/questions/19047995/ Hat USA, 2014.
programmatically-pair-bluetooth-device-without-the-user-entering-pin,
Accessed: May 2018. [36] M. Ryan, “Bluetooth: With Low Energy Comes Low Security,” in
Proceedings of the 7th USENIX Workshop on Offensive Technologies
[15] “PulseAudio Homepage,” https://www.freedesktop.org/wiki/Software/ (WOOT), Washington, D.C., USA, August 13, 2013, 2013.
PulseAudio/, Accessed: May 2018.
[37] N. Semeconductor, “Updating firmware over the air,” http://infocenter.
[16] “Pybluez Homepage,” https://pybluez.github.io/, Accessed: May 2018. nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.tools%
[17] “Source Package on Debian - ofono,” https://packages.debian.org/ 2Fdita%2Ftools%2FnRF Connect%2FnRF Connect DFU.html,
source/sid/ofono, Accessed: May 2018. August 2018.
[18] “TCPDUMP/LIBPCAP Public Repository,” https://www.tcpdump.org/, [38] Y. Shaked and A. Wool, “Cracking the Bluetooth PIN,” in Proceedings
Accessed: May 2018. of the 3rd International Conference on Mobile Systems, Applications,
[19] “The Attack Vector “BlueBorne” Exposes Almost Every Connected and Services (MobiSys), Seattle, Washington, USA, June 6-8, 2005,
Device,” https://www.armis.com/blueborne/, Accessed: May 2018. 2005.
[20] S. Angel, R. S. Wahby, M. Howald, J. B. Leners, M. Spilo, Z. Sun, A. J. [39] P. Sivakumaran and J. B. Alı́s, “A Low Energy Profile: Analysing
Blumberg, and M. Walfish, “Defending against Malicious Peripherals Characteristic Security on BLE Peripherals,” in Proceedings of the
with Cinch,” in Proceedings of the 25th USENIX Security Symposium Eighth ACM Conference on Data and Application Security and Privacy
(USENIX-SEC), Austin, TX, USA, August 10-12, 2016., 2016. (CODASPY), Tempe, AZ, USA, March 19-21, 2018, 2018.
[21] X. Bai, L. Xing, N. Zhang, X. Wang, X. Liao, T. Li, and S. Hu, “Staying [40] D. Spill and A. Bittau, “BlueSniff: Eve Meets Alice and Bluetooth,” in
secure and unprepared: Understanding and mitigating the security risks Proceedings of the First USENIX Workshop on Offensive Technologies
of apple zeroconf,” in Proceedings of the 37th IEEE Symposium on (WOOT), Boston, MA, USA, August 6, 2007, 2007.
Security and Privacy (Oakland), San Jose, CA, USA, May 22-26, 2016, [41] P. Stone, “Consider blocklisting qualcomm csr firmware update service,”
2016. https://github.com/WebBluetoothCG/registries/issues/20, March 2017.
[22] A. Bellissimo, J. Burgess, and K. Fu, “Secure software updates: [42] Y. Su, D. Genkin, D. C. Ranasinghe, and Y. Yarom, “USB Snooping
Disappointments and new challenges,” in 1st USENIX Workshop on Made Easy: Crosstalk Leakage Attacks on USB Hubs,” in Proceedings
Hot Topics in Security, HotSec’06, Vancouver, BC, Canada, July 31, of the 26th USENIX Security Symposium (USENIX-SEC), Vancouver,
2006, 2006. BC, Canada, August 16-18, 2017., 2017.
[23] A. K. Das, P. H. Pathak, C. Chuah, and P. Mohapatra, “Uncovering [43] C. Support, “Cs-327746-rp-1-training and tutorials - csr over-the-
Privacy Leakage in BLE Network Traffic of Wearable Fitness Trackers,” air-update,” https://www.csrsupport.com/download/49800/CS-327746-
in Proceedings of the 17th International Workshop on Mobile Comput- RP-1-Training%20and%20Tutorials%20-%20CSR%20Over-the-Air-
ing Systems and Applications (HotMobile), St. Augustine, FL, USA, Update.pdf, March 2017.
February 23-24, 2016, 2016.
[44] D. J. Tian, A. M. Bates, K. R. B. Butler, and R. Rangaswami, “Provusb:
[24] K. Fawaz, K. Kim, and K. G. Shin, “Protecting Privacy of BLE Block-level provenance-based data protection for USB storage devices,”
Device Users,” in Proceedings of the 25th USENIX Security Symposium in Proceedings of the 2016 ACM SIGSAC Conference on Computer and
(USENIX-SEC), Austin, TX, USA, August 10-12, 2016, 2016. Communications Security (CCS), Vienna, Austria, October 24-28, 2016,
[25] Y. Fratantonio, C. Qian, S. Chung, and W. Lee, “Cloak and Dagger: 2016.
From Two Permissions to Complete Control of the UI Feedback [45] D. J. Tian, N. Scaife, A. M. Bates, K. R. B. Butler, and P. Traynor,
Loop,” in Proceedings of the IEEE Symposium on Security and Privacy “Making USB Great Again with USBFILTER,” in Proceedings of the
(Oakland), San Jose, CA, May 2017. 25th USENIX Security Symposium (USENIX-SEC), Austin, TX, USA,
[26] J. Greig, “How Android P plans to turn your phone into a bluetooth key- August 10-12, 2016., 2016.
board or mouse,” https://www.techrepublic.com/article/how-android-p- [46] D. J. Tian, N. Scaife, D. Kumar, M. Bailey, A. Bates, and K. Butler,
plans-to-turn-your-phone-into-a-bluetooth-keyboard-or-mouse/. “SoK: “Plug & Pray” Today – Understanding USB Insecurity in
[27] T. Instruments, “Over-the-air download users guide for ble-stacktm Versions 1 through C,” in Proceedings of the 39th IEEE Symposium
version: 2.2.1,” https://e2e.ti.com/cfs-file/ key/communityserver- on Security and Privacy (Oakland), San Francisco, CA, USA, May 21-
discussions-components-files/538/CC2640-BLE-OAD-User 2700 s- 23, 2018, 2018.
Guide.pdf, October 2016. [47] J. D. Tian, A. M. Bates, and K. R. B. Butler, “Defending Against
[28] S. Jasek, “GATTacking Bluetooth Smart Devicess,” in Black Hat USA Malicious USB Firmware with GoodUSB,” in Proceedings of the
Conference, 2016. 31st Annual Computer Security Applications Conference (ACSAC), Los
[29] C. Kolias, L. Copi, F. Zhang, and A. Stavrou, “Breaking BLE Beacons Angeles, CA, USA, December 7-11, 2015, 2015.
For Fun But Mostly Profit,” in Proceedings of the 10th European [48] Z. Wang and A. Stavrou, “Exploiting Smart-Phone USB Connectivity
Workshop on Systems Security (EUROSEC), Belgrade, Serbia, April For Fun And Profit,” in Proceedings of the 26th Annual Computer
23, 2017, 2017. Security Applications Conference (ACSAC), Austin, Texas, USA, 6-10
[30] A. Korolova and V. Sharma, “Cross-App Tracking via Nearby Bluetooth December 2010, 2010.
Low Energy Devices,” in Proceedings of the Eighth ACM Conference [49] C. Xiao, “Update: Xcodeghost attacker can phish passwords and open
on Data and Application Security and Privacy (CODASPY), Tempe, AZ, urls through infected apps,” http://researchcenter.paloaltonetworks.com/
USA, March 19-21, 2018, 2018. 2015/09/update-xcodeghost-attacker-can-phish-passwords-and-open-
[31] D. Kügler, ““Man in the Middle” Attacks on Bluetooth,” in Financial urls-though-infected-apps/, September 2015.
Cryptography, 7th International Conference, FC 2003, Guadeloupe,
French West Indies, January 27-30, 2003, Revised Papers, 2003.

15