==================================================================== CERT-Renater Note d'Information No. 2019/VULN256 _____________________________________________________________________ DATE : 02/09/2019 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems implementing Bluetooth BR/EDR Core versions 5.1 and earlier. ===================================================================== https://kb.cert.org/vuls/id/918987/ https://www.bluetooth.com/security/statement-key-negotiation-of-bluetooth/ _____________________________________________________________________ Bluetooth BR/EDR supported devices are vulnerable to key negotiation attacks Vulnerability Note VU#918987 Original Release Date: 2019-08-14 | Last Revised: 2019-08-30 Overview The encryption key length negotiation process in Bluetooth BR/EDR Core v5.1 and earlier is vulnerable to packet injection by an unauthenticated, adjacent attacker that could result in information disclosure and/or escalation of privileges. This can be achieved using an attack referred to as the Key Negotiation of Bluetooth (KNOB) attack, which is 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. Description Bluetooth is a short-range wireless technology based off of a core specification that defines six different core configurations, including the Bluetooth Basic Rate / Enhanced Data Rate Core Configurations. Bluetooth BR/EDR is used for low-power short-range communications. To establish an encrypted connection, two Bluetooth devices must pair with each other and establish a link key that is used to generate the encryption key. For example, assume that there are two controllers attempting to establish a connection: Alice and Bob. After authenticating the link key, Alice proposes that she and Bob use 16 bytes of entropy. This number, N, could be between 1 and 16 bytes. Bob can either accept this, reject this and abort the negotiation, or propose a smaller value. Bob may wish to propose a smaller N value because he (the controller) does not support the larger amount of bytes proposed by Alice. After proposing a smaller amount, Alice can accept it and request to activate link-layer encryption with Bob, which Bob can accept. An attacker, Charlie, could force Alice and Bob to use a smaller N by intercepting Alice's proposal request to Bob and changing N. Charlie could lower N to as low as 1 byte, which Bob would subsequently accept since Bob supports 1 byte of entropy and it is within the range of the compliant values. Charlie could then intercept Bob's acceptance message to Alice and change the entropy proposal to 1 byte, which Alice would likely accept, because she may believe that Bob cannot support a larger N. Thus, both Alice and Bob would accept N 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. Impact An unauthenticated, adjacent attacker can force two Bluetooth devices to use as low as 1 byte of entropy. This would make it easier for an attacker to brute force as it reduces the total number of possible keys to try, and would give them the ability to decrypt all of the traffic between the devices during that session. Solution Bluetooth host and controller suppliers should refer to the Bluetooth SIG's "Expedited Errata Correction 11838" for guidance on updating their products. Downstream vendors should refer to their suppliers for updates. Vendor Information These issues exist due to the specification, which has been corrected. BlackBerry Notified: June 10, 2019 Updated: August 19, 2019 Statement Date: August 19, 2019 Status Affected Vendor Statement Please read the full vendor statement in the reference link below Vendor References http://support.blackberry.com/kb/articleDetail?articleNumber=000057251 Bluetooth SIG Notified: May 07, 2019 Updated: August 09, 2019 Status Affected Vendor Statement Please read the full vendor statement here. Vendor Information We are not aware of further vendor information regarding this vulnerability. Vendor References https://www.bluetooth.com/security/statement-key-negotiation-of-bluetooth Afero Updated: August 30, 2019 Status Not Affected Vendor Statement No statement is currently available from the vendor regarding this vulnerability. Vendor Information We are not aware of further vendor information regarding this vulnerability. Vendor References https://www.afero.io/release/secured-by-afero-devices-are-immune-to-bluetooth-knob-vulnerabilities/ A10 Networks Notified: June 10, 2019 Updated: June 10, 2019 Status Unknown Vendor Statement No statement is currently available from the vendor regarding this vulnerability. Vendor Information We are not aware of further vendor information regarding this vulnerability. ACCESS Notified: June 10, 2019 Updated: June 10, 2019 Status Unknown Vendor Statement No statement is currently available from the vendor regarding this vulnerability. Vendor Information We are not aware of further vendor information regarding this vulnerability. Actelis Networks Notified: June 10, 2019 Updated: June 10, 2019 Status Unknown Vendor Statement No statement is currently available from the vendor regarding this vulnerability. Vendor Information We are not aware of further vendor information regarding this vulnerability. Actiontec Notified: June 10, 2019 Updated: June 10, 2019 Status Unknown Vendor Statement No statement is currently available from the vendor regarding this vulnerability. Vendor Information We are not aware of further vendor information regarding this vulnerability. ADTRAN Notified: June 10, 2019 Updated: June 10, 2019 Status Unknown Vendor Statement No statement is currently available from the vendor regarding this vulnerability. Vendor Information We are not aware of further vendor information regarding this vulnerability. Aerohive Notified: June 10, 2019 Updated: June 10, 2019 Status Unknown Vendor Statement No statement is currently available from the vendor regarding this vulnerability. Vendor Information We are not aware of further vendor information regarding this vulnerability. AhnLab Inc Notified: June 10, 2019 Updated: June 10, 2019 Status Unknown Vendor Statement No statement is currently available from the vendor regarding this vulnerability. Vendor Information We are not aware of further vendor information regarding this vulnerability. View all 218 vendors CVSS Metrics Group Score Vector Base 7.8 AV:A/AC:L/Au:N/C:C/I:C/A:N Temporal 7.8 E:ND/RL:ND/RC:ND Environmental 7.8 CDP:ND/TD:ND/CR:ND/IR:ND/AR:ND References https://www.bluetooth.com/specifications/adopted-specifications https://www.bluetooth.com/security/statement-key-negotiation-of-bluetooth https://www.usenix.org/system/files/sec19-antonioli.pdf https://www.icasi.org/br-edr-encryption-key-bluetooth-vulnerability/ Acknowledgements Thanks to Daniele Antonioli for reporting this vulnerability. This document was written by Madison Oliver. Other Information CVE IDs: CVE-2019-9506 Date Public: 2019-08-14 Date First Published: 2019-08-14 Date Last Updated: 2019-08-30 13:06 UTC Document Revision: 75 Learn more about vulnerability note structure Contact us about this vulnerability Provide a vendor statement Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications. ________________________________________________________________ Key Negotiation of Bluetooth Researchers at the Center for IT-Security, Privacy and Accountability (CISPA) have identified a security vulnerability related to encryption on Bluetooth BR/EDR connections. The researchers identified that it is possible for an attacking device to interfere with the procedure used to set up encryption on a BR/EDR connection between two devices in such a way as to reduce the length of the encryption key used. In addition, since not all Bluetooth specifications mandate a minimum encryption key length, it is possible that some vendors may have developed Bluetooth products where the length of the encryption key used on a BR/EDR connection could be set by an attacking device down to a single octet. In addition, the researchers identified that, even in cases where a Bluetooth specification did mandate a minimum key length, Bluetooth products exist in the field that may not currently perform the required step to verify the negotiated encryption key meets the minimum length. In such cases where an attacking device was successful in setting the encryption key to a shorter length, the attacking device could then initiate a brute force attack and have a higher probability of successfully cracking the key and then be able to monitor or manipulate traffic. For an attack to be successful, an attacking device would need to be within wireless range of two vulnerable Bluetooth devices that were establishing a BR/EDR connection. If one of the devices did not have the vulnerability, then the attack would not be successful. The attacking device would need to intercept, manipulate, and retransmit key length negotiation messages between the two devices while also blocking transmissions from both, all within a narrow time window. 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. There is no evidence that the vulnerability has been exploited maliciously and the Bluetooth SIG is not aware of any devices implementing the attack having been developed, including by the researchers who identified the vulnerability. To remedy the vulnerability, the Bluetooth SIG has updated the Bluetooth Core Specification to recommend a minimum encryption key length of 7 octets for BR/EDR connections. The Bluetooth SIG will also include testing for this new recommendation within our Bluetooth Qualification Program. In addition, the Bluetooth SIG strongly recommends that product developers update existing solutions to enforce a minimum encryption key length of 7 octets for BR/EDR connections. The Bluetooth SIG is also broadly communicating details on this vulnerability and its remedy to our member companies, and is encouraging them to rapidly integrate any necessary patches. As always, Bluetooth users should ensure they have installed the latest recommended updates from device and operating system manufacturers. For more information, please refer to the statement from the CERT Coordination Center. ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================