A slew of vendors that have built Bluetooth pairing into their devices without requiring public key validation are issuing fixes for their products.
Researchers at the Israel Institute of Technology have identified a cryptography-related security vulnerability (CVE-2018-5383) in the Bluetooth specification for over-the-air short-range connectivity between devices, concerning two related Bluetooth features: Secure Simple Pairing and LE Secure Connections.
Simply put, the Bluetooth spec allowed vendors to opt out of implementing public key authentication when devices use the two features, throwing open the door to a man-in-the-middle attack. Without the authentication in place, the vulnerability comes into play: An attacker with physical proximity (within 30 meters) can gain unauthorized access via an adjacent network, intercept traffic and send forged pairing messages between two vulnerable Bluetooth devices. This could result in attackers intercepting information flowing to the devices (including two-factor authentication messages), elevation of privilege and/or denial of service.
“It is possible that some vendors may have developed Bluetooth products that support those features but do not perform public key validation during the pairing procedure,” said the Bluetooth Special Interest Group (SIG) in a short post on the issue this week, noting that the spec recommends public key validation, but previously did not require it. “To remedy the vulnerability, the Bluetooth SIG has now updated the Bluetooth specification to require products to validate any public key received as part of public key-based security procedures. In addition, the Bluetooth SIG has added testing for this vulnerability within our Bluetooth Qualification Program.”
Diving in a bit deeper into the vulnerability, the problem specifically exists in Bluetooth’s use of a device-pairing mechanism based on elliptic-curve Diffie-Hellman (ECDH) key exchange, to allow encrypted communication between devices.
“The ECDH key pair consists of a private and a public key, and the public keys are exchanged to produce a shared pairing key,” a CERT/CC advisory explained on Monday. “The devices must also agree on the elliptic curve parameters being used. Previous work on the Invalid Curve Attack showed that the ECDH parameters are not always validated before being used in computing the resulted shared key, which reduces attacker effort to obtain the private key of the device under attack, if the implementation does not validate all of the parameters before computing the shared key.”
In vulnerable implementations, CERT explained, those elliptic curve parameters are not all validated by the cryptographic algorithm implementation. Thus, a remote attacker within range can simply inject an invalid public key to determine the session key with high probability, and from there passively intercept and decrypt all device messages, and/or forge and inject malicious messages.
Bluetooth said that there’s no evidence of an exploit in the wild, and noted that a successful attack would be somewhat challenging: