A KNOB (key negotiation of Bluetooth) attack against the basic rate/enhanced data rate (BR/EDR, or Bluetooth Classic) configuration can result in information disclosure and/or escalation of privileges.
The vulnerability was discovered by researchers at the Center for IT-Security, Privacy and Accountability (CISPA), and reported to Bluetooth. Bluetooth published an advisory and Microsoft patched its own Bluetooth in the August 2019 updates. But patching Windows does not mean the Bluetooth issue is solved.
In its own Vulnerability Note VU#918987, CERT/CC has explained the vulnerability and designated it as CVE-2019-9506 with a CVSS score of 9.3. The vulnerability is based on the process by which communicating Bluetooth devices decide on and establish an encryption key length. This can be anything between one and 16 bytes of entropy. One byte provides an encryption key so small that it can be brute forced by an attacker.
Microsoft patched Windows Bluetooth with “a software update that enforces a default 7-octet minimum key length to ensure that the key negotiation does not trivialize the encryption.” However, this is not set by default and must be enabled by the user setting a flag in the registry. Unless this flag is set, Windows Bluetooth will remain susceptible to the vulnerability.
The main problem is that an attacker can force a minimal key length. It is not a simple attack and it is thought that it has never been maliciously exploited. BR/EDR Bluetooth is the standard configuration for short range communication. This means that the attacker must be adjacent to the communicating devices with kit adequate to intercept the wireless communications.
In such circumstances, the attacker could intercept a proposal request and change the requested key length to 1. Under normal circumstances (but not by patched Windows if the registry flag is set) this would be accepted as a valid proposal since it is within the Bluetooth parameters. The second device may respond by requesting a larger entropy — but again the attacker could intercept and change it to 1.
“Thus,” explains CERT/CC, “both Alice and Bob would accept N [ie, 1] and inform the Bluetooth hosts that encryption is active, without acknowledging or realizing that N is lower than either of them initially intended it to be.”
It is still not a simple attack. As Bluetooth explains, “If the attacking device was successful in shortening the encryption key length used, it would then need to execute a brute force attack to crack the encryption key. In addition, the attacking device would need to repeat the attack each time encryption gets enabled since the encryption key size negotiation takes place each time.”
Bluetooth has responded by updating the Bluetooth Core Specification to recommend a minimum encryption key length of seven octets; that is the length set in the Windows update. For Windows Bluetooth communication to continue (assuming the user actually does set the registry flag), it will require that other Bluetooth device manufacturers update their products to the new specification, and that users update their devices to include the latest software version.
Without this, as Microsoft comments, “If your particular Bluetooth device or the Bluetooth radio in your Windows device, or the driver for that Bluetooth radio does not support the longer key length, this update could block connections with that device when the registry key EnableMinimumEncryptionKeySize is set.”
Related: Bluetooth Vulnerability Allows Traffic Monitoring, Manipulation
Related: New Vehicle Hack Exposes Users’ Private Data Via Bluetooth
Related: Bluetooth Chip Flaws Expose Enterprises to Remote Attacks
Related: Billions of Devices Potentially Exposed to New Bluetooth Attack