The ins and outs of BlueTrust, a Bluetooth vulnerability

BlueTrust is a Bluetooth vulnerability that allows information about devices and users to be obtained and trust relationships to be traced

BlueTrust is a mechanism for discovering trust relationships between Bluetooth devices discovered by Tarlogic, which allows tracing networks of devices and obtaining information about their usage and users.

In the previous post about BlueTrust, a Bluetooth vulnerability, we presented the research conducted by the Tarlogic Innovation team and the proof of concept that resulted from it. In this article, we continue detailing how the Bluetooth vulnerability works and the steps that have been necessary to implement it.

BlueTrust relies on the findings of research into the BIAS and KNOB vulnerabilities in Bluetooth. As we mentioned in the article BlueTrust, goodbye to privacy in Bluetooth, the exploitation of these vulnerabilities is only viable in certain impractical scenarios, but they reveal deficiencies in the security of the standard and how they can be exploited.

Bluetrust uses the information available from the device impersonation capability provided by the BIAS and KNOB vulnerabilities to find out which devices are linked, and thus map «trust networks» between devices.

Along the way, difficulties encountered in implementing the original proof-of-concepts have been resolved, automating the process and simplifying its use. These tools may be helpful for future research in the Bluetooth standard and are published in the Tarlogic code repository.

This article shows the tools developed for the research and delves into the operation of the Bluetrust vulnerability, but first, a brief review of the operation of BIAS and KNOB and the pitfalls for their implementation.

1. BIAS and KNOB

BIAS and KNOB are two of the attacks published about the Bluetooth standard in 2019 and 2020 that have had the most impact in the specialized media. Published by Daniele Antonioli‘s team, both affect the Bluetooth standard and, therefore, all devices that implement it. Part of our Bluetooth research focused on reproducing both vulnerabilities in laboratory environments, finding that their practical application is limited, and they do not pose a threat in a realistic environment.

1.1. BIAS

BIAS affects authentication between two Bluetooth devices, allowing a malicious user to impersonate one device against another. To do so, it exploits the possibility of using an insecure authentication method, known as Legacy Authentication. Bluetooth authentication works based on cryptographic challenges: the authenticating device (Master) sends a random number to the slave device to be authenticated, and the slave device responds with the result of encrypting the random number with the key shared between the two. The Legacy Authentication method only requires the slave device to respond to the authentication challenge, and does not expect a validation response from the Master authenticator, so if the malicious user is the master or impersonates the master, he can pretend to be another device and pass the authentication despite not knowing the key previously shared in the pairing.

In case the malicious user acts as a slave in the connection, he can use the role switching mechanism before authentication is initiated to become a master so that he reverses the roles and can make use of this flaw.

The role reversal mechanism allows a master to become a slave in communication or vice versa and is introduced in Bluetooth so that devices that are only capable of operating as slaves can initiate connections. After establishing a connection, the initiating device becomes the master by default, but if the device is not capable of operating as a master, it can send a request to change the role from master to slave. If the other device accepts the request, the roles are exchanged, and communication continues.

BIAS exploits the reverse possibility: that a slave becomes a master. This role change can occur at any time after the start of the connection, so it can be performed before authentication, to ensure that you are the master device and do not need to be authenticated.

With this combination, the user is always master and never needs to authenticate, so he can impersonate another device.

However, after authentication, modern Bluetooth devices require encryption of communications. BIAS takes care of bypassing authentication, but does not address data encryption or decryption, so it will not be able to continue to impersonate the device after initiating data encryption.

1.3. KNOB

KNOB aims to reduce the size of the encryption key to facilitate a brute force attack to break the encryption between two devices. This allows decrypting encrypted traffic or, if done in real time and combined with BIAS, exchanging encrypted information pretending to be another device by establishing a valid communication.

The key used during an encryption session is a temporary key (Kc) derived from the link key (KL) shared by both devices during the pairing process, plus random numbers exchanged during connection establishment, communication clock data and the address of the master device.

After calculation of the temporary encryption key (Kc), a key size can be negotiated to decrease the workload during encryption on devices with low computational capacity. During this negotiation process, each device proposes a key size until both agree. At that point, the original 128-bit (16-byte) Kc key is shortened by removing the least significant bytes left over to the negotiated size.

The KNOB technique attempts to intervene in the negotiation of the key size to ensure that the negotiated key is only a few bytes. A key as small as 1 byte, for example, is vulnerable to brute force attacks to obtain the encryption key.

The difficulty of this vulnerability lies in its implementation, since modifying the size of the negotiated key requires interfering with communications between two legitimate devices, which requires, at the very least, the ability to sniff and inject packets.

Sniffing in BR/EDR has its own complications since the Bluetooth protocol uses a mechanism called “channel hopping” which consists of transmitting each packet on a different frequency, this is done to improve data transmission in noisy environments, avoid interference and add greater difficulty in capturing and injecting packets.

1.3. Combining BIAS and KNOB

Another possibility is to combine BIAS and KNOB: you impersonate a device with BIAS, initiate a connection to another device linked to the first device bypassing authentication and use KNOB to break the encryption. At this point, encrypted messages could be sent and received as if it were the original device.

In practice, this case requires capturing an encrypted message, which is sent by one of the devices at the time of connection, decrypting the message, obtaining the key and responding to the communication before the connection is closed due to inactivity, something that in the Bluetooth standard is done in a very short time interval. Performing the whole process before the connection is closed due to timeout is not feasible.

2. Overcoming the challenges of BIAS and KNOB

Part of the difficulty in implementing a combined BIAS and KNOB attack is the lack of tools, so that many of the tasks require manual work.

Below, we explain and share some of the advances, improvements and automations made that may be of help to other researchers to combine BIAS and KNOB and open new lines of research.

2.1. Bluetooth development board: Cypress CYW920819EVB-02

One of the problems encountered during the research is the lack of Bluetooth tools and drivers to work with. Even in those cases where tools are found, many of them are not maintained or are not compatible with other versions of libraries or software that have advanced.

An example of this problem is the lack of support for the use of the Cypress CYW920819EVB-02 card used in the BIAS and KNOB investigations. Although it is originally used in those investigations, there is no documentation for its use in a Plug and Play manner, therefore, during this research, support scripts have been developed that allow the Linux kernel to automatically detect this card and associate the appropriate driver to it.

More specifically, udev rules and systemd targets have been created for the detection and launch of the corresponding service, which also serves as a basis for supporting more devices with similar problems. The code can be found in Tarlogic’s Bluetooth Attach Service GitHub repository.

2.2. Dissecting Broadcom HCI messages with Wireshark

Once a proper functioning of the board used for the BIAS and KNOB proofs of concept was achieved, the lack of tools for debugging and analyzing what happens during execution became evident. More specifically, there was no functional solution to capture and study the communications that were taking place during the test execution.

Bluetooth splits the implementation of its protocol stack between a host device, usually the operating system of a PC or a cell phone, and a driver device, an electronic module separated from the host hardware and implementing the lower layers of the standard.

The CYW920819EVB-02 board driver enables a proprietary debugging function of the manufacturer, Broadcom, which sends received and sent low-level messages to the host. These debug messages are received by the host via the HCI protocol, which is the communication protocol between the host and the Bluetooth controller.

On the other hand, one of the most widespread solutions for protocol analysis is Wireshark. A packet dissector has been implemented for Wireshark with the capability to analyze HCI packets from Broadcom debug messages, which contain the low-level messages. Capturing the low-level traffic is very useful for debugging and analyzing the behavior of the Bluetooth adapter, among these messages are part of the LMP protocol, the protocol that controls the state of the Bluetooth BR/EDR links and implements security functions such as authentication and encryption.

The code to dissect these packages is located in the Wireshark repository on Tarlogic’s GitLab server.

2.3. Sending and receiving HCI messages

With the possibility of using the hardware in a consistent way and with a tool that allows evaluating and debugging what is happening in the lower layers of the Bluetooth protocol, the next challenge during the research focused on the possibility of sending and receiving messages programmatically.

To achieve the sending and receiving of messages, the Scapy framework has been modified, this library allows the creation of packets of different protocols for their reception and sending. Scapy already has support for sending and receiving some Bluetooth messages, but it does not have support for interacting with the lower Bluetooth BR/EDR layers. Specifically, it implements only some HCI messages, so the library of available messages has been extended.

Among the added messages, many belonging to the standard are included, such as those involved in BR/EDR discovery or inquiry. In addition, the necessary code has been implemented to add vendor-specific messages and some of Broadcom’s own messages, which allow the manipulation of Broadcom controllers.

Another challenge is to interact with a Bluetooth device in an exclusive way without other services of the operating system and the host stack (BlueZ in this case) taking control of the communication and interrupting the execution of the tests. To avoid this, the Bluetooth User Socket has been implemented in Scapy: a type of Bluetooth sockets, supported by Linux systems, that allow exclusive use.

On the other hand, sending and receiving LMP messages is implemented in the driver firmware, so it is out of the host’s reach. However, in the case of Broadcom controllers, LMP messages are forwarded to the host in the form of debug messages. To capture these messages programmatically, from Scapy, an additional type of socket is required: Bluetooth Monitor Socket. Support for this type of socket has been added in the Scapy framework extension, allowing LMP messages to be captured and parsed.

Both types of sockets, Bluetooth User Sockets and Bluetooth Monitor Sockets, are supported by Linux kernel systems through the socket() function. The implementation made for Scapy makes it much more accessible for use in Python and facilitates the implementation of tools.

All Scapy modifications are available in the Scapy fork on Tarlogic’s Github.

3. BlueTrust, a Bluetooth vulnerability

After all the knowledge acquired during the process of research and replication of Bluetooth vulnerabilities, the Bluetooth vulnerability has been developed, using the standard in an unintended way. BlueTrust reuses part of the BIAS development and applies it to the discovery of bonding relationships between Bluetooth devices.

Bluetooth devices that have been paired with each other share a link key that they use during authentication, encryption and other security functions. Pairing between devices can be evidenced by verifying that both devices share a key, without physically accessing the device or extracting information from its firmware.

This is achieved by exploiting the BlueTrust vulnerability that affects the standard, which makes it possible to obtain relationships between Bluetooth devices, calling into question the privacy maxim with which Bluetooth is designed.

Successfully exploiting BlueTrust requires four phases:

1. Device discovery.
2. Profiling.
3. Device impersonation.
4. Pairing detection.

3.1. Device discovery

The first step is the detection of the devices. This is done using the procedure documented in the Bluetooth standard and can be done using the active method, typical of Bluetooth BR/EDR, or the passive method, typical of Bluetooth LE.

The discovery process consists of activating the inquiry mode of the driver and receiving responses from nearby devices, using the modifications made to Scapy. In inquiry mode, the controller sends discovery requests and waits for responses. Discoverable devices respond to the requests with messages that include, among other information, the address and class of the device. If a device name is not found in the response messages received, it is explicitly requested.

3.2. Profile creation

The BIAS attack allows to impersonate the identity of a Bluetooth device, but this identity is composed of different and not all of them appear in the device discovery messages. Specifically, to impersonate the identity of a device, the following data are required:

• BT name: name of the device.
• BT address: MAC address.
• Device class: indicates the device type according to the Bluetooth SIG classification.
• LMP version: LMP protocol version, which corresponds to the maximum version of the Bluetooth standard.
• Company ID: identifier of the controller manufacturer.
• LMP subversion: manufacturer-specific value, usually corresponding to the controller firmware version.
• LMP features: bitfield indicating which parts of the standard are supported by the controller.
• IO capabilities: value that identifies the input and output controls of the device: whether it has a display, keyboard, or buttons.
• Authentication requirements: indicates the protections required during authentication between devices, including protection against MitM, which consists of requiring the use of Secure Authentication.

This set of data is called a device profile and contains everything necessary to impersonate it against others until the encryption phase is reached. Apart from the name, address and class, the rest of the data is exchanged during the initiation of a connection or pairing.

To perform the fetching of most of the data and prevent the user from being notified, HCI messages are sent with the Scapy library, in a sequence of connection initiation, data request and connection closure. By performing the connection attempt in this manner, device operating systems do not notify the user that a connection attempt has been initiated.

However, there are messages that cannot be captured with such a simple process. Specifically, input and output capabilities (IO capabilities) are only exchanged during the pairing of two devices and cannot be captured with a normal connection, but instead a pairing must be forced.

The Bluetooth driver initiates a pairing when, during an authentication, the host does not know a link key for the remote device.

On Linux, the BlueZ Bluetooth stack allows interacting with the stored keys via the mgmt-api API, and the btmgmt tool. Therefore, to obtain the input and output capabilities and complete the device profile it is necessary to remove any corresponding stored keys with the device, send a connection and authentication request, and capture the message with the IO Capabilities information. Once the message is captured, the connection is terminated abruptly, preventing the user from being notified.

3.3. Device impersonation

With the complete profile, the device identity can be spoofed using the Cypress CYW920819EVB-02 board.

The identifying data of a device is stored in the controller memory, so it will be necessary to modify this memory. Broadcom’s own HCI messages allow to do just this, overwrite the profile data in the controller memory.

From this point on, when a device requests the name, the Cypress board will reply with the name of the supplanted device, and the same with the rest of the identity parameters.

However, if the Cypress board tries to initiate a connection to another device at this point, it may find that the host itself closes the connection prematurely. This is because the host’s protocol stack, BlueZ, does not find a key corresponding to the remote device, and consequently cuts the connection.

To avoid this, before each connection, a randomly generated key is added via btmgmt, which, although not valid, allows BlueZ to continue to the authentication phase.

3.4. Pairing detection

With the ability to scan the environment and impersonate devices, you can proceed to the last step, which is to detect if any of the discovered devices are paired with the impersonated device. This means that at some point in time both devices have been connected and therefore have generated a shared key, they store it to authenticate each other, i.e. they have been connected in the past.

During authentication, a remote device can react in two ways during the challenge exchange:

• With an LMP sres message in response to the challenge, calculated with the link key.
• By rejecting the challenge, with an LMP not accepted message, which cuts off the connection, or by stopping sending messages.

In the first case, it is evident that the device knows the shared key, as it needs it to calculate the response to the challenge, and in the second case, that it does not know it.

This difference makes it possible to distinguish whether the authenticated device knows the authenticator. During the interaction, a connection has not been completed, nor an authentication, so the user of the device does not receive a notification.

The key messages that distinguish whether a device responds correctly to the authentication challenge or not are exchanged at the LMP layer, and not at the HCI layer, so the host does not receive the information directly and it is necessary to use the monitor mode sockets.

These sockets make it possible to observe all host messages and receive debugging messages. These debug messages are defined by the driver manufacturer and, in the case of Broadcom and Cypress CYW920819EVB-02 board, contain the LMP packets observed only by the Bluetooth driver. By activating the debug function of the board, with a specific HCI message, and with Sockets monitor, the LMP messages needed to detect pairing between devices can be captured.

The discovery – profiling – spoofing – pairing detection cycle can be repeated automatically for all identified devices, generating a graph of the relationship of known devices to each other.

4. BlueTrust use cases

BlueTrust allows different uses, such as the collection of personal information, which can be useful in phishing exercises, but there are more specific uses in scenarios that represent new research opportunities.

4.1. Forensics

In the scenario of a forensic investigation where Bluetooth devices are found, BlueTrust can be useful to take as evidence which devices have been connected to each other.

This is especially useful in cases where it is not possible to interact normally with the device during the investigation, for example, a cell phone that is locked, but the Bluetooth is active or can be activated externally.

In this scenario, obtaining the relationships of a device to the environment can be used to gather evidence on:

• Location: Bluetooth connections are short-range, so the device under investigation must have been within close range of the devices it connected with.
• Relationship with other people: two devices of different owners being paired and connected indicates that their owners have been in contact, or at least their devices have been in contact.
• Extending lines of investigation: the devices to which the investigated device is related may contain additional information that can be used as evidence during the investigation. For example: the location history of a cell phone may serve as evidence of the location of the owner of a Bluetooth headset connected to the phone.

4.2. Red Team

During a Red Team exercise, the discovery of vulnerable devices that can be used as a pivot or access point to an infrastructure, this information is very useful during the reconnaissance phase and, in a scenario with Bluetooth devices, distinguishing the relevant devices can be a challenge and widens the exploitation surface.

In this case, BlueTrust can be used to distinguish the relationships between devices and select those that can be used as a pivot most successfully. Especially in targeted exercises, where only a limited set of resources are relevant, Bluetrust can help to shape the attack surface in a more effective and agile way.

Bluetooth security research, including BIAS and KNOB, has enabled the development and publication of tools that simplify research with Bluetooth devices and make it more accessible. The publication of these tools can open the exploration for the discovery of new vulnerabilities and applications of Bluetooth technologies.

BlueTrust relies on research to create a new mechanism to obtain information about Bluetooth devices and their users. It allows to trace networks of relationships between devices and these can be used, among other uses, as a method to link different devices in a forensic investigation or to increase the attack surface in a network exercise.