Bluetooth, as we know, is one of the most popular and widely used wireless technologies in today’s world. With the rapid growth of IoT accelerating development in Bluetooth technology, constant efforts are being taken by the Bluetooth Special Interest Group (SIG) to increase the transfer speed with a maximum focus on beacons, healthcare entertainment, and fitness.

Bluetooth Low Energy (BLE) is a part of the Bluetooth 4.0 specification which additionally also includes Classic Bluetooth and Bluetooth High Speed Protocols. Compared to classic Bluetooth, BLE is intended to use lesser power while maintaining similar communication range. BLE is an "always off" technology and only transmits short amounts of data when required. This significantly reduces power consumption making it ideal to use in cases where a persistent long term connection is required with a low data rate. BLE is perfect for a TV remote but not for a wireless media streaming device which needs a large amount of data to transmit.

Bluetooth Low Energy is built into many of the gadgets that we use today. From smartphones, smart televisions, advanced technologies such as medical equipment to a basic devices such as our coffee machines, all use BLE.

Nokia originally developed BLE for an in-house project called ‘WIBREE,’ which was later on, taken over by the Bluetooth SIG. BLE was conceived with an emphasis on better pairing speed and energy efficiency. .

What makes BLE stand out?

• Enables multi-platformed communication: Can easily communicate via a large number of devices that run on Android, iOS, Linux, Windows Phone, Windows 8, and OS X
• Better pairing speed
• Helps maintain a connection for longer periods of time
• Significantly lower implementation costs
• Energy efficient

BLE does sound good but, is it really all that good?

That’s a good question from a security standpoint. The fact is - BLE is just a protocol. It’s up to the manufacturers to implement BLE securely in their device. Even the strongest cryptographic protocol has been known to fail due to the random number generator not being "random enough." The same applies to BLE. Thus, it can be said that the security of BLE lies in the hands if its implementers.

While all Bluetooth Low Energy devices were developed with the principal motive of enhancing user experience, did security take a backseat during the process?

Let us have a look at the three main vulnerabilities that BLE may expose its users to:

1. Eavesdropping: As the name suggests, eavesdropping refers to a third party device listening in on the data that’s being exchanged between two paired devices. A connection between two paired devices signifies a chain of trust. The chain gets broken when one of the device is removed. An attacker may use the device unit number for getting access to other Bluetooth connected devices. Even if the encryption/ decryption keys on the device were to be deleted, the attacker may brute force the PIN number offline using a Bluetooth Sniffer (using the ID of the device). Once the PIN is derived, the device can easily be hijacked.
2. Man in the Middle Attacks (MITM): Man in the middle attacks involve a third party device impersonating a legitimate device, tricking two legitimate devices into believing that they’re connected to each other, when in reality, the legitimate devices are connected to the impersonator. This sort of an attack enables the attacker/impersonator to access all the data that is being exchanged between the devices and also, manipulate data by deleting it or changing it, before it reaches the respective device.
3. Denial of Service & Fuzzing Attack: Since most wireless devices these days work on inbuilt battery packs, these devices run the risk of being exposed to Denial of Service Attacks (DoS). DoS attacks expose a system to the possibility of frequent crashes leading to a complete exhaustion of its battery. Fuzzing attacks too lead to systems crashing as an attacker may send malformed or non-standard data to a device’s Bluetooth radio and check its response, ultimately overwhelming it.

Core concepts in BLE

There are two basic concepts in BLE.

• GAP - Generic Access Profile
• GATT - Generic Attribute Protocol

Generic Access Profile (GAP)

This is responsible for the connections and advertising in BLE. GAP is responsible for the visibility of a device to the external world and also plays a major role in determining how the device interacts with other devices.
The following two concepts are integral to GAP:

Peripheral devices : These are small and low energy devices that can connect with complex, more powerful central devices. Heart rate monitor is an example of a peripheral device.

Central devices : These devices are mostly cell phones or gadgets that have an increased memory and processing power.

Advertising process

This illustrates how the advertisement and scan response payload work.

The peripheral device will send an advertising data once every 2 seconds. If the central device is ready to listen to the advertisement packets, it will respond with a scan response request.

In response to this request, the peripheral device will send a scan response data. Thus, the central and peripheral device gets advertised and connected with each other.

Generic Attribute Protocol (GATT)

Making use of a generic data protocol known as Attribute Protocol, GATT determines how two BLE devices exchange data with each other using concepts - service and characteristic. This protocol stores all the service and characteristic in a lookup table using a 16 bit IDs as specified by the Bluetooth SIG. It’s vital to note that GATT gets initiated only after the advertising process governed by GAP has been completed.

The two main concepts that form GATT are

• Services
• Characteristics

Services
Services are simply defined as a cabinet which can hold many drawers in it, which in turn are called as characteristics. A service can have many characteristics. Each service is unique in itself with a universally unique identifier (UUID) that could either be 16 bit in size for official adapted services or 128 bit for custom services.

Characteristics
Characteristics are the most fundamental concept within a GATT transaction. Characteristics contain a single data point and akin to services, each characteristic has a unique ID or UUID that distinguishes itself from the other characteristic. For example HRM sensor data from health bands etc.

Here are the SIG specifications for the characteristics and services for BLE devices. Any BLE device which has officially adopted UUID’s by SIG must use the ID specified by them in their applications.

For example the official TX power UUID as mandated by the SIG is 0x1804.

A beacon which is scanned by the nRF Connect app (more on this later) must have the same TX power UUID as per the specifications of SIG.

Tools for exploiting BLE

Linux offers the best support for BLE. In order to use BLE, we need to install the bluetooth stack (blueZ). It can be installed by running

sudo apt-get install bluez

We will use a PC/Laptop running Ubuntu with bluez installed. This device will work as the central gateway for communicating with other peripheral devices. BlueZ’s goal is to program and implement Bluetooth wireless standards specifications. After installing this, we need two tools to scan, connect, and read/write data.

1. hcitool
2. gatttool

Before starting, we need to scan for BLE devices in our vicinity. If there's one we need to find out how to connect to it, read/write the data and hopefully discover a vulnerability in it which can later be used for exploitation. For these purposes, the hcitool is indispensible.

hcitool

It makes use of the host controller interface in a laptop to communicate and read/write changes to BLE devices. hcitool is therefore, useful in finding out the available victim BLE device that advertises, and then in changing the values after connection.

The values/data can only be changed if one knows the service and characteristic the data is coming from. In order to find out the relevant services and characteristics, one may use a gatttool.

gatttool

As mentioned in the previous paragraph, gatttool is mainly helpful in finding out the services and characteristics of an available BLE device so that the victim’s data can be read/written according to the attacker.

Command cheatsheet

General purpose commands

Command	Function
hciconfig	Used to configure Bluetooth devices.  We can run this command to list the BLE dongles connected to our computer  along with basic information about them.
hciconfig hciX up	Turns on the Bluetooth device named hciX

More commands: https://helpmanual.io/man1/hciconfig/

Hcitool commands

hcitool is used to configure Bluetooth connections and send some special command to Bluetooth devices.

Command	Function
hcitool -i hciX	Use the interface hciX for the command. If not specified, defaults to the first available interface
hcitool scan	Scans for classic Bluetooth devices which are in discoverable mode
hcitool lescan	Scans for BLE devices

More commands: https://helpmanual.io/man1/hcitool/

Gattool commands

GATT stands for Generic Attribute and defines a data structure for organizing characteristics and attributes. We can discover, read, and write characteristics using gatttool.

Command	Function
gatttool -I	Launch gatttool in interactive mode
gatttool -t random -b [adr] -I	Launch gattool in interactive mode using a random LE address. Connect to the remote Bluetooth device having address adr.
primary	Check for available services of the connected BLE device
characteristic	Check for available characteristics of the connected BLE device from where we can read data
char-desc	Characteristics Descriptor Discovery. Check for n no of handles
char-read-hnd	Read characteristic by their handle
char-write-req	Write values to the handle

More commands: https://helpmanual.io/man1/gatttool/

Example usage

hciconfig : Used to list all the attached BLE adapters.

hciconfig hciX up : Enable the BLE adapter named hciX.

hciconfig hciX down : Disable the BLE adapter named hciX.

hcitool lescan : Scan for BLE devices in the vicinity.

After obtaining the address of the BLE device we need to connect to it and this is when we use gatttool.

gatttool -I : Launches gatttool in an interactive REPL like mode where the user can various issue commands as listed below.

connect <addr> : Connect to the BLE device with the specified address.

In case of devices that only connect with phones and not to a computer, the above steps might not work. In order to connect with such devices, we need to use a random address.

gatttool -t random -b <addr> -I : Connect to the device using a random address.

After successful connection, we can see the services and characteristics of the device using the commands.

Primary

Characteristics

After finding services and characteristics, we need to know the handles by which we can read/write data using the char-desc command.

We can also filter the displayed handles to a particular range using a command like char-desc 01 05 which displays 5 handles from 1 to 5.

After finding the handle, we need to read the data from it using the command char-read-hnd <handle>.

In order to write to a specific handle, we need to know which one is a write handle. For this, we can go for a hit and try method and try reading all the handles one by one until we encounter a read error. A read error means the specific handle is a write handle (write handles cannot be read). Alternatively, apps like such as nrf connect can automatically figure out the write handles.

The handle 0x000b has a UUID as in the image below

Using nRF Connect, we get the following output which confirms handle 0x000b is indeed a write handle. The UUIDs of handle 0x000b in the above image and below in nrf connect matches.

After connecting to the bulb, we can write random value to the different characteristics. In most cases, writing random values will not work as expected. To write the correct values in the handle, we need to decipher the data protocol, which can be found out using sniffing tools like wireshark and ubertooth.

After deciphering the data protocol, we can write the values in the handle using the command char-write-req <handle> <value>

If the char-write-req reports an error we can use char-write-cmd instead.

Bluetooth hci snoop log

Android starting from version 4.4 onwards has an option to record all bluetooth packets going in/out from the device. To enable capture of bluetooth traffic follow the steps below. Ensure that the android app is installed.

Step 1 : Go to mobile Settings and enable the developer option.

Step 2 : Go to "developer option" and enable Bluetooth HCI snoop log.

Step 3 : Run the android app (magic blue) app and send some commands to the bulb to change its color. Repeat this several times.

Step 4 : Corresponding to our commands we can find the captured file of the Bluetooth traffic at /sdcard/btsnoop_hci.log or /internal Storage/btsnoop_hci.log

Note - In some devices, btsnoop_hci.log is created in a different location like /sdcard/Android/data/btsnoop_hci.log.

Transfer the captured log file to a computer/laptop using Email, Google Drive or you can connect the android device to your laptop via USB cable.

Step 4 : Analyze the capture packets in Wireshark. Wireshark is a free and open source packet analyzer tool and can be installed by running

sudo apt install wireshark-qt

For more information on how to use Wireshark for analysis refer to our blog GHOST_URL/exploiting-iot-enabled-ble-smart-bulb-security/

Alternatively, you can open this capture file in a text editor like nano.

Using nRF Connect

The nRF connect app from Nordic Semiconductor can also be used BLE hacking. It can both sniff as well as write data just like gatttool.

Step 5: Open the nRF Connect app and connect with the BLE bulb.

Step 6 : Once connected, write the payload value 56b0306000f0aa. Click on send. The bulb color will change to a shade of burgundy.

This is because the color has a RGB value of 176, 48, 96 or B03060 in hexadecimal. The command we sent to the bulb was 56 b0 30 60 00 f0 aa. Note the second, third and fourth byte correspond to the RGB value in hex.

We can figure out the protocol by manually analyzing the traffic and trying to find a pattern in it.

Using Bleah for BLE attacks

Bleah is a BLE scanner. It's based on the bluepy python library. In this section, we are going to see how we can "hack" BLE devices using Bleah.

To get started, we will need

Hardware

• A Laptop running Linux preferably Ubuntu
• A Smart BLE bulb or any other Bluetooth Smart Device
• A Bluetooth Adapter

Software

• Python 2.7 (Installed by default on Ubuntu)
• Bluepy library
• Bleah

First ensure, Bluepy is working as expected.

Go to bluepy directory. Open a terminal and type
sudo ./bluepy-helper 0 followed by le on as shown below

(Note: For finding the path where Bluepy is installed simply run which bluepy-helper)

A success message indicates Bluepy is functioning correctly. Now, lets see how we can use Bleah for BLE hacking.

Step 1: In the same terminal type Scan to scan for BLE devices in the vicinity.

Our BLE device address is F81D78607184

Step 2: Open another terminal and run sudo bleah -t0 where t0 means to scan continuously.

Step 3: We can connect to the specific device and enumerate all the Services and Characterstics using.

sudo bleah -b "aa:bb:cc:dd:ee:ff" -e

where,
aa:bb:cc:dd:ee:ff stands for device address
-b means to filter by device address
-e means to connect to the device and perform enumeration

Step 4: For writing data to a specific characteristics run.

sudo bleah -b "aa:bb:cc:dd:ee:ff" -u "0000ffe9-0000-1000-8000-00805f9b34fb" -d "data"

As we just saw, Bleah is a powerful tool for conducting attacks on BLE devices. It automates many of the steps which otherwise we need to do manually.

With this, we come to an end to this blog post where we learnt various tools and techniques for performing attacks on Bluetooth Low Energy Devices. Hope you find this post useful. For any queries, suggestions, or improvements feel free to leave a comment below. Your ideas are always welcome.