Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and might lead to discovery of the encryption key and live injection, aka BLUFFS.

Refer: https://www.bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security/bluffs-vulnerability/

The HID Profile in multiple Bluetooth host stacks may accept connections with the HID control and HID interrupt channels of the HID Host role without MITM protection/mitigation and without user confirmation on the Central role device. This can permit a device like a keyboard (or emulating a keyboard) to successfully connect to a discoverable device without confirmation and permit keystroke injection.

Patch: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=25a471a83e02e1effb15d5a488b3f0085eaeb675

Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and might lead to discovery of the encryption key and live injection, aka BLUFFS.

Bluetooth Classic in Bluetooth Core Specification through 5.3 does not properly conceal device information for Bluetooth transceivers in Non-Discoverable mode. By conducting an efficient over-the-air attack, an attacker can fully extract the permanent, unique Bluetooth MAC identifier, along with device capabilities and identifiers, some of which may contain identifying information about the device owner. This additionally allows the attacker to establish a connection to the target device.

Bluetooth® Low Energy Pairing in Bluetooth Core Specification v4.0 through v5.3 may permit an unauthenticated MITM to acquire credentials with two pairing devices via adjacent access when the MITM negotiates Legacy Passkey Pairing with the pairing Initiator and Secure Connections Passkey Pairing with the pairing Responder and brute forces the Passkey entered by the user into the Initiator. The MITM attacker can use the identified Passkey value to complete authentication with the Responder via Bluetooth pairing method confusion.

Bluetooth® Pairing in Bluetooth Core Specification v1.0B through v5.3 may permit an unauthenticated MITM to acquire credentials with two pairing devices via adjacent access when at least one device supports BR/EDR Secure Connections pairing and the other BR/EDR Legacy PIN code pairing if the MITM negotiates BR/EDR Secure Simple Pairing in Secure Connections mode using the Passkey association model with the pairing Initiator and BR/EDR Legacy PIN code pairing with the pairing Responder and brute forces the Passkey entered by the user into the Responder as a 6-digit PIN code. The MITM attacker can use the identified PIN code value as the Passkey value to complete authentication with the Initiator via Bluetooth pairing method confusion.

An information leakage vulnerability in the Bluetooth Low Energy advertisement scan response in Bluetooth Core Specifications 4.0 through 5.2, and extended scan response in Bluetooth Core Specifications 5.0 through 5.2, may be used to identify devices using Resolvable Private Addressing (RPA) by their response or non-response to specific scan requests from remote addresses. RPAs that have been associated with a specific remote device may also be used to identify a peer in the same manner by using its reaction to an active scan request. This has also been called an allowlist-based side channel.

Unencrypted Bluetooth Low Energy baseband links in Bluetooth Core Specifications 4.0 through 5.2 may permit an adjacent device to inject a crafted packet during the receive window of the listening device before the transmitting device initiates its packet transmission to achieve full MITM status without terminating the link. When applied against devices establishing or using encrypted links, crafted packets may be used to terminate an existing link, but will not compromise the confidentiality or integrity of the link.

Mesh Provisioning in the Bluetooth Mesh profile 1.0 and 1.0.1 may permit a nearby device, able to conduct a successful brute-force attack on an insufficiently random AuthValue before the provisioning procedure times out, to complete authentication by leveraging Malleable Commitment.

Mesh Provisioning in the Bluetooth Mesh profile 1.0 and 1.0.1 may permit a nearby device (without possession of the AuthValue used in the provisioning protocol) to determine the AuthValue via a brute-force attack (unless the AuthValue is sufficiently random and changed each time).

Bluetooth Mesh Provisioning in the Bluetooth Mesh profile 1.0 and 1.0.1 may permit a nearby device (participating in the provisioning protocol) to identify the AuthValue used given the Provisioner’s public key, and the confirmation number and nonce provided by the provisioning device. This could permit a device without the AuthValue to complete provisioning without brute-forcing the AuthValue.

Bluetooth Mesh Provisioning in the Bluetooth Mesh profile 1.0 and 1.0.1 may permit a nearby device, reflecting the authentication evidence from a Provisioner, to complete authentication without possessing the AuthValue, and potentially acquire a NetKey and AppKey.

A vulnerability was found in Linux Kernel, where Passkey Entry protocol used in Secure Simple Pairing (SSP), Secure Connections (SC) and LE Secure Connections (LESC) of the Bluetooth Core Specification is vulnerable to an impersonation attack where an active attacker can impersonate the initiating device without any previous knowledge.

Refer: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6d19628f539fccf899298ff02ee4c73e4bf6df3f

A vulnerability was found in Linux Kernel, where Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack. When an attacker connects to a victim device using the address of the device and the victim initiates a Pairing, the attacker can reflect the encrypted nonce even without knowledge of the key.

Devices supporting Bluetooth before 5.1 may allow man-in-the-middle attacks, aka BLURtooth. Cross Transport Key Derivation in Bluetooth Core Specification v4.2 and v5.0 may permit an unauthenticated user to establish a bonding with one transport, either LE or BR/EDR, and replace a bonding already established on the opposing transport, BR/EDR or LE, potentially overwriting an authenticated key with an unauthenticated key, or a key with greater entropy with one with less.

Pairing in Bluetooth® Core v5.2 and earlier may permit an unauthenticated attacker to acquire credentials with two pairing devices via adjacent access when the unauthenticated user initiates different pairing methods in each peer device and an end-user erroneously completes both pairing procedures with the MITM using the confirmation number of one peer as the passkey of the other. An adjacent, unauthenticated attacker could be able to initiate any Bluetooth operation on either attacked device exposed by the enabled Bluetooth profiles. This exposure may be limited when the user must authorize certain access explicitly, but so long as a user assumes that it is the intended remote device requesting permissions, device-local protections may be weakened.

A vulnerability affecting Bluetooth BR/EDR pairing was found in the Bluetooth Core specification versions 1.0 through 5.2. The flaw could allow an attacking device to spoof the address of a previously paired remote device to successfully complete the authentication procedure with some paired/bonded devices while not possessing the link key. This can permit an attacker to initiate the Bluetooth Key Negotiation attack (KNOB) on encryption key strength without intervening in an ongoing pairing procedure through an injection attack.

The Bluetooth Stack 2.1 in Microsoft Windows Vista SP1 and SP2 and Windows 7 Gold and SP1 does not prevent access to objects in memory that (1) were not properly initialized or (2) have been deleted, which allows remote attackers to execute arbitrary code via crafted Bluetooth packets, aka "Bluetooth Stack Vulnerability."