Cybersecurity risk in Bluetooth Low Energy (BLE) Device

Authors: Ramakrishnan Lakshminaryanan and Jasper Nota

Devices with a Bluetooth Low Energy (BLE) connection are common nowadays. However, they might be unsafe to use. This is the case when BLE is implemented in an insecure way. To demonstrate the cybersecurity risk of such devices, we chose a medical device that can be ordered by consumers at several well-known web shops.

Note: Prior to publishing this article, multiple attempts were made to inform the Original Equipment Manufacturer (OEM) about the discovered vulnerabilities and the consequences that come with it. Unfortunately, no response was received from the OEM. Secura has chosen to publish this article to enhance security awareness among manufacturers and users.

Multiple Security Concerns

Multiple security concerns were observed throughout the brief investigation conducted. For the purpose of this article, only the risks related to the BLE functionality will be disclosed.

The Medical Device

The Device Under Test (DUT) is a medically certified device that allows users to relieve pain, relax or strengthen muscles through electrodes. This device can be controlled by using the associated Android application (v4.3.15 at the time of testing this device).

The entire functionality depends on the intensity set by the central or peripheral device. Based on the intensity value [min = 0; max = 60], the vibration could be felt on the body via the electrode patches. Depending on which part of our body the electrode patches are stuck, there are a set of workout, relax, recovery programs respectively.

Testing began with sticking the patches to the arms or legs. The observation (while testing on the arm) was that after the intensity value exceeded 25, the arm experienced violent shaking. The intensity controlled the arm movement, which made it difficult to resist that motion. These vibrations can become serious shocks at higher intensities or during sudden changes in intensity.

Services and Characteristics

A BLE discovery was initiated to identify the Media Access Control (MAC) address associated with the DUT. Once identified, the services and characteristics, which are nested objects responsible for handling transmitted data, could be enumerated:

Notice how multiple handles have the WRITE property stated for the DUT. This means that those handles accept incoming data from the central device, which is the mobile phone in this case.

Out of the handles listed with write access, there were several interesting ones, which are listed below:

(1) Handle 0007 - Peripheral Privacy Flag

This flag is explicitly related to the privacy feature of the peripheral device. In other words, it is the flag that determines whether the peripheral device supports privacy - enabled or disabled. Testing if this handle can be overwritten/toggled would be one of the interesting things for an attacker.

(2) Handle 000b - Reconnection Address

This handle contains address related information to be used when reconnecting to a private device. Since this handle is also a point of interest from an attacker perspective, we wanted to verify whether this can be overwritten.

(3) Handles 0010, 0011, 0012, 0013 - Related to vibration intensities

These handles contain vibration intensity values and would again be interesting handles for an attacker to overwrite.

As can be seen in the above stated figure, the Peripheral Privacy Flag [Handle 0007] was overwritten. Thus, concluding that it can be disabled and enabled. Similarly, the field ‘Reconnection Address [Handle 000b]’ could also be overwritten, as shown in the below stated figure. Figures related to overwriting the vibration intensity values are shown in the next section of this article.

There are multiple methods to analyze the BLE traffic between devices, using various hardware and software tools.

One of the first ones we considered was passively capturing BLE traffic by using the Ubertooth One and thereafter analyzing the packets with Wireshark. Below is the screenshot that shows a packet capture using Wireshark. Information related to the vibration intensity value, type of protocol being used, and information of the handles could be examined:

In the above screenshot, it can be seen that the packets captured use the ATT protocol. ATT, also known as Attribute protocol, is part of the BLE stack, which strictly defines how data should be represented in a BLE server database, and also defines the way in which the data can be read or written.

Another approach to analyzing BLE communications is to use the HCI snooping technique on a rooted Android mobile phone. Basically, a rooted Android device is a modified device that allows the user superuser access. The process of rooting a device is where a user breaks a set of limitations preset by the manufacturer of the device, to obtain complete control over the Operating System. Thus, elevating oneself to admin privileges. Once the BLE pairing/communication is established, the snoop logs can be extracted from the rooted device to analyze the captured packets.

The above mentioned methods were mostly passively sniffing the BLE communication to gather information about the pairing process, type of protocols in place, MAC address of the DUT, different handles, etc.

To actively engage with the different handles, the Bettercap tool, in combination with a Bluetooth dongle, was used. Results of this approach are presented earlier within this article.

Hijacking The Communication

Now that the communication between the central and peripheral device was analyzed, an attempt was made to establish a Man-in-the-Middle (MiTM) position.

The screenshot below shows how a legitimate BLE connection between the mobile device and the DUT was successfully hijacked. This means the central device is now the attacker machine instead of the mobile phone:

When the BLE hijacking is in progress, there are indications on the mobile screen and front panel of the DUT that unregulated behavior is going on.

Indication 1: DUT is turned on; no workout program is active on the Android application. Normally, if a user quits the workout, the DUT should shut down after a few seconds (Regular Behaviour). Therefore, it is impossible that the device is in ON state when the application does not run any program, unless it is kept ON by an active BLE connection from another Central device. This demonstrates that the Android application no longer controls the device, but that the attacker is now in control of the device.

Indication 2: DUT is turned on; the Android application is trying to reconnect to the DUT, but it fails with a message saying the user needs to turn on the DUT. However, the DUT is already switched on, and the attacker is running an active workout program.

Thus, the above indications convey that the attacker establishes a MiTM position.

Once a MiTM position was established, the communication between the mobile phone and the DUT could be observed in HEX format.

It was observed that, for the same vibration intensity value, there were two data formats of HEX data in the captured BLE packets:

1. Data from the peripheral device to central device -> Data Format 1 or DF1.
2. Data from the central device to the peripheral device -> Data Format 2 or DF2.

For instance, let's consider vibration intensity value 31.
For the same value, there were two different data formats which were observed throughout testing.

DF1 for value 31 was captured as shown below:
LL Data: 06 1b 17 00 04 00 1b 12 00 4e 4f 54 49 46 59 20 73 74 72 65 6e 67 74 68 20 33 31 0d 0a

DF2 for value 31 was captured as shown below:
LL Data: 02 10 0c 00 04 00 52 55 00 3e 73 74 72 20 33 31 0d 0a
LL Data: 0a 0f 0b 00 04 00 1b 55 00 73 74 72 3d 33 31 0d 0a

Both formats indicate that the strength or intensity of vibration on electrode patches should be 31.

The success rate was higher with DF2, while trying to overwrite the handle that contains the vibration intensity value. This would make sense, as the attacker device is the new central device after hijacking the BLE connection, and hence DF2 would work in that case. However, there were some interesting scenarios based on the above approach -

1. While being at a higher intensity or strength value, and overwriting the handle 0x12 with a lower value worked, as there was a noticeable change in the vibration intensity, which could be felt on the body part wherever the electrode patches are stuck [hand/leg]. However, it returned to the original value after a period of time.
   
2. While being at a lower intensity or strength value and overwriting the handle 0x12 with a higher value also worked, it lasted only for a very small amount of time before it returned to the original value. Also, this was the case when the delta/difference between the original value and overwritten value was small.
3. While being at lower intensity or strength value, and overwriting the handle 0x12 with a higher value with a large delta/difference from the original intensity, did not cause any visible difference in vibration on the body. As a loud thought, this could be due to some threshold delta value set in the DUT. We did not go into that part of experimentation, as hijacking BLE communication was our focus and scope.

The follow HEX data was sent to the device:

After the handle 0x12 was overwritten, the vibration intensity change could be felt on the body part to which the electrodes were attached. This demonstrates that an attacker has full control over the intensity set for the electrodes.

Conclusion

We have demonstrated how an attacker could abuse BLE communications when vendors implement BLE in an insecure manner, which could cause serious harm to end-users.

Many other smart devices in the market still have an insecure implementation of Bluetooth Low Energy (BLE). Are you in the industry of smart devices based on BLE? We strongly advise you to evaluate your products from both functional and security perspectives.