Known Bluetooth standard version vulnerabilities

BR/EDR

BLE

Identifying whether the device is affected by known vulnerabilities is a fundamental step in a security audit.

Throughout the history of the Bluetooth standard, multiple security issues have been identified and led to vulnerabilities. Maintaining backward compatibility requires devices to support older versions of the standard, which can be unsafe, as some legacy versions contain exploitable security weaknesses. As with driver and stack level issues, it is necessary to verify which standard vulnerabilities affect the analyzed device.

Bluetooth specifications also have a defined lifecycle, so the implemented version must remain supported to ensure that any new vulnerabilities in the standard can be addressed.

Description

First, the version of the Bluetooth standard supported by the device must be identified. The implemented version of the standard can be obtained from different sources:

• Inspection of the packets of a connection at the Link Layer or link layer (LMP or LLL) for LMP_VERSION_REQ, LMP_VERSION_RES and LLL_VERSION_IND packets.
• Requesting version data from the device via the HCI Read remote version command.
• Device information inspection: devices like smartphones usually specify the Bluetooth version among their features.
• Searching to obtain the public information of the device: device models sometimes indicate the Bluetooth version they implement.
• Requesting data from the manufacturer.

It should be borne in mind that information provided on the Internet may be outdated and it’s advisable to contrast it, whenever possible, with the information provided by the device.

Vulnerability enumeration can generally be done by searching in vulnerability databases or general-purpose search engines.

Checking the Status of the specification version can commonly be found in the list of Bluetooth SIG documents.

The most common specifications and their status as of May 2023 are listed below:

Related resources

Listed below are some resources that may be useful for obtaining the Bluetooth version supported by a Bluetooth device:

For vulnerability enumeration the following resources may be of interest:

Example case

A connection that established between our PC and a device is captured using the resource BSAM-RES-05 (Capture of a Bluetooth connection). This capture has been done with the debug modes of a Cypress card enabled following the BSAM-RES-06 (Enabling debug mode on a Bluetooth controller) technique. In this way, packets from the Link Layer are captured, in this case from BR/EDR.

Among the exchanged packets, an LMP_VERSION_RES packet is found.

The dissected packet has a VersNr field with value 0x0b. By consulting the Bluetooth Assigned Numbers Rev. 2022-12-20 document in Section 2.1 (Core specification versions), it is concluded that the device under test supports Bluetooth v5.2.

A search following the resource BSAM-RES-03 (Vulnerability database search) finds three vulnerabilities against this version of the Bluetooth standard:

• BIAS
• KNOB
• BlueTrust

For each of the vulnerabilities found, a proof of concept is executed. It is found that the analyzed device does not accept low entropy keys and is therefore considered not vulnerable to KNOB. However, the device allows authentication of devices with cloned identities and is therefore considered vulnerable to BIAS and BlueTrust. The controller manufacturer is notified of this security issue to obtain a firmware update to address the vulnerabilities found.

External references

• Bluetooth Core V5.3, Vol. 6, Part B, Section 2.4.2.13 - LL_VERSION_IND
• Bluetooth Core V5.3, Vol. 2, Part C, Section 4.3.3 - LMP version
• Bluetooth Core V5.3, Vol. 4, Part E, Section 7.1.23 - Read Remote Version Information command
• Bluetooth Core V5.3, Vol. 4, Part E, Section 7.7.12 - Read Remote Version Information Complete event
• Bluetooth Assigned Numbers Rev. 2022-12-20, Section 2.1 - Core specification versions