Top 6 Bluetooth Vulnerabilities

Over the last few years we’ve seen a slew of vulnerabilities found in Bluetooth and Bluetooth Low Energy (BLE). It’s important to be familiar with them because they still affect products, can apply to your product or be related to other vulnerabilities. So here are the top vulnerabilities you should keep in mind while developing your product.

1. Bluetooth 4.0 to 4.1 Key Exchange

The original Bluetooth Specification for Bluetooth Low Energy (BLE) that was released in Bluetooth v4.0 used a custom designed key exchange protocol designed by the Bluetooth SIG. This protocol is flawed, making all Bluetooth 4.0 and 4.1 devices vulnerable to having their encryption keys brute forced (sometimes in a second).

This vulnerability forced the Bluetooth SIG to turn to a Diffie-Hellman Key Exchange (instead of their own implementation). This is a known industry primitive that was added in the Bluetooth 4.2 specification and called LE Secure Connections (LESC).

It’s no longer possible to use Bluetooth 4.0 or Bluetooth 4.1. The specifications are withdrawn and you cannot certify a product with the Bluetooth SIG using those specifications. Even so, we still see products that don’t use LE Secure connections. These features are not necessarily enabled by default. Oftentimes, SDK examples use Legacy pairing to make things easier, and no one makes sure LESC is actually used or working.

Many of the attacks on Bluetooth Low Energy assume that LESC is being used, because otherwise the security of the device is already compromised.

2. KNOB Attack

The Key Negotiation of Bluetooth (KNOB) attack is a vulnerability in the Bluetooth specification that allows a malicious actor to weaken the encryption used in Bluetooth connections, making it easier to intercept and decipher transmitted data. This issue primarily affects devices using Bluetooth BR/EDR (Bluetooth Classic) rather than Bluetooth Low Energy (BLE). The vulnerability lies in the way Bluetooth devices establish encryption keys during the pairing process.

When two Bluetooth devices pair, they agree on an encryption key, which is used to secure the data exchanged between them. The KNOB Attack exploits the fact that the key length is negotiable by forcing the devices to agree on an encryption key that’s much smaller (and with significantly less entropy) than intended. This is possible because the negotiation itself isn’t encrypted.

A key with low entropy is easier to crack. For example, if the attacker negotiates a one byte key, then it only requires testing 256 possibilities. Reducing the key helps an attacker brute-force the encryption key more quickly and eavesdrop on the data being transmitted.

It’s important to note that for the attack to be successful, the attacker must be within wireless range of the targeted Bluetooth devices during the pairing process.

Because the key negotiation protocol is part of the Bluetooth protocol, all devices are potentially vulnerable. To avoid being impacted by this attack, products can require a minimum key length to be enforced and reject connections where the other party tries to use a small key.

Many products did not initially enforce a minimum key for connections. However, many manufacturers have since released new firmware that enforces the stronger key size requirements and protects against this attack, so it’s important to update the firmware of all the devices you have to make sure this attack is mitigated.

3. BLUFFS Attack

BLUFFs, which stands for Bluetooth Forward and Future Secrecy Attacks and Defenses, is one of the newest attacks on BLuetooth and is assigned CVE-2023-24023. This attack uses a Man in the Middle (MITM) atttack between devices that are already paired.

This attack leverages the KNOB attack – reducing the entropy of the encryption key. But BLUFFS attacks future sessions.

Because it relies on KNOB, the mitigation for this vulnerability is similar – ensuring that keys are at least 7 bytes, ideally more, to make them resistant to being brute forced.

4. SweynTooth 

The SweynTooth vulnerabilities are a collection of security flaws discovered in the Bluetooth Low Energy (BLE). These vulnerabilities affect a wide range of products, including but not limited to fitness trackers, smart home devices, and medical devices, making them a significant concern for both consumers and manufacturers.

Identified and disclosed by security researchers, SweynTooth can potentially allow attackers to cause a range of issues, from crashing devices to bypassing security features, and in some cases, executing arbitrary code.

The SweynTooth vulnerability are not issues with the Bluetooth standard itself but with the implementation in stacks provided by vendors. The attack exploits flaws in how these devices handle BLE connections and data packets in certain cases (specially crafted packets), leading to a variety of potential security breaches depending on the nature of the exploited vulnerability.

The issues disclosed by SwyenTooth have been resolved by many if not all of the stack vendors.

5. Bluetooth HID Vulnerability

We wrote extensively about the Bluetooth HID flaw in Apple’s devices, which vulnerability, and you can read the details here. A significant number of operating systems and products failed to properly protect against Bluetooth HID attacks that allow an attacker to send keystrokes and other HID events.

This attack lets anyone type as if they’re your Bluetooth keyboard, even Apple’s Magic keyboard is vulnerable.

It’s one of the broadest attacks possible and has a huge impact because it let’s anyone issue commands to your PC.

6. BlueBorne

BlueBorne is a collection of eight vulnerabilities impacting a slew of systems uncovered by Armis in 2017.

CVE-2017-14315 – Flaws in the implementation of the Low Energy Audio protocol can cause a heap overflow attack if a specific crafted packet is send. This allows an attacker to get control of the Bluetooth stack and therefore the device

CVE-2017-1000250 – This vulnerability affects BlueZ 5.46 and below, where remote attackers can get information from a device’s bluetoothd memory because of issues in the SDP server implementation and how it processes SDP search attribute requests.

CVE-2017-1000251 – Another BlueZ flaw that impacts the Linux Kernel where a stack overflow can occur when processing L2CAP configuration responses. This attack allows an attacker to execute core remotely

CVE-2017-0781 and CVE-2017-0782 allow for remote code execution because of issues in the SDP server and the Bluetooth Network Encapsulation Protocol (BNEP) service.

CVE-2017-0785 is a information leak vulnerability also related to SDP.

What can we learn from these Vulnerabilities?

The Bluetooth vulnerabilities we presented are some of the top issues Bluetooth product designers have to factor into their products.

Specification flaws, where the Bluetooth specification does something that reduces system security is one core type of issues. This is clear in the KNOB attack, an issue that can’t really be eliminated because it’s an essential part of the protocol. These kind of issues tend to be relatively small in number, but have a huge impact.

The other, more typical vulnerabilities we see are implementation vulnerabilities. Vendors, programmers, and Bluetooth stack providers make mistakes. Insecure code gets exploited in ways the developers never expected and never tested.

Especially for the implementation flaws, most if not all vendors will patch their stacks to address the issues.

Firmware Updates are Critical

The most effective way to keep Bluetooth and other connected products secure is to design for firmware updates. It’s impossible to predict what flaws and vulnerabilities will be disclosed in the future, but enabling firmware updates for products means patching these issues before they become a problem.