Role switch before authentication
BR/EDR
In a Bluetooth communication there are two defined roles:
- Master: Is the main role of a “piconet” (network of Bluetooth devices) and defines the physical parameters of the connections.
- Slave: Device that simply follows the steps of the master.
After the initiation of a physical connection, the initiating device automatically becomes the master.
In this context, role switching is commonly used by devices that can only act as slaves to avoid being masters of the connection when they have been initiators of the connection.
However, this mechanism can be abused to avoid the authentication process by a device acting as master, since the Legacy authentication process only requires the master device to authenticate the slave but not the other way around.
For example, BIAS uses this capability for a slave device to become the master of the communication just before authentication, and thus avoid being authenticated by the other end. With this strategy, it can impersonate other devices against a victim with which the impersonated device was paired.
It is preferable to avoid the use of the slave to master role change mechanism if it is not necessary for the normal operation of the device.
Description
The role change message is produced with LMP messages and is therefore dependent on the firmware of the Bluetooth driver.
To check whether a device allows a role change from slave to master, it is necessary to have a driver that allows sending LMP role change messages at arbitrary moments of the communication.
Modifications to the CYW920819WCD2 driver firmware made as part of the BIAS PoC include a patch to change the role of the device from slave to master prior to authentication, so in conjunction with Wireshark it can be used to test control, although this requires the CYW920819EVB-02 development board, or one compatible with the “Patch ROM” mechanism.
The process consists of patching the firmware on the board (an example of how to do this is available at the BIAS repository) and using the board to initiate a connection to the audited device while capturing the communication with Wireshark. Before starting the communication it is necessary to activate the debug messages on the board, which include the LMP messages sent and received. In addition, traffic must be captured through the bluetooth monitor interface and the Broadcom debug message dissector must be used to observe and interpret the LMP messages correctly.
Just before authentication, you will observe an LMP_role_switch message being sent. If the message receives an LMP_accepted response, the device is not in compliance with the control.
Related resources
To check this control, the following resources may be useful:
| ID | Description |
|---|---|
| BSAM-RES-04 | Bluetooth connections sniffing |
| BSAM-RES-05 | Capture of a Bluetooth connection |
| BSAM-RES-06 | Enabling debug mode on a Bluetooth controller |
| BSAM-RES-07 | Sending and receiving HCI messages |
| BSAM-RES-09 | Changing the attributes of a controller |
Example case
We will use Wireshark with BTVS (btvs.exe -Mode wireshark) to capture packets for analysis.
There is a laptop with the Scapy tool that is performing pairing with Peripheral role to another device with the Central role. During the connection process is possible to perform an additional step called role switch.
The peripheral device receives the central device connection request through the HCI_Connection_Request command.
The Peripheral device response by accepting the connection using the HCI_Accept_Connection_Request command. It communicates its intention to function as a Central device by configuring the Role field with a value of Role field with value 0x00 (Become Central for this connection. The LM will perform the role switch.).
If the remote device accepts this role change, it will respond with the HCI_Role_Change command, and the Status field will have a value of 0x00 (A Role change has ocurred.). Any other value would indicate an error code for the procedure.
To determine whether this role switch is occurring before the authentication process, the HCI_Link_Key_Request_Reply command followed by the HCI_Command_Complete command should be located in the Wireshark capture.
If the HCI_Accept_Connection_Request command is before the two commands (HCI_Link_Key_Request_Reply / HCI_Command_Complete), it indicates a role switch before the authentication stage.
The check control FAIL if the HCI_Role_Change command with the Status field set to 0x00 is found before the authentication of the devices.
