BLUFFS - Bluetooth vulnerabilities that allow you to conduct a MITM attack

Brother

Professional
Messages
2,590
Reaction score
539
Points
113
Daniele Antonioli, a Bluetooth security researcher who previously developed the BIAS, BLUR, and KNOB attack techniques, identified it two new vulnerabilities (CVE-2023-24023) in the Bluetooth session negotiation mechanism, affecting All Bluetooth implementations that support the "Secure Connections" and "Secure Simple Pairing" modes that meet the Bluetooth Core 4.2-5.4 specifications. As a demonstration of the practical application of the identified vulnerabilities, we developed 6 attack options, allowing you to connect to a previously paired Bluetooth device. Code with the implementation of attack methods and utilities for checking for vulnerabilities published on GitHub.

Vulnerabilities were identified during the analysis of the mechanisms described in the standard for achieving forward and Future Secrecy, which counteract the compromise of session keys in the case of determining a permanent key (compromising one of the permanent keys should not lead to decryption of previously intercepted or future sessions) and reuse of session keys (the key from one session should not be applicable to another session). The vulnerabilities found allow you to bypass the specified protection and reuse the untrusted session key in different sessions. Vulnerabilities are caused by flaws in the basic standard, are not specific to individual Bluetooth stacks, and occur in chips from different manufacturers.

eda2c313af.png


The proposed attack methods implement various options for organizing spoofing of classic (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 the peripheral device, as well as organizing MITM attacks for connections in LSC and SC modes. It is assumed that all Bluetooth implementations that comply with the standard are susceptible to some variant of the BLUFFS attack. The method was demonstrated on 18 devices from companies such as Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell and Xiaomi.

5987e9774a.png


The essence of the vulnerabilities boils down to the ability to force a connection to use the old LSC mode and an unreliable short session key (SK) without violating the standard, by specifying the minimum possible entropy during the connection negotiation process and ignoring the contents of the response with authentication parameters (CR), which leads to the generation of a session key based on constant input parameters (SK session key calculated as the KDF of the persistent key (PK) and session-agreed parameters). For example, during a MITM attack, an attacker can replace the following parameters during session negotiation: AC and SD to zero values, and entropy SE set it to the value 1, which will cause the session key to be generated SK with an actual entropy of 1 byte (the standard minimum entropy size is 56 bytes, which is comparable in terms of reliability to the selection of DES keys).

If the attacker managed to use a shorter key during the connection negotiation process, then he can use brute force to determine the permanent key (PK) used for encryption and decrypt traffic between devices. Since it is possible to initiate the use of the same encryption key during a MITM attack, if this key is selected, it can also be used to decrypt all past and future sessions intercepted by the attacker.

f69d73e782.png


To block vulnerabilities, the researcher suggested making changes to the standard that extend the LMP protocol and change the logic of using KDF (Key Derivation Function) when generating keys in LSC mode. The change does not break backward compatibility, but it does result in the inclusion of an extended LMP command and the need to send an additional 48 bytes. The Bluetooth SIG organization, which is responsible for developing Bluetooth standards, has proposed rejecting connections over an encrypted communication channel with keys up to 7 bytes in size as a security measure. Implementations that always use Security Mode 4 Level 4 are advised to reject connections with keys up to 16 bytes in size.
 
Top