Preface
Bluetooth is a short-range wireless communication technology that enables data exchange between fixed and mobile devices. It can be said that Bluetooth is one of the most popular and widely used wireless technologies in the world today. With the rapid development of the Internet of Things (IoT), Bluetooth technology has also accelerated its pace of development to meet the growing market and user demands. The Bluetooth Special Interest Group (SIG) is continually working to improve Bluetooth’s transmission speed to better integrate Bluetooth technology into various IoT devices.
Bluetooth Low Energy (BLE) is part of the Bluetooth 4.0 specification, which includes traditional Bluetooth and Bluetooth High-Speed protocols. Compared to traditional Bluetooth, BLE aims to use less power while maintaining the same communication range. BLE transmits small amounts of data only when needed and stays off otherwise, greatly reducing its power consumption, making it an ideal choice for long-term, low-data-rate connections. BLE is well-suited for use in TV remote controls but is not suitable for wireless media streaming devices that require high data transmission.
BLE is built into many appliances or smart devices we use today, such as smartphones, smart TVs, medical devices, coffee machines, and more.
Why is BLE popular?
Multiplatform support, the following devices and platforms support Bluetooth 4.0 and BLE:
iOS5+ (iOS7+ preferred) Android 4.3+ (numerous bug fixes in 4.4+) Apple OS X 10.6+ Windows 8 (XP, Vista, and 7 only support Bluetooth 2.1) GNU/Linux Vanilla BlueZ 4.93+ Windows Phone
BLE sounds good but is it really?
From a security perspective, this is an excellent question. The fact is – BLE is just a protocol. Manufacturers can implement BLE securely in their devices. However, if the random number generator cannot generate numbers that are “strong enough”, even the strongest encryption protocols can be broken, and this also applies to BLE. Therefore, in other words, the security of BLE is actually in the hands of its implementers.
Although all development motivation for low-power Bluetooth devices is to enhance user experience, the question we need to consider is whether security is synchronized with this advancement?
Below, let’s look at three main vulnerabilities that affect BLE security:
1. Eavesdropping
Consider regular BLE communication, with a phone on one end and a BLE device on the other. If there is no authenticated encryption between the two, one could use a BLE Sniffer nearby before the communication starts and see the plaintext communication data between the phone and the BLE device.
2. MITM Attack
MITM (Man in the Middle) attack refers to a third-party device inserting itself into the BLE communication link, falsifying communication data to deceive both parties.
If Device A and Device B are about to communicate, and Device M notices their intention to communicate, Device M intercepts the connection request sent by Device A, masquerading as Device B to establish a connection and communicate. Afterward, it masquerades as Device A to initiate a connection request to Device B, establishing a connection and repeating the data sent earlier by Device A. In this manner, Device A would continuously think it is communicating with Device B, and so would Device B, unaware of the presence of a third party in between.
3. Denial of Service Attack
As most wireless devices today use built-in battery packs, these devices are susceptible to denial of service (DoS) attacks. DoS attacks can cause the system to crash frequently and exhaust its battery power. Fuzzing attacks can also cause system crashes by sending malformed or non-standard data to the device’s Bluetooth radio to check its response, ultimately bringing down the device.
Core Concepts of BLE
BLE has two fundamental concepts:
GAP – Generic Access Profile GATT – Generic Attribute Profile
GAP
GAP (Generic Access Profile) is mainly responsible for controlling device connection and broadcasting. GAP makes your device visible to others and determines if your device can and how it interacts with other devices.
GAP defines several roles for devices, with the two main ones being: Peripheral and Central devices.
Peripheral device: This is generally a very small or simple low-power device used to provide data and connect to a relatively more powerful central device. Central device: The central device is relatively more powerful and is used to connect to other peripheral devices, such as smartphones.
Broadcasting Protocol
GAP’s broadcasting workflow is shown in the diagram below:
>
In GAP, peripheral devices broadcast data through two means: Advertising Data Payload and Scan Response Data Payload, with each type containing up to 31 bytes. Broadcasting data is essential, as peripherals need to continuously broadcast to let central devices know about their presence. Scan Response is optional; the central device can request a scan response from the peripheral, which contains additional information like the device’s name.
GATT
GATT (Generic Attribute Profile) defines how two BLE devices communicate through Service and Characteristic. GATT uses the ATT (Attribute Protocol) protocol, where the protocol data of Service and Characteristic is stored in a lookup table, using a 16-bit ID as the index for each item. Once a connection between two devices is established, GATT starts working, meaning that GATT only activates after GAP-managed broadcasting workflow is complete.
GATT’s two main concepts:
Services Characteristics
Service
A Service divides data into independent logical items, containing one or more Characteristic. Each Service has a UUID that uniquely identifies it. UUID can be 16 bit, or 128 bit. 16-bit UUIDs are officially certified and require purchasing, while 128-bit ones are custom that you can set freely.
There are some standard Services approved officially, with a complete list here. Taking Heart Rate Service as an example, its officially approved 16-bit UUID is 0x180D, which includes three Characteristics: Heart Rate Measurement, Body Sensor Location, and Heart Rate Control Point, with only the first being mandatory and others optional for implementation.
Characteristic
The lowest level in GATT transactions is the Characteristic, the smallest logical data unit, though it may contain a group of associated data, such as the X/Y/Z-axis values of an accelerometer.
Similar to Service, each Characteristic is uniquely identified by a 16-bit or 128-bit UUID. You can freely use the Bluetooth SIG defined Standard Characteristics, ensuring that your BLE software and hardware can understand each other. Of course, you can customize Characters, but only your software and your peripherals will understand each other.
For instance, the officially recognized TX power UUID by SIG is 0x1804.
>
Tools for Utilizing BLE
Linux provides the best support for BLE. To utilize BLE, we need to install blueZ. Use the following command:
sudo apt-get install bluezHere, I am using a computer with an Ubuntu system, which will act as a central gateway communicating with other peripheral devices. Once installation is complete, we need two tools to scan, connect, and read/write data.
hcitool gatttool
Before we start, we need to scan nearby BLE devices. After finding them, we need to establish connections, read/write data, and find vulnerabilities for exploitation. Hence, hcitool is an essential tool for us.
hcitool
hcitool makes use of the host controller interface in laptops to communicate with BLE devices and perform read/write/change operations. It can be used to locate broadcasted available target BLE devices and then connect to modify their values.
But to change values/data, we must first know the service and characteristic. Therefore, we need to use gatttool.
gatttool
gatttool’s function is to identify the available services and characteristics of BLE devices, to perform read/write operations on victim data.
Command Cheatsheet
|
Command |
Function |
|---|---|
|
hciconfig |
Used to configure Bluetooth devices. We can run this command to list BLE dongles and their basic information connected to our computer. |
|
hciconfig hciX up |
Turn on a Bluetooth device named hciX |
For more commands, refer to: https://helpmanual.io/man1/hciconfig/
Hcitool Commands
hcitool is used to configure Bluetooth connections and send specific commands to Bluetooth devices.
|
Command |
Function |
|---|---|
|
hcitool -i hciX |
Use hciX interface. Defaults to the first available interface if not specified |
|
hcitool scan |
Scan traditional Bluetooth devices in discoverable mode |
|
hcitool lescan |
Scan BLE Bluetooth devices |
For more commands, refer to: https://helpmanual.io/man1/hcitool/
Gattool Commands
|
Command |
Function |
|---|---|
|
gatttool -I |
Start gatttool in interactive mode |
|
gatttool -t random -b [adr] -I |
Start gattool in interactive mode using random LE address. Connect to remote Bluetooth device with address adr. |
|
primary |
Check available services on connected BLE device |
|
characteristic |
Check available characteristics on the connected BLE device from which we can read data |
|
char-desc |
Characteristics Descriptor discovery |
|
char-read-hnd |
Read characteristic |
|
char-write-req |
Write value to handle |
For more commands, refer to: https://helpmanual.io/man1/gatttool/
Example Usage
hciconfig: List all connected BLE adapters.
hciconfig hciX up: Enable a BLE adapter named hciX.
hciconfig hciX down: Disable a BLE adapter named hciX.
hcitool lescan: Scan for nearby BLE devices.
After obtaining the address of the BLE device, we need to connect to it using gatttool.
gatttool -I: Start gatttool in interactive REPL mode where users can send various commands as shown below.
connect: Connect to a BLE device using the specified address.
If devices only connect using phones and not computers, the above steps may not work. To connect these devices, we need to use a random address.
gatttool -t random -b -I: Connect to the device using a random address.
Once connected, we can use commands to view services and characteristics of the device.
Primary
Characteristics
After discovering services and characteristics, we need to know the handle where we can read/write data using the char-desc command.
We can also use commands like char-desc 01 05, to filter displayed handles to a specific range. This command will display handles from 1 to 5.
Once we find the handle, we read data from it using the char-read-hnd command.
To write to a specific handle, we need to know which one is the write handle. We can try reading each handle one by one until reading errors appear. A read error means the specific handle is a write handle (because write handles cannot be read). Or, you can use apps like nrf connect to automatically identify the write handle for you.
Handle 0x000b has a UUID, as shown below:
After using nRF Connect, I obtained the following output, which confirmed for us that handle 0x000b is indeed a write handle. The UUID of handle 0x000b matches with nRF connect in the above image.
After connecting to a light bulb, we can write random values to different characteristics. In most cases, writing random values will not work as expected. To write correct values into the handle, we need to decrypt the data protocol and can use sniffing tools like Wireshark and Ubertooth.
Once the data protocol is decrypted, we can use the char-write-req command to write values into the handle.
If there’s an error with char-write-req, we can use char-write-cmd instead.
Bluetooth hci snoop log
Since Android 4.4, an option was added to record all Bluetooth packets entering and leaving the device. To enable Bluetooth traffic capture, follow these steps. Make sure the Android app is installed.
Step 1: Open phone settings and enable developer options.
Step 2: Open “Developer options” and enable Bluetooth HCI snoop log.
Step 3: Run the Android app (magic blue) and send some color-changing instructions to the bulb, repeat the operation several times.
Step 4: We can find the Bluetooth traffic capture file in /sdcard/btsnoop_hci.log or /internal Storage/btsnoop_hci.log.
Note – In some devices, btsnoop_hci.log may be created elsewhere, such as /sdcard/Android/data/btsnoop_hci.log.
Use email or Google Drive to transfer the captured log file to a computer, or you can connect the Android device to the PC using a USB data cable.
Step 5: Analyze the captured packets in Wireshark. Wireshark is a free open-source packet analysis tool; if you don’t have it installed, you can use the following command:
sudo apt install wireshark-qtFor content about how to use Wireshark for analysis, refer to: https://blog.attify.com/exploiting-iot-enabled-ble-smart-bulb-security/
Alternatively, you can open the capture file in a text editor like nano.
Using nRF Connect
nRF connect can also be used for sniffing and writing data.
Step 6: Open the nRF Connect app and connect to BLE bulbs.
Step 7: After connecting, write payload value 56b0306000f0aa. Click send, and the bulb’s color will change.
This is because the RGB value of the color is 176, 48, 96, or B03060 (hexadecimal). The command we send to the bulb is 56 b0 30 60 00 f0 aa. The second, third, and fourth bytes correspond to the RGB values in hexadecimal, respectively.
Please provide the original heading you would like to be rewritten, including the keyword Bluetooth technology.
Using Bleach to Attack BLE
Bleah is a BLE Bluetooth scanner based on the bluepy python library.
Before using it, we need to meet the following software and hardware conditions:
Hardware
Linux computer, preferably with Ubuntu system Smart BLE bulb or any other smart Bluetooth device Bluetooth adapter
Software
Python 2.7 (default installation on Ubuntu) Bluepy library Bleah
We need to make sure the Bluepy library works properly first.
Go to the bluepy directory, open a terminal, and type:
sudo ./bluepy-helper 0 le onAs shown below:
(Note: Bluepy installation path, simply running bluepy-helper can locate it)
Success indicates Bluepy is working properly. Next, let’s see how to use Bleah to attack BLE.
Step 1: In the same terminal, enter the Scan command to scan for nearby BLE devices.
Our BLE device address is: F81D78607184
Step 2: Open a new terminal and enter the command sudo bleah -t0, where t0 indicates continuous scanning.
Step 3: We can connect to specific devices and enumerate all Services and Characteristics.
sudo bleah -b "aa:bb:cc:dd:ee:ff" -eaa:bb:cc:dd:ee:ff is the device address -b Filters by device address -e Connect to device and perform enumeration
Step 4: Write data to a specific characteristic of operation.
sudo bleah -b "aa:bb:cc:dd:ee:ff" -u "0000ffe9-0000-1000-8000-00805f9b34fb" -d "data"
Bleah is a very powerful tool for attacking BLE devices, automatically performing many operations and saving us from repetitive complex operations.
The above is what I’ve introduced as some tools and techniques for attacking BLE devices. I hope this article helps you gain a deeper understanding of BLE and related attack techniques.