Bluetooth Vulnerability Allows an attacker to impersonate previously paired devices.
The researchers found that the pairing vulnerability in Bluetooth Basic/Data Rate Enhanced (BR/EDR) connections can be used to simulate an already paired device.
Due to the lack of security, an attacker in the Bluetooth area of an infected device can remotely forge the Bluetooth address of a previously connected device and thus authenticate himself successfully without knowing the connection key normally used to establish an encrypted connection.
An unauthenticated remote attacker may impersonate a previously paired/connected device and successfully authenticate without knowing the connection key. This allows the attacker full access to the paired device by performing a Bluetooth identity theft attack (BIAS) – the CERT/CC warning of the focal point is read.
In a statement on this vulnerability, the Bluetooth Special Interest Group (SIG) states that attacks allow hackers to negotiate a reduction in encryption key strength if the device is still vulnerable to a KNOB (Key Negotiation of Bluetooth) attack reported last year.
An attacker could try to crack the encryption key and tamper with a remote paired device. If an attack fails, no encrypted connection is installed, but the attacker can still authenticate to the host.
For an attack to be successful, the attacker must know the Bluetooth address of the external device to which the target was previously connected. The vulnerability detected as CVE-2020-10135 has a CVSS score of 4.8.
The vulnerability can be exploited in two ways, depending on the single secure connection method (Legacy Secure Connections or Secure Connections) used to establish the previous connection to the external device.
The first method allows an attacker to reduce authentication security and switch to the BIAS method. If they can lower the authentication level or if the device does not support secure connections, an attacker can switch from master to slave to start authentication.
If successful, perform full authentication with the external device. If the external device cannot authenticate with an attacker in the lead role, this results in a full authentication notification on both devices, even if the attacker does not have a login key – a CERT/CC warning is read.
To resolve this issue, it is recommended that providers ensure that the length of the encryption key cannot be reduced below 7 bytes and that hosts only initiate mutual authentication or support secure connections when possible. In addition, they must ensure that an encrypted connection is required to use Bluetooth authentication for an independent signal to change the confidence in the device.
To address this vulnerability, the Bluetooth SIG updates the Bluetooth kernel specification to specify when role changes are allowed, to require mutual authentication for legacy authentication, and to recommend the type of encryption checks to prevent connections from being downgraded to the old encryption, according to the Bluetooth SIG.
That’s what it looks like: New Bluetooth vulnerability allows attackers to intercept traffic
That’s what it looks like: Critical Bluetooth vulnerability exposes Android devices to attack
That’s what it looks like: Google Titanium security keys are vulnerable to Bluetooth attacks.
Ionat Argir is the international correspondent for Security Week.