BIAS: a Bluetooth attack that allows spoofing a paired device

A few days ago, researchers from the Swiss Federal Institute of Technology Lausanne announced that they have identified vulnerabilities in the pairing methods of devices that comply with the Bluetooth Classic standard (Bluetooth BR/EDR).

The vulnerability is codenamed BIAS and the problem allows the attacker to arrange the connection of their fake device instead of a previously connected user's device and successfully pass the authentication procedure without knowing the channel key (link key) generated during the initial device pairing and allowing without repeating the manual confirmation procedure on each connection.

The essence of the method is that when connecting to devices that support Secure Connections mode, the attacker advertises the absence of this mode and reverts to an outdated authentication method ("legacy" mode). In "legacy" mode, the attacker initiates the master-slave role change, presenting their device as the "master" and taking over the authentication process. The attacker then sends a notification of successful authentication completion, without even possessing a channel key, and the device authenticates itself on the other end.

The Bluetooth Spoofing Attack (BIAS) can be performed in two different ways, depending on which Secure Simple Pairing method (either Legacy Secure Connections or Secure Connections) was previously used to establish a connection between two devices. If the pairing procedure was completed using the Secure Connections method, the attacker could claim that it is the previously paired remote device that no longer supports secure connections, reducing authentication security. 

After that, the attacker can manage to use an encryption key that is too short, containing only 1 byte of entropy , and apply the KNOB attack previously developed by the same researchers to establish an encrypted Bluetooth connection under the guise of a legitimate device (if the device has protection against KNOB attacks and the key size could not be reduced, the attacker will not be able to establish an encrypted communication channel, but will continue to be authenticated to the host).

For successful exploitation of the vulnerability , the attacker's device must be within range of the vulnerable Bluetooth device, and the attacker must determine the address of the remote device to which the connection was previously made.

The researchers published a prototype toolkit implementing the proposed attack method and demonstrated how to spoof the connection of a previously paired Pixel 2 smartphone using a Linux laptop and a CYW920819 Bluetooth card.

The BIAS method can be performed for the following reasons: establishing a secure connection Bluetooth is not encrypted and the selection of the secure connection pairing method does not apply for an already established pairing, establishing a secure connection for Legacy Secure Connections does requires mutual authentication, a Bluetooth device can perform a role change at any time after baseband search, and devices that have been paired with Secure Connections can use Legacy Secure Connections while establishing a secure connection.

The problem is caused by a memory defect and manifests in several Bluetooth stacks and Bluetooth chip firmware, including Intel, Broadcom, Cypress Semiconductor, Qualcomm, Apple, and Samsung chips used in smartphones, laptops, single-board computers, and peripherals from various manufacturers.

The researchers tested 30 devices (Apple iPhone/iPad/MacBook, Samsung Galaxy, LG, Motorola, Philips, Google Pixel/Nexus, Nokia, Lenovo ThinkPad, HP ProBook, Raspberry Pi 3B+, etc.), which use 28 different chips, and notified the manufacturers of the vulnerability last December. It is not yet known which manufacturers have released firmware updates with the fix.

In response, the Bluetooth SIG, the organization responsible for developing Bluetooth standards, has announced an update to the Bluetooth Core specification . The new edition clearly defines the cases in which a master-slave role change is permitted, mandates mutual authentication when reverting to "legacy" mode, and recommends verifying the encryption type to prevent a decrease in connection security.

Source: https://www.kb.cert.org


Add as preferred source in Google