According to researchers, the attacks carried out by exploiting BLURtooth vulnerability are being referred to as the BLUR attacks.
With rising technological advancements, there has been pressure to reduce the amount of moving parts in any device and to minimize the use of physical components. This is one reason why headphone jacks are also being abandoned bringing the use of Bluetooth to the forefront.
However, just like every protocol, it is important to remember that it can be vulnerable as well. Keeping this in mind, recently researchers have discovered that the Cross-Transport Key Derivation (CTKD) which can be found in both versions 4.2 and 5.0 of Bluetooth’s core specifications is vulnerable to a Man in the Middle Attack (MITM).
Dubbed as BLURtooth and identified as CVE-2020-15802; the vulnerability targets the fact that CTKD is used for the authentication that occurs when multiple devices connect to each other. It does so by allowing the user to choose 1 out of 2 standards, namely Low Energy (BLE) and Basic Rate/Enhanced Data Rate (BR/EDR) for the authentication to occur.
It is worth noting that BLE is mostly used in IoT devices and wearable tech. However, it is natively supported in systems including iOS, Android, BlackBerry, and Windows Phone, as well as macOS, Linux, Windows 8, and Windows 10.
While BR/EDR is a digital mobile phone technology that allows improved data transmission rates. Mostly, the technology is used in apps like wireless headphones and speakers, etc.
The problem though starts here when an attacker tries to overwrite legitimate authentication keys by tampering with CTKD resulting in the bad guys to “gain additional access to profiles or services that are not otherwise restricted.” This naturally equates to a MITM attack.
The pre-requisite for this is outlined by Bluetooth SIG stating:
For this attack to be successful, an attacking device would need to be within wireless range of a vulnerable Bluetooth device supporting both BR/EDR and LE transports that supports CTKD between the transports and permits pairing on either the BR/EDR or LE transport either with no authentication (e.g. JustWorks) or no user-controlled access restrictions on the availability of pairing.
To conclude, for the future, the flaw should be fixed as soon as possible using multiple methods that have been recommended by different stakeholders. One of these is that no overwriting of keys is allowed by default in the vulnerable versions mentioned above and ” restrictions on CTKD” be also placed.
However, even these are pushed out by the developers, all device manufacturers would need to implement them in their devices for users to be safe which isn’t easy with hundreds of different companies operating with such devices.