Daniele Antonioli, a Bluetooth security researcher who previously developed BIAS, BLUR, and KNOB attack techniques, has identified two new vulnerabilities (CVE-2023-24023) in the Bluetooth session negotiation mechanism. These vulnerabilities affect all Bluetooth implementations that support the 'Secure Connections' and 'Secure Simple Pairing' secure pairing modes, corresponding to Bluetooth Core specifications 4.2-5.4. To demonstrate the practical application of the identified vulnerabilities, six attack variants have been developed, allowing an attacker to intercept connections between previously paired Bluetooth devices. The code for implementing the attack methods and tools for checking the presence of vulnerabilities has been published on GitHub.
The vulnerabilities were discovered during an analysis of the mechanisms outlined in the standard for achieving forward and future secrecy, which counteract the compromise of session keys if a persistent key is compromised (the compromise of one of the persistent keys should not lead to the decryption of previously intercepted or future sessions) and the reuse of session keys (the key from one session should not be applicable to another session). The identified vulnerabilities allow bypassing the stated protections and reusing an insecure session key across different sessions. These vulnerabilities are due to shortcomings in the base standard, are not specific to individual Bluetooth stacks, and manifest in chips from various manufacturers.
The proposed attack methods implement different variants for spoofing classical (LSC, Legacy Secure Connections based on outdated cryptographic primitives) and secure (SC, Secure Connections based on ECDH and AES-CCM) Bluetooth connections between the system and peripheral devices, as well as organizing MITM attacks for connections in LSC and SC modes. It is assumed that all Bluetooth implementations compliant with the standard are susceptible to various forms of the BLUFFS attack. The effectiveness of the method has been demonstrated on 18 devices from companies such as Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell, and Xiaomi.
The essence of the vulnerabilities lies in the ability to forcibly revert the connection to an older LSC mode and to an unreliable short session key (SK) without violating the standard, by specifying the minimum possible entropy in the connection negotiation process and ignoring the content of the response with the authentication parameters (CR). This leads to the generation of a session key based on constant input parameters (the session key SK is calculated as KDF from the permanent key (PK) and the parameters agreed upon during the session). For example, during a MITM attack, the attacker can replace the parameters 𝐴𝐶 and 𝑆𝐷 in the session negotiation process with zero values, while setting the entropy 𝑆𝐸 to 1, resulting in the formation of a session key 𝑆𝐾 with an actual entropy of 1 byte (the standard minimum entropy size is 7 bytes (56 bits), which is comparable in reliability to DES key guessing).
If the attacker managed to achieve the use of a shorter key during the connection negotiation, they can subsequently use brute force to determine the permanent key (PK) used for encryption and decrypt the traffic between devices. Since it is possible to initiate the use of the same encryption key during a MITM attack, if this key is guessed, it can be used to decrypt all past and future sessions intercepted by the attacker.
To block the vulnerabilities, researchers have proposed amendments to the standard that expand the LMP protocol and change the logic of using KDF (Key Derivation Function) when generating keys in LSC mode. This change does not disrupt backward compatibility, but it leads to the inclusion of an extended LMP command and the necessity to send an additional 48 bytes. The Bluetooth SIG organization, responsible for the development of Bluetooth standards, has proposed as a protective measure to reject connections over an encrypted communication channel with keys sized up to 7 bytes. Implementations that always apply Security Mode 4 Level 4 are recommended to reject connections with keys sized up to 16 bytes.
Source: opennet.ru
