This article opens a series of cybersecurity-focused articles, created by the members of the expert team at UDV Technologies. This piece focuses on a still relevant Bluetooth Low Energy 4.0 - 4.1 vulnerability, but we'll cover many topics as we go. If you'd like us to cover something specific - please let us know in the comments. And of course feel free to share if you find it useful and interesting.

Before we even start, here's why this vulnerability still matters:

Updating Bluetooth and BLE versions is impossible since they depend on the adapter integrated into the device’s motherboard.

In the contemporary world, the term Bluetooth is rather overloaded. Let’s name the first thing that comes to mind when thinking of Bluetooth. Wireless speakers, activity trackers, remote controls, keyboards, mice and other things associated with the Internet of Things (IoT)? Most of them, in fact, transfer data over Bluetooth Low Energy (BLE or Bluetooth Smart).

BLE protocol is a Bluetooth core specification defined in the Bluetooth 4.0 standard featuring lower energy consumption in comparison with the classic protocol version.

Note: Bluetooth SIG 4.0 + versions support two standards: BR/EDR and Low Energy. Bluetooth devices are divided into three types:

1. Bluetooth Classic
2. Bluetooth Low Energy
3. Devices that support both protocols.

In fact, most Bluetooth adapters embedded in phones, notebooks and other gadgets belong to type 3.

Most contemporary portable devices communicate over BLE. Access to smart watch, wireless sensors or other devices can help an adversary access your phone or computer. So here is the question: is it even safe to use devices with BLE support?

To answer the question, we need to understand the first phase of the pairing process. Pairing can be divided into several phases:

• Phase 1. Pairing feature exchange
• Phase 2. LE legacy pairing or LE Secure Connections
• Phase 3. Transport specific key distribution

Understanding how devices decide which method to use in Phase 2 requires additional knowledge on pairing packet format. In Phase 1, the devices exchange packets with their features and decide on a pairing method. Here’s what the pairing packet format looks like.

The protocol format shows that the pairing method depends on the specified flags. When SC flag is set on both devices, they will use Secure connection for pairing, otherwise, fall back on Legacy pairing.

Phase 2 depends on the supported protocol version. For pairing details, refer to Bluetooth SIG official site or check out Intro to Bluetooth Low Energy by Mohammad Afaneh. Now let’s take a closer look at LE legacy pairing Phase 2. The phase has various vulnerabilities that allow potential adversary to decrypt all data exchanged by the devices.

To understand the essence of the vulnerability and the remediation methods implemented in the contemporary BLE version, we are going to dive into the protocol operation theory. Three legacy pairing methods exist:

1. Just Works – the temporary key is set to 0. Definitely not the safest method
2. Out of Band (OOB) – a different method is used e.g. NFC. The security of this option depends on the technology used
3. Password – 6 digit pin code is used.

While selecting a pairing method for Legacy pairing, devices will follow the table shown below.

Note: the table for Secure Connection is different.

In order to understand the protocol we need to introduce a few terms:

• Temporary Key (TK). Temporary key generation depends on selected pairing method. For legacy methods TK is generated each time when paring is performed.
• Short Term Key (STK). Short term key is generated using temporary key, shared by both devices, each time during pairing for transferred data encryption during current connection.  It is implemented in legacy connection methods only.
• Long Term Key (LTK). Long term key is generated and saved on the device during the third phase of the authentication in legacy connection methods and during the second phase in safe connection methods.  It is preserved on each device and subsequently used to establish connection between two devices.
• Mrand and Srand – random 128-bit numbers generated by the initiator and responder respectively.
• Mconfirm and Sconfirm – 128-bit confirmation values calculated by c1 function.

When Use IO Capabilities method is selected, the devices will execute another step to determine the pairing method. Multiple factors such as display and other input-output device availability affect the choice.

If the devices agree on the second method, it makes analysis complicated due to the wide range of implemented technologies; however, we can focus on methods #1 and #3. So, after selecting the pairing method, step 2 is executed in accordance with the algorithm below.

1. Mrand & Srand values are generated by both sides.
2. C1 function is executed to calculate Mconfirm & Sconfirm.
3. Initiator sends Mconfirm, Sconfirm and Mrand.
4. Responder verifies Mconfirm by repeating calculations executed by initiator using the obtained Mrand value:
1. If the Mconfirm value calculated by the responder does not match the value calculated by the initiator, the pairing process is interrupted and the responder sends Pairing Failed command with the reason code Confirm Value Failed.
2. If the Mconfirm values match, the responder transfers Srand to the initiator.
5. Initiator verifies the received Sconfirm value by repeating responder calculation using Srand value:
1. If the Sconfirm value calculated by the initiator does not match Sconfirm calculated by the responder, devices stop pairing and the initiator sends Pairing Failed command with the reason code Confirm Value Failed
2. If the Scomfirm values match, the initiator calculates Shot Term Key (STK) using the S1 function and instructs the controller to enable encryption.

A detailed description of the s1 and c1 functions is provided in Bluetooth protocol specification, however knowing the input data is enough for understanding the concept.

C1 function requires the following input parameters:

• TK
• Mrand for Mconfirm or Srand for Sconfirm calculations
• Pairing request command
• Pairing response command
• Initiator address type
• Initiator address
• Responder address type
• Responder address.

S1 function requires the following input parameters:

Note that in Legacy Pairing process the third phase includes LTK key generation, which is further used for subsequent channel encryption between the devices. In the Secure Connection process, the LTK key is generated on the second step.

You may notice now that knowing TK, Srand and Mrand values allows us to recover the STK, and then a successful attack on the protocol takes a simple enumeration of the values between 000000 and 999999.

So why is this attack rare? First, this vulnerability has been detected in BLE 4.0-4.1 versions, however it was fixed in BLE 4.2 and later by adding Secure connection pairing mode where asymmetric cryptography based on Diffie-Hellman elliptic curves is used for LTK approval.

Second, intercepting all pairing packets is a challenge. Bluetooth operates in the 2.4 GHz frequency range (2.402 - 2.480 GHz, to be precise). This comprises 79 channels with 1MHz bandwidth and allows quick channel changes in addition to encryption. The interception requires special equipment, i.e. Ubertooth – a device that can intercept all channels at once.

Attack implementation example

Attack implementation requires:

• Ubertooth or any other device capable of simultaneous packet capture from all channels
• A Linux-operated device
• A vulnerable device, in my case it is a Bluetooth Mouse 3600
• Any device that supports BLE, in our case it is a notebook with Windows 10.

Note: Although I have been using this mouse for several years, this model is still available for purchase.

Step 1. Configure Ubertooth, install the necessary libraries for traffic sniffer, e.g. Wireshark. Refer to Ubertooth GitHub for details. Do a trial run to verify proper operation. When everything is working, let’s proceed to the main part.

Start the Bluetooth adapter:

sudo hciconfig hci0 up

Create a file for pipes:

mkfifo /tmp/pipe

Start Ubertooth:

ubertooth-btle -f -c <FilePipe>

Open Wireshark and configure pipes file:

Capture-Options...>Manage interfaces...>Pipes

Step 2. Start packets interception

Step 3. Start devices pairing

Step 4. When the pairing is complete, verify that all required packets have been captured by applying the filter:

btle.advertising_header.pdu_type==0x05

To verify that proper devices’ pairing has been recorded, it is enough to know the MAC address of at least one device. Out of the many ways to find out Bluetooth device MAC address, the most efficient are:

1. Bluetooth device search: hcitool scan
2. BLE device search: hcitool lescan
3. Bettercap utility
4. BlueHydra utility
5. Bluescan utility.

For the sake of simplicity let's just use the hcitool lescan command

Step 5. As soon as the device MAC address is detected, it becomes clear that we have successfully intercepted the connection. To ease the detection of the pin-code and LTK let’s use a ready-made solution known as crackle. This program takes a pcap file, detects all pairing attempts and then attempts an attack.

Out of two pairing attempts captured, we failed to intercept several necessary packets during the first pairing. However, we had all necessary packets for the second set of devices and have been able to perform the attack. Results show that Bluetooth Mouse 3600 uses the standard pin code of 000000. After detecting the pin code, we managed to obtain the LTK.

Here's a Secure Connection example, taken from the Crackle project GitHub.

Finally, a brute force attack example aimed at obtaining the pin code, taken from the same GitHub project.

So what's the danger here?

First, if the target device is not a Bluetooth mouse, but something different such as a fitness tracker, the attack would allow adversaries to try and access confidential information. Second, verified Bluetooth connections are susceptible to different types of attacks. The threat is that a potential adversary can pass a device such as earphones, for a Bluetooth keyboard or other device. Experience shows that most current operating systems are incapable to detect significant device mutations, i.e. earphones becoming a keyboard. Our own example studies a vulnerable Bluetooth mouse that uses the same Bluetooth profile as would a keyboard – Human Interface Device.

There are multiple options to obtain LTK and the demonstrated attack is just one of them. As you’re reading this article, there are hundreds of BLE 4.0-4.1 devices sold on various market places, although sometimes the BLE version is not specified.

Staying safe

A great thing to remember is that BLE is a range-limited technology. Namely, performing the attack described in this article would require the adversary to operate within a 20 meter range from the target. Therefore, be careful in choosing places where you pair the devices.

Second, whenever your BLE device suddenly loses the connection, do not rush to reconnect it. It is better to stay alert.

Third, if you are not using any Bluetooth device at the moment, turn the host adapter off.

And finally, check the BLE version on your device: all 4.2 and newer devices are secured against these attacks, however even if you run a 4.0 or 4.1 version, it’s not a reason to feel insecure as the device may use a third-party technology such as NFC or may require additional action for pairing, i.e. scanning moving dots on smart watch display as Apple devices request. And of course, it never hurts to find out device Bluetooth version before purchase. Most vendors currently implement Bluetooth 5.0, although often enough vulnerable legacy devices can be found on sales.

Note: if a phone or a computer supports the latest Bluetooth version and the legacy earphones or a fitness tracker have 4.0-4.1 version, the devices will pair over the legacy protocol version (Legacy pairing). The fastest way to find out device BLE version is to refer to the user guide or the vendor web site, as describing technical methods for BLE version detection may constitute another research.

© 2024 UDV MENA INFORMATION TECHNOLOGY SERVICES CO. L.L.C. All rights reserved.