[VU:799380] Devices supporting Bluetooth Core and Mesh Specifications are vulnerable to impersonation attacks and AuthValue disclosure

Overview

Devices supporting the Bluetooth Core and Mesh Specifications are vulnerable to impersonation attacks and AuthValue disclosure that could allow an attacker to impersonate a legitimate device during pairing.

Description

The Bluetooth Core Specification and Mesh Profile Specification are two specifications used to define the technical and policy requirements for devices that want to operate over Bluetooth connections. Researchers at the Agence nationale de la sécurité des systèmes d'information (ANSSI) have identified a number of vulnerabilities in each specification that allow impersonation attacks and AuthValue disclosures.

Devices supporting the Bluetooth Core Specification are affected by the following vulnerabilities:

Impersonation in the Passkey Entry Protocol

The Passkey Entry protocol used in Secure Simple Pairing (SSP), Secure Connections (SC), and LE Secure Connections (LESC) of the Bluetooth Core Specification is vulnerable to an impersonation attack that enables an active attacker to impersonate the initiating device without any previous knowledge (CVE-2020-26558). An attacker acting as a man-in-the-middle (MITM) in the Passkey authentication procedure could use a crafted series of responses to determine each bit of the randomly generated Passkey selected by the pairing initiator in each round of the pairing procedure, and once identified, the attacker can use these Passkey bits during the same pairing session to successfully complete the authenticated pairing procedure with the responder. Devices supporting BR/EDR Secure Simple Pairing in Bluetooth Core Specifications 2.1 through 5.2, BR/EDR Secure Connections Pairing in Bluetooth Core Specifications 4.1 through 5.2 and LE Secure Connections Pairing in Bluetooth Core Specifications 4.2 through 5.2 are affected by this vulnerability.

Impersonation in the Pin Pairing Protocol

The Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack (CVE-2020-26555). An attacker could connect to a victim device by spoofing the Bluetooth Device Address (BD_ADDR) of the device, reflect the the encrypted nonce, and complete BR/EDR pin-code pairing with them without knowledge of the pin code. A successful attack requires the attacking device to be within wireless range of a vulnerable device supporting BR/EDR Legacy Pairing that is Connectable and Bondable. Devices supporting the Bluetooth Core Specification versions 1.0B through 5.2 are affected by this vulnerability.

Devices supporting Bluetooth Mesh Profile Specification, versions 1.0 and 1.0.1, are affected by the following vulnerabilities:

Impersonation in Bluetooth Mesh Provisioning

The Mesh Provisioning procedure could allow an attacker without knowledge of the AuthValue, spoofing a device being provisioned, to use crafted responses to appear to possess the AuthValue and to be issued a valid NetKey and potentially an AppKey (CVE-2020-26560). For this attack to be successful, an attacking device needs to be within wireless range of a Mesh Provisioner and either spoof the identity of a device being provisioned over the air or be directly provisioned onto a subnet controlled by the provisioner.

Predictable AuthValue in Bluetooth Mesh Provisioning Leads to MITM

The Mesh Provisioning procedure could allow an attacker observing or taking part in the provisioning to brute force the AuthValue if it has a fixed value, or is selected predictably or with low entropy (CVE-2020-26557). Identifying the AuthValue generally requires a brute-force search against the provisioning random and provisioning confirmation produced by the Provisioner. This brute-force search, for a randomly selected AuthValue, must complete before the provisioning procedure times out, which can require significant resources. If the AuthValue is not selected randomly with each new provisioning attempt, then the brute-force search can occur offline and if successful, would permit an attacker to identify the AuthValue and authenticate to both the Provisioner and provisioned devices, permitting a MITM attack on a future provisioning attempts with the same AuthValue.

Malleable Commitment

The authentication protocol is vulnerable if the AuthValue can be identified during the provisioning procedure, even if the AuthValue is selected randomly (CVE-2020-26556). If an attacker can identify the AuthValue used before the provisioning procedure times out, it is possible to complete the provisioning operation and obtain a NetKey. Similar to CVE-2020-26557, identifying the AuthValue generally requires a brute-force search against the provisioning random and provisioning confirmation produced by the Provisioner. This brute-force search for a randomly selected AuthValue, which can require significant resources, must complete before the provisioning procedure times out.

AuthValue Leak

The Mesh Provisioning procedure could allow an attacker that was provisioned without access to the AuthValue to identify the AuthValue directly without brute-forcing its value (CVE-2020-26559). Even when a randomly generated AuthValue with a full 128-bits of entropy is used, an attacker acquiring the Provisioner’s public key, provisioning confirmation value, and provisioning random value, and providing its public key for use in the provisioning procedure, will be able to compute the AuthValue directly.

Impact

Impersonation in the Passkey Entry Protocol

This vulnerability could allow an attacker to authenticate to the response victim device and act as a legitimate encrypted device. The attacker cannot pair with the initiating device using this method of attack, which prevents a fully transparent man-in-the-middle attack between the initiator and responder. For this attack to be successful, an attacking device needs to be within wireless range of two vulnerable Bluetooth devices that are initiating pairing or bonding for which a BR/EDR IO Capabilities exchange or LE IO Capability in the pairing request and response results in the selection of the Passkey pairing procedure.

Impersonation in the Pin Pairing Protocol

This vulnerability could allow an attacker to complete pairing with a known link key, encrypt communications with the vulnerable device, and access any profiles permitted by a paired or bonded remote device supporting Legacy Pairing.

Impersonation in Bluetooth Mesh Provisioning

This vulnerability could allow an attacker to successfully authenticate without the AuthValue. Once authenticated, the attacker could perform any operation permitted to a node provisioned on the subnet until it is either denied access or a new subnet is formed without the attacking node present.

Predictable AuthValue in Bluetooth Mesh Provisioning Leads to MITM

This vulnerability could allow an attacker to successfully brute force the AuthValue and authenticate to both the Provisioner and provisioned devices, permitting a MITM attack on a future provisioning attempt with the same AuthValue.

Malleable Commitment

This vulnerability could allow an attacker to obtain a NetKey, which could be used to decrypt and authenticate up to the network layer, allowing the relay of messages, but no application data decryption.

AuthValue Leak

This vulnerability could allow an attacker to compute the AuthValue and authenticate to the Provisioner and provisioned devices.

Solution

Bluetooth users should ensure that they have installed the latest recommended updates from device and operating system manufacturers.

In addition to the two vulnerabilities affecting the Bluetooth Core Specification, the researchers also identified a potential security vulnerability related to LE Legacy Pairing authentication in Bluetooth Core Specification versions 4.0 through 5.2. The researchers claim that an attacker can reflect the confirmation and random numbers of a peer device in LE legacy pairing to successfully complete legacy authentication phase 2 without knowledge of the temporary key (TK). Because the attacker does not acquire a TK, or valid short-term key (STK) during this attack, completing authentication phase 2 is not sufficient for an encrypted link to be established. While the Bluetooth SIG does not consider this to be a method which can provide unauthorized access to a device, they still recommend that LE implementations requiring pairing and encryption use LE Secure Connections. The Bluetooth SIG also recommends that, where possible, implementations enable and enforce Secure Connections Only Mode, ensuring that LE legacy pairing cannot be used.

The Bluetooth SIG additionally makes the following recommendations for each vulnerability:

Impersonation in the Passkey Entry Protocol

For the attack to succeed the pairing device needs to accept the same public key that it provided to the remote peer as the remote peer’s public key. The Bluetooth SIG recommends that potentially vulnerable implementations restrict the public keys accepted from a remote peer device to disallow a remote peer to present the same public key chosen by the local device, and the pairing procedure should be terminated with a failure status if this occurs.

Impersonation in the Pin Pairing Protocol

The Bluetooth SIG recommends that potentially vulnerable devices not initiate or accept connections from remote devices claiming the same BD_ADDR as the local device. They also continue to recommend that devices use Secure Simple Pairing or BR/EDR Secure Connections to avoid known vulnerabilities with legacy BR/EDR pairing.

Impersonation in Bluetooth Mesh Provisioning

The Bluetooth SIG recommends that potentially vulnerable mesh provisioners restrict the authentication procedure and not accept provisioning both random and confirmation numbers from a remote peer that are the same as those selected by the local device.

Predictable AuthValue in Bluetooth Mesh Provisioning Leads to MITM

The Bluetooth SIG recommends that mesh implementations enforce a randomly selected AuthValue using all of the available bits, where permitted by the implementation. A large entropy helps ensure that a brute-force of the AuthValue, even a static AuthValue, cannot normally be completed in a reasonable time.

Malleable Commitment

The statement from the Bluetooth SIG notes: "AuthValues selected using a cryptographically secure random or pseudorandom number generator and having the maximum permitted entropy (128-bits) will be most difficult to brute-force. AuthValues with reduced entropy or generated in a predictable manner will not grant the same level of protection against this vulnerability. Selecting a new AuthValue with each provisioning attempt can also make it more difficult to launch a brute-force attack by requiring the attacker to restart the search with each provisioning attempt."

AuthValue Leak

The Bluetooth SIG recommends that potentially vulnerable mesh provisioners use an out-of-band mechanism to exchange the public keys.

Acknowledgements

Thanks to researchers at the Agence nationale de la sécurité des systèmes d'information (ANSSI) for reporting these vulnerabilities.

This document was written by Madison Oliver.