Forced disconnection

BR/EDR

BLE

During a Bluetooth connection the devices are responsible for keeping the connection open so that they can continue to exchange messages, these messages have a maximum response time from the remote device.

BR/EDR disconnection

If the timeout is exceeded the connection is automatically closed. For the closing of a connection by one of the devices, either device can send an LMP_detach message with the reason for the disconnection.

This disconnection should only be allowed by messages coming from the same connection that is being closed. An attacker can create a new connection by impersonating another device and send a disconnect message, being able to disconnect all devices with the MAC address of the message. This behavior can be exploited to produce denials of service and initiate other attacks.

BLE disconnection

If the timeout is exceeded the local device sends a cancellation of the previous send. If the command is related to the pairing process the result will be the cancellation of the pairing with a data of the reason for disconnection.

In addition to disconnection due to a timeout for a response in BLE, there is the possibility of forcing an unpairing at any point during the connection using the HCI_Disconnect command. The Handle will indicate the connection to be disconnected. Depending on whether the connection is synchronous or asynchronous, the PDU (Protocol Data Unit) of the message will differ:

Connection TypePDU MessageOpcode
Asynchronous (ACL)LL_TERMINATE_IND0x02
Synchronous (CIS)LL_CIS_TERMINATE_IND0x22

Description

Assuming the scenario where devices A and B are connected, it must be proven that device C cannot force disconnection of B. To do so, C must impersonate B and initiate a connection to A to immediately send a disconnect message.

For the check to be satisfied, the process must be rejected or the disconnect message must only disconnect C, but not B.

To check this control, the following resources may be useful:

IDDescription
BSAM-RES-04Bluetooth connections sniffing
BSAM-RES-05Capture of a Bluetooth connection
BSAM-RES-06Enabling debug mode on a Bluetooth controller
BSAM-RES-07Sending and receiving HCI messages
BSAM-RES-09Changing the attributes of a controller

Example case

We will use Wireshark with BTVS (btvs.exe -Mode wireshark) to capture packets for analysis.

We have Bluetooth headphones paired with a mobile device during the test. These headphones allow establishing a new connection with a laptop using the Scapy application, maintaining a simultaneous connection between both devices.

To initiate the connection, the laptop, with the assistance of the Scapy tool, starts the process with the LE Create Connection command.

Wireshark LE Create Connection

The headphones notify the acceptance of the connection with the LE Meta event, with a value of 0x00 (Success) in the Status field.

Wireshark Connection complete

After accepting the connection, a disconnection has been requested, proceeding to disconnect all devices that were connected to the headphones using the Disconnect command.

Wireshark Disconnect

It can be verified that the laptop have been unpaired in the Wireshark capture through the Disconnect Complete command.

Wireshark Forced Disconnect full process

The check control FAIL if it disconnects from all devices.

The auditor must verify that it is no longer paired with additional devices.

External references

  • Bluetooth Core V5.3, Vol. 6, Part B, Section 4.5.12 Connection Termination and loss
  • Bluetooth Core V5.3, Vol. 6, Part B, Section 5.1.6 ACL Termination Procedure
  • Bluetooth Core V5.3, Vol. 6, Part B, Section 5.1.16 Connected Isochronous Stream Termination procedure
  • Bluetooth Core V5.3, Vol. 4, Part E, Section 7.1.6 Disconnect Command