Exploiting the TI BLE5-Stack: A Practical Guide to Unresolvable RPA Denial-of-Service

TLDR: A critical denial-of-service vulnerability in the Texas Instruments BLE5-Stack allows attackers to force a permanent connection drop by injecting malformed pairing packets. This flaw, tracked as CVE-2023-52709, forces the target device to discard its MAC address, requiring a physical hard reset to restore functionality. Pentesters should prioritize testing for this behavior in automotive and medical IoT devices that rely on TI chipsets and Resolvable Private Addresses.

Bluetooth Low Energy (BLE) security often feels like a game of cat and mouse played in the dark. While developers focus on encryption and authentication, the underlying stack implementation frequently harbors vulnerabilities that bypass these controls entirely. The recent research into the Texas Instruments BLE5-Stack reveals a classic failure in state machine handling, where a simple injection of malformed packets leads to a complete denial-of-service. This is not a theoretical bug found in a lab; it is a practical, reproducible exploit that impacts millions of devices currently deployed in the field.

The Mechanics of the Failure

At the heart of this vulnerability is how the BLE stack handles the pairing process when Resolvable Private Addresses (RPAs) are in use. The stack is designed to rotate these addresses to prevent tracking, but the implementation of the MAP_LL_ENC_Decrypt function fails to account for malformed packets during the transition. When an attacker sends a specific sequence of pairing requests, confirmations, and random values, the stack enters an inconsistent state.

The vulnerability triggers when the link layer receives a packet that causes the decryption function to return a failure. Crucially, the stack does not terminate the connection as it should. Instead, it proceeds to trigger an RPA update. Because the previous state was corrupted by the malformed packet, the subsequent RPA update operation fails. This failure forces the device to discard its current MAC address. Once the MAC address is discarded, the device becomes unreachable to any previously bonded peer. The only way to recover is a hard reset of the device, which is often impossible for an end-user in a remote or embedded automotive context.

Reproducing the Attack

For researchers and pentesters, reproducing this requires a setup that can manipulate the BLE link layer. The research utilized Defencics, a protocol fuzzing tool, to target the Security Manager Protocol (SMP). Specifically, test case 1001 proved effective at triggering the failure on the CC2642R1 and CC2652R1 development boards.

If you are testing a target device, you can automate the connection and pairing process using a tool like Sniffle to monitor the extended advertisements and identify if the device is using RPAs. The attack flow involves:

1. Establishing a connection with the target device.
2. Initiating the pairing process.
3. Injecting the malformed pairing sequence during the exchange of random values.
4. Monitoring for the connection drop and the subsequent disappearance of the device from the airwaves.

The following command structure is typical for interacting with such devices via bluetooth-ctl or custom scripts:

# Example of initiating a connection to a target BLE device
bluetooth-ctl connect [TARGET_MAC]

# The exploit involves sending a malformed pairing request
# that triggers the stack's failure to handle the RPA update.
# This is often achieved by fuzzing the SMP layer.

Real-World Impact and Engagement Strategy

During a penetration test, you are likely to encounter this vulnerability in automotive keyless entry systems or medical monitoring equipment. These devices often prioritize low power consumption and seamless connectivity, leading developers to use default SDK configurations that are susceptible to this flaw. If you are auditing a device, check the SDK version against the Texas Instruments security advisory.

The impact is severe because it is a permanent denial-of-service. In a vehicle, this could mean a user is locked out of their car until they perform a battery disconnect or a dealer-level reset. For a medical device, this could interrupt critical data transmission. When reporting this, focus on the lack of error handling in the link layer and the inability of the device to recover from a state-machine failure without manual intervention. This falls squarely under OWASP A06:2021 – Vulnerable and Outdated Components, as the issue is often tied to outdated SDK versions that have not been patched.

Defensive Considerations

Defending against this requires a two-pronged approach. First, ensure that your firmware is updated to the latest SDK version provided by the vendor. Texas Instruments has released patches that correctly handle the RPA update process even when the decryption function returns an error. Second, implement robust error handling in your application layer. If the BLE stack reports a link-layer failure, the application should be able to detect the loss of connectivity and attempt a controlled reset or re-initialization of the radio, rather than leaving the device in a bricked state.

Security researchers should continue to probe the edges of the BLE stack. The complexity of the Bluetooth specification means that there are likely many more state-machine vulnerabilities waiting to be discovered. If you find a device that stops responding after a specific sequence of pairing packets, do not assume it is a simple crash. Dig into the link layer and see if you have forced the device into an unrecoverable state. The tools are available, and the impact is real.