Bluetooth Bugs Allow Impersonation Attacks on Legions of Devices A host of unpatched security bugs that allow BIAS attacks affects Bluetooth chips from Apple, Intel, Qualcomm, Samsung and others. Academic researchers have uncovered security vulnerabilities in Bluetooth Classic that allows attackers to spoof paired devices: They found that the bugs allow an attacker to insert a rogue device into an established Bluetooth pairing, masquerading as a trusted endpoint. This allows attackers to capture sensitive data from the other device. The bugs allow Bluetooth Impersonation Attacks (BIAS) on everything from internet of things (IoT) gadgets to phones to laptops, according to researchers at the École Polytechnique Fédérale de Lausanne (EPFL) in Switzerland. The flaws are not yet patched in the specification, though some affected vendors may have implemented workarounds. “We conducted BIAS attacks on more than 28 unique Bluetooth chips (by attacking 30 different devices),” the researchers said. “At the time of writing, we were able to test chips from Cypress, Qualcomm, Apple, Intel, Samsung and CSR. All devices that we tested were vulnerable to the BIAS attack.” The issue lies in the pairing/bonding protocols used in the specification. When two Bluetooth devices are paired for the first time, they exchange a persistent encryption key (the “long-term key”) that will then be stored, so that the endpoints are thereafter bonded and will connect to each other without having to perform the lengthier pairing process every time. For the attacks to be successful, an attacking device would need to be within wireless range of a vulnerable Bluetooth device that has previously established bonding with a remote device with a Bluetooth address known to the attacker. BIAS Bugs The post-pairing connections are enabled because the devices – let’s call them Alice and Bob – perform a background check to make sure both possess the long-term key. This is done using the Legacy Secure Connections or Secure Connections protocols inside the Bluetooth specification, which verify three things: Alice’s Bluetooth address, Bob’s Bluetooth address and the shared long-term key. As the researchers explained in their paper released on Monday, an attacker (let’s call him Charlie) can change his Bluetooth address to mimic either Alice or Bob’s address (uncovered via simple eavesdropping), but he cannot prove the ownership of [the long-term key].” The researchers explained, “this is the fundamental assumption behind Bluetooth’s authentication guarantees, and this assumption should protect against impersonation attacks.” They added, “Both procedures authenticate [the long-term key] using a challenge-response protocol, and the procedure selection depends on Alice and Bob’ supported features. The standard claims that both procedures protect secure connection establishment against impersonation attacks, as an attacker who does not know [the long-term key] cannot provide a correct response to a challenge.” However, several bugs exist in these processes, they found, opening the door for BIAS gambits while that post-pairing connection is being carried out. The problems include: The Bluetooth secure connection establishment is neither encrypted nor integrity-protected; Legacy Secure Connections secure connection establishment does not require mutual authentication; a Bluetooth device can perform a role switch anytime after baseband paging; and devices who paired using Secure Connections can use Legacy Secure Connections during secure connection establishment. There are several attack scenarios that are possible, according to the paper, especially for device pairs that use the older Legacy Secure Connections to bond. For instance, Charlie can establish a connection with Alice pretending to be Bob. Charlie sends a challenge to Alice, and receives a response that’s calculated based on address and long-term key. “As the Bluetooth standard does not mandate [the use of] the legacy authentication procedure mutually while establishing a secure connection, Alice does not have to authenticate that Charlie knows [long-term key],” according to the paper. Another attack scenario involves switching master and slave roles. The master in a pairing is the one that requests the connection. The above attack works when attackers impersonate the requesting side of the relationship. However, they can also impersonate a slave device by maliciously taking advantage of Bluetooth’s role switch procedure. “Bluetooth uses a master-slave medium access protocol, to keep the master and the slave synchronized. The standard specifies that the master and slave roles can be switched any time after baseband paging is completed,” according to the researchers. “This is problematic because Charlie can use this to impersonate the slave device by initiating a role switch and become the master (verifier) before the unilateral authentication procedure is started, and then complete the secure connection establishment without having to authenticate…This feature of Bluetooth was never investigated in a security context, and is thus an entirely novel attack technique.” The devices using the newer and stronger Secure Connections protocol are also vulnerable, specifically to downgrade attacks. “Charlie can pretend that the impersonated device (either Alice or Bob) does not support Secure Connections to downgrade secure connection establishment with the victim to Legacy Secure Connections,” the paper explained. “As a result of the downgrade, Charlie and the victim use the legacy authentication procedure rather than the secure authentication procedure, and Charlie can bypass secure connection establishment authentication.” KNOB Connection The BIAS attacks can also be combined with the Key Negotiation of Bluetooth (KNOB) attack, according to a CERT advisory, which would give an attacker full access to the paired device. KNOB was discovered last August. It occurs when a third party forces two or more victims to agree on an encryption key with as little as one byte of entropy. Once the entropy is reduced, the attacker can brute-force the encryption key and use it to decrypt communications. This would allow a user to “impersonate a Bluetooth device, complete authentication without possessing the link key, negotiate a session key with low entropy, establish a secure connection and brute-force the session key,” according to CERT. An attacker could initiate a KNOB attack on encryption key strength without intervening in an ongoing pairing procedure through an injection attack. If the accompanying KNOB attack is successful, an attacker may gain full access as the remote paired device. If the KNOB attack is unsuccessful, the attacker will not be able to establish an encrypted link but may still appear authenticated to the host. Remediation Forthcoming The Bluetooth Special Interest Group (SIG) said in an advisory that it will be eventually updating the Bluetooth Core Specification to clarify when role switches are permitted, to require mutual authentication in legacy authentication and to recommend checks for encryption-type to avoid a downgrade of secure connections to legacy encryption. “Until this occurs, the Bluetooth SIG is strongly recommending that vendors ensure that reduction of the encryption key length below 7 octets is not permitted, that hosts initiate mutual authentication when performing legacy authentication, that hosts support Secure Connections Only mode when this is possible, and that the Bluetooth authentication not be used to independently signal a change in device trust without first requiring the establishment of an encrypted link,” it said. The researchers said that for now, any standard-compliant Bluetooth device can be expected to be vulnerable. “After we disclosed our attack to industry in December 2019, some vendors might have implemented workarounds for the vulnerability on their devices,” according to the BIAS website. “So the short answer is: if your device was not updated after December 2019, it is likely vulnerable. Devices updated afterwards might be fixed.”