Pwning bluetooth devices in unexpected ways

Pwning bluetooth devices in unexpected ways

Speakers: Damien Cauquil, Security Engineer, Quarkslab

Conference: BruCON

YouTube: https://www.youtube.com/watch?v=TF7FOeUT2Fo

Overview

In this BruCON talk, Damien Cauquil, a seasoned security engineer at Quarkslab and co-author of well-known Bluetooth testing tools like Beetlejuice, Beetlejack, and WAD, delves into the often-overlooked vulnerabilities within Bluetooth Low Energy (BLE) devices. The presentation uncovers a range of unexpected and peculiar behaviors discovered during extensive testing of various BLE-enabled gadgets, from smartwatches and trackers to light bulbs. Cauquil aims to highlight lesser-known features of the BLE specification that can be exploited, challenging common assumptions about the protocol's security.

The talk provides a comprehensive technical exploration, beginning with fundamental BLE concepts before dissecting practical attacks on privacy, device control, and even low-level stack integrity. A significant portion of the presentation is dedicated to a candid recounting of a "critical vulnerability" discovery that, while initially a misunderstanding, ultimately led to the identification of a genuine, albeit more subtle, data leakage vulnerability in specific System-on-Chips (SoCs). This narrative underscores the iterative and often surprising nature of security research, emphasizing that even apparent failures can pave the way for deeper insights.

Cauquil's insights are particularly relevant in an era where BLE devices are ubiquitous, permeating households, wearables, and industrial settings. The vulnerabilities discussed range from simple tracking bypasses and denial-of-service attacks to more sophisticated information leaks from device memory buffers. By demonstrating how a peripheral device can act as a GATT client to query a connected smartphone, and how seemingly read-only attributes can be modified, the talk offers crucial lessons for both developers implementing BLE stacks and users interacting with these devices, urging a more cautious and informed approach to BLE security.

Background

▶ Watch: Introduction to BLE oddities and vulnerabilities (1:30)

Bluetooth Low Energy (BLE) was designed to enable wireless communication for tiny, battery-powered devices by optimizing for minimal power consumption. This is achieved primarily by exchanging data not continuously, but in specific, infrequent intervals ranging from 7.5 milliseconds down to 4 seconds. Operating within the 2.4 GHz band, BLE utilizes frequency hopping across 40 channels (each 2 MHz wide) to mitigate collisions and ensure reliable data transmission, reusing many components from the earlier Bluetooth Classic specification.

The communication process typically begins with advertising. BLE devices regularly broadcast advertising data over three dedicated channels (37, 38, and 39). These advertising records contain crucial information, structured with a length byte, a type byte, and the payload itself, which can include device names, manufacturer data, and flags. To establish a connection, a central device (e.g., a smartphone) sends a connection request immediately after receiving an advertisement. The device receiving this request becomes the peripheral device, and the connection is considered established without an explicit acknowledgment, with both devices then synchronously hopping between channels to exchange data.

The BLE protocol stack involves several layers, with this talk focusing on the L2CAP layer (handling fragmentation and reassembly) and the Attribute Protocol (ATT). The Generic Attribute Profile (GATT), built atop ATT, specializes its functionality. The ATT protocol defines a set of attributes, each uniquely identified by a UUID (16-bit or 128-bit) and referenced by a 16-bit handle (an incrementing index). Key attribute types include primary services, characteristics, and descriptors, which together form a hierarchical attribute database. For instance, a primary service contains one or more characteristics, each of which holds a characteristic value and can have associated descriptors. Data exchange occurs by a central device writing bytes into a peripheral's characteristic value, which then triggers firmware processing and potential responses or notifications.

BLE incorporates several security mechanisms. Address randomization aims to prevent tracking by regularly changing the device's Bluetooth device address. This can be either non-resolvable private addresses (NRPA), which are purely random, or resolvable private addresses (RPA), which require bonding and the exchange of an Identity Resolving Key (IRK) for a challenge-response mechanism. Starting with BLE v4.2, Secure Connections introduced more robust encryption, further enhanced by a more random channel selection algorithm in v5. However, the speaker notes that many BLE devices forgo encryption due to the complexity of pairing, often pushing security concerns to the application layer, leaving the underlying BLE layer unprotected. The rapid evolution of the BLE specification, from v4 to v6.3, also presents challenges, with new stacks constantly being developed, leading to a higher potential for implementation and design flaws.

Key Findings

▶ Watch: Peripheral acting as GATT client to attack phones (24:00)

Damien Cauquil's research unveiled several critical weaknesses and unexpected behaviors across various BLE devices and stacks:

1. Privacy Bypass via Persistent Unique IDs: Despite BLE's address randomization features (NRPA), many devices inadvertently expose persistent, unique identifiers within their advertising records (e.g., manufacturer data) or readily accessible characteristics. This allows for continuous tracking even when the Bluetooth device address changes, defeating the privacy mechanism.

1. Active Fingerprinting of BLE Stacks and Firmware: Devices can be fingerprinted by querying their LL version ind message, which reveals the underlying System-on-Chip (SoC) vendor (e.g., Qualcomm), supported BLE version (e.g., BLE 5), and the baseband firmware subversion number. Additionally, enumerating exposed services and characteristics and cross-referencing them with collaborative databases (like Zeno Corva's) can precisely identify device types and potential vulnerabilities.

1. Smartphone Vulnerability as a GATT Server: A significant discovery is that when a smartphone (acting as a GATT client) connects to a peripheral device, the smartphone often exposes its own GATT server by default. This allows a malicious or specially crafted peripheral to act as a GATT client and query the smartphone's exposed services and characteristics, potentially exfiltrating sensitive information or even launching further attacks.

1. Permission Bypass in Attribute Writes: Numerous BLE stacks fail to correctly enforce attribute permissions. Devices were found to allow write operations to read-only characteristic values (e.g., modifying a device name characteristic 2A00) and even critical primary service definitions (e.g., handle 0x0001). This leads to unauthorized device modification and denial of service.

1. Denial of Service (DoS) Vulnerabilities:

• Application-layer DoS: Modifying a primary service UUID can break the associated smartphone application's ability to connect and interact with the device, as the app relies on specific UUIDs for service discovery.
• Stack Crash DoS: Writing malformed data or attempting writes to sensitive, restricted memory locations (e.g., writing FFFF twice to primary service definition handle 0x0001 on a BB tracker) can crash the BLE stack, leading to an endless reboot loop requiring a battery removal to recover.
• Malformed PDU DoS: Sending a specifically crafted, malformed ATT PDU (e.g., an unexpected response opcode like 0x0A without a preceding request) can cause a device (like a smartwatch) to reset or reboot.

1. Data Leakage from System-on-Chip Buffers: While an initial hypothesis about leaking residual data from the reception buffer via manipulated PDU lengths proved incorrect (it actually leaked the sender's own transmit buffer), further research led to a genuine 4-byte data leakage vulnerability. This exploit leverages an invalid ATT length check in specific BLE stacks (GD system on chip maker, Blue Tron) by combining a malformed Read Request (0x0A without a handle) and a Find Information Request (0x04) in a dichotomic attack to reconstruct up to four bytes of residual data from the device's reception buffer.

Technical Deep Dive

▶ Watch: The 'shameful' vulnerability: leaking own transmit buffer (37:00)

Damien Cauquil's talk meticulously breaks down the technical underpinnings of BLE and the vulnerabilities he uncovered. The protocol's reliance on a 2.4 GHz band split into 40 channels, with advertising occurring on channels 37, 38, and 39, forms the bedrock of initial device discovery. Advertising records are crucial, where each record begins with a length byte, followed by a type byte (e.g., 0x06 for flags, 0x09 for complete local name), and then the data payload. An example demonstrated how a device might advertise as "Broadcom" by encoding this in a 0x09 type record.

The BLE communication stack, particularly the L2CAP and ATT layers, is central to the discovered flaws. An L2CAP PDU encapsulates data, featuring a 2-byte LL header and a 4-byte L2CAP header that specifies the payload size and the channel ID (e.g., indicating an ATT payload). The Attribute Protocol (ATT) defines the hierarchical attribute database, where primary services contain characteristics, which in turn hold characteristic values and descriptors. Each attribute is identified by a 16-bit handle and a UUID. The speaker highlighted that ATT defines specific operations like Read, Write, and Enumerate Attributes, and the permissions for these operations are critical.

Privacy Bypass (Bose NC 700): The Bose NC 700 wireless headset was presented as a case study. It uses both Bluetooth Classic for audio and BLE for control. While it implements non-resolvable private addresses (NRPA), randomizing its Bluetooth device address, it also includes a custom unique ID within its manufacturer data record in advertising packets. This custom ID, despite being "rolled regularly" by Bose, often remains constant even when the Bluetooth device address changes. This allows an attacker to correlate the device across address changes, effectively bypassing its privacy mechanism. The speaker also noted that many devices broadcast user-assigned names, which, if unique, can also be used for tracking.

Fingerprinting BLE Stacks: Active fingerprinting was demonstrated using the LL version ind message. This message, exchanged at the link layer, reveals the underlying hardware's baseband Bluetooth version, a company identifier (e.g., Qualcomm Technologies International), and a subversion number often tied to the specific firmware version. This allows an attacker to identify the SoC and potentially known vulnerabilities associated with that firmware. Furthermore, enumerating all services and characteristics UUIDs and consulting a collaborative database (like Zeno Corva's, which lists over 500 verified UUID sets) can precisely identify device models and their specific characteristic structures, often exposing serial numbers or other unique identifiers.

Peripheral as GATT Client: A critical, often overlooked, aspect of the BLE specification is that a peripheral device can also act as a GATT client. When a smartphone (typically a GATT client) connects to a peripheral (GATT server), the smartphone itself often exposes a default GATT server. This means a malicious peripheral can initiate requests to the connected smartphone, enumerating its services and characteristics, and potentially exploiting vulnerabilities in the phone's BLE stack. Cauquil demonstrated this with a Python script emulating a "Ledger Nano, go hack me" device, which, upon connection, successfully listed all services and characteristics exposed by the connecting smartphone.

Permission Bypass Attacks:

The talk highlighted a fundamental permission checking issue, stemming from the distinction between ATT level attribute permissions and GATT level characteristic properties.

• Writable Read-Only Characteristics: On a BB tracker, the device name characteristic (UUID 2A00), defined as read-only, could be written to. The system stack allowed writing "hack" into it, which persisted even after disconnection and reconnection. If a device uses this characteristic for advertising, its broadcasted name would change.
• Service Definition Modification (DoS): On a BLE light bulb, a primary service UUID (e.g., 00010203...) could be modified. Since the smartphone application relied on this specific UUID for service discovery, altering it rendered the device unconnectable and unusable by the legitimate app, causing a denial of service.
• Stack Crash (DoS): Attempting to write FFFF twice to handle 0x0001 (the primary service definition) on a BB tracker caused the device to disconnect and enter an endless reboot loop. This suggested an invalid memory write leading to a stack crash, requiring physical intervention (battery removal) to recover.
• Malformed PDU (DoS): Sending an unexpected ATT PDU with an operation code 0x0A (Read Response) to a smartwatch that hadn't requested anything caused it to reset or reboot, demonstrating a vulnerability to malformed protocol data units.

Data Leakage from SoCs (The "Shameful" Story and Actual Discovery):

Cauquil initially hypothesized a data leak by sending an incomplete PDU with a manipulated L2CAP length (e.g., 128 bytes) but a short ATT PDU (e.g., 5 bytes), expecting the firmware to process residual data in the reception buffer (RX buffer). However, he later realized he was merely leaking his own transmit buffer (TX buffer), as his attacking SoC sent data based on its LL header length, which he had set to a large value.

This "failure" spurred further investigation, leading to a genuine 4-byte data leak. The new technique exploits an invalid ATT length check in vulnerable BLE stacks (specifically, GD system on chip maker and Blue Tron SoCs).

1. Recovering 2 Bytes: An attacker sends a Read Request (0x0A) without any handle.

• If the next two bytes in the RX buffer happen to match a valid handle, the device responds with the associated attribute value.
• If they don't, the device sends an error PDU containing the two "erroneous" bytes as the handle, effectively leaking them.

1. Recovering 2 More Bytes (Dichotomic Attack): To get the subsequent two bytes, the attacker uses the Find Information Request (0x04), which takes four bytes: a starting handle and an ending handle. A critical constraint is that the starting handle must be less than or equal to the ending handle. By injecting specific bytes into the RX buffer (e.g., by sending an invalid ATT operation and flushing the buffer), and then sending 0x04 with a controlled starting handle, an attacker can use a dichotomic search to guess the values of the two bytes immediately following the previously leaked two bytes.

This combined technique allows for the exfiltration of up to 4 bytes of residual data from the device's RX buffer, which could contain sensitive information like PIN codes if they were recently processed.

Demo / Proof of Concept

▶ Watch: New plan: leaking SoC reception buffer using ATT requests (39:40)

Damien Cauquil's talk included several compelling demonstrations and proof-of-concept scenarios, illustrating the practical implications of his findings:

1. Bose NC 700 Tracking Bypass: While not a live demo, the speaker presented a visual representation of how the Bose NC 700 headset's non-resolvable private address (NRPA) would change, but its custom unique ID embedded in the manufacturer data record of its advertising packets would remain constant. This allowed for continuous tracking of the device despite its address randomization, effectively tying together different broadcast instances.

1. Smartphone as GATT Server / Malicious Peripheral: This was a key demonstration. Cauquil showed his Python script emulating a peripheral device named "Ledger Nano, go hack me" running on a laptop. On the right side of the screen, a smartphone running the Nordic Semiconductor nRF Connect application was shown connecting to this emulated peripheral. Crucially, once the connection was established, the Python script (acting as a GATT client) was able to list all services and characteristics exposed by the smartphone itself. This vividly illustrated how a smartphone, usually considered a "client" in BLE, can inadvertently expose its own GATT server when connecting to a peripheral, making it vulnerable to queries from the peripheral.

1. BB Tracker Permission Bypass: The speaker demonstrated writing to a non-writable characteristic. He connected to a BB tracker (a small luggage tracking device) and showed that its device name characteristic (2A00) was designated as read-only. Despite this, he successfully wrote the string "hack" into it. He then read the characteristic back, confirming that the value had been modified and persisted even after disconnection and reconnection.

1. Light Bulb Denial of Service (DoS): Cauquil showed how modifying a specific primary service UUID on a BLE light bulb could render it unusable. He modified the UUID to a custom value (e.g., 112233445566). The associated smartphone application, which was designed to look for the original, specific UUID during service discovery, could no longer find or connect to the light bulb, effectively denying service to the legitimate user.

1. BB Tracker Stack Crash (DoS): This demo involved writing specific malformed data to a sensitive area. By writing FFFF twice to the handle 0x0001 (representing the primary service definition) of the BB tracker, the device immediately disconnected and ceased advertising. The speaker explained that this action caused the device's BLE stack to crash and enter an endless reboot loop, necessitating a physical battery removal to reset the device.

1. Smartwatch Reset (DoS): A brief, but impactful, demonstration showed a smartwatch instantly rebooting after receiving a specifically crafted, malformed ATT PDU. The PDU contained an 0x0A operation code (Read Response) without any preceding request, which the smartwatch's stack failed to process correctly, leading to a reset.

1. 4-Byte Data Leak Proof of Concept: For the actual data leakage vulnerability, a short demo was presented where the speaker connected to a target device. He then injected four specific bytes of data into the device's buffer using an intermediary step. Subsequently, by employing the refined Read Request and Find Information Request technique, he successfully recovered those four injected bytes, proving the ability to exfiltrate data from the reception buffer of vulnerable SoCs like those from GD system on chip maker and Blue Tron.

Defensive Implications

▶ Watch: Q&A: Why SDR cannot bypass BLE frame CRC checks (48:30)

The insights presented in this talk highlight several crucial defensive strategies for developers, manufacturers, and end-users of BLE devices:

1. Strengthen Privacy Beyond Address Randomization: Developers should not rely solely on BLE's built-in address randomization. Thoroughly audit all advertising records and accessible characteristics to ensure no persistent, unique identifiers (e.g., serial numbers, custom IDs, user-assigned unique names) are being broadcast or exposed. If unique IDs are necessary, they must be cryptographically secured or change frequently in a non-correlatable manner.

1. Implement Robust Permission Checks at All Layers: The discrepancy between ATT and GATT level permissions is a significant vulnerability. BLE stack developers must ensure that attribute properties (read, write, notify, etc.) are rigorously enforced at both the ATT and GATT layers. Writing to read-only characteristics or sensitive service definitions should be strictly prohibited and properly handled as an error, not allowed to modify device state or crash the stack.

1. Validate All Incoming PDUs Rigorously: Malformed PDUs can lead to denial-of-service or information leakage. BLE stacks must perform comprehensive validation of all incoming PDU lengths, opcodes, and parameters to prevent crashes, unexpected resets, or buffer over-reads/under-reads. Devices should gracefully handle invalid PDUs, ideally by sending an error response, rather than crashing or leaking data.

1. Be Wary of Peripheral GATT Client Behavior: Smartphone and operating system developers must recognize that when a central device (like a smartphone) connects to a peripheral, the peripheral can act as a GATT client and query the central device. Default GATT servers on smartphones should be minimal, expose only strictly necessary services, and require explicit user consent or robust authentication for access. Users should be cautioned against connecting their smartphones to untrusted or unknown BLE devices.

1. Keep BLE Stacks and Firmware Up-to-Date: The rapid evolution of the BLE specification means new vulnerabilities are constantly being discovered and patched. Device manufacturers and OS vendors must prioritize regular security updates for their BLE stacks and device firmware to address known issues and protect against new exploits. End-users should diligently apply these updates.

1. Layered Security for Sensitive Data: For devices handling sensitive information (e.g., PINs, medical data, financial transactions), BLE's native security mechanisms (even Secure Connections) may not be sufficient. Application-layer encryption, authentication, and integrity checks should be implemented to protect data end-to-end, independent of the underlying BLE stack's robustness.

1. Secure Development Practices: Manufacturers should adopt secure development lifecycle practices for BLE product development, including threat modeling, security code reviews, and penetration testing focused on the BLE stack and application logic. Utilizing tools like Damien's WAD can aid in identifying vulnerabilities early in the development process.

Key Takeaways

• BLE's Lower Layers are Critical: While application-layer security is often the focus, significant vulnerabilities, including DoS and information leaks, reside in the lower layers of the BLE stack, particularly the Attribute Protocol (ATT) and L2CAP.
• Address Randomization is Not Foolproof: BLE's privacy features can be bypassed by persistent unique identifiers found in advertising records (e.g., manufacturer data) or accessible characteristics, enabling device tracking.
• Smartphones Can Be Vulnerable GATT Servers: When a smartphone connects to a peripheral, it often exposes its own GATT server, allowing a malicious peripheral to act as a GATT client and query the phone's attributes.
• Permission Enforcement is Often Flawed: Many BLE stacks fail to correctly enforce read/write permissions, allowing attackers to modify read-only characteristics, alter critical service definitions, or even crash devices.
• Malformed PDUs are Dangerous: Improper handling of malformed or unexpected Protocol Data Units (PDUs) can lead to device resets, stack crashes, and even subtle data leakage from reception buffers.
• Continuous Updates and Vigilance are Essential: The BLE specification is constantly evolving, leading to new stack implementations and potential vulnerabilities. Keeping device firmware and operating systems updated is crucial for mitigating risks.
• Embrace "Failure" in Research: The speaker's candid story about a misidentified vulnerability that led to a genuine discovery highlights that thorough investigation and learning from mistakes are integral to successful security research.

About the Speaker(s)

Damien Cauquil is a security engineer at Quarkslab, a company specializing in security research and services. With a deep expertise in wireless protocols, he has been actively involved in Bluetooth and Bluetooth Low Energy (BLE) research since 2016, dedicating nearly a decade to understanding and exploiting these technologies. Cauquil is a prolific tool developer in the Bluetooth security community, known for co-authoring popular tools such as Beetlejuice and Beetlejack. More recently, he has been involved in developing WAD, initially standing for "Wireless Hacking for Wireless Hacking Devices" and now affectionately dubbed "Wireless Hacking for Dummies," reflecting its ease of use for exploring wireless protocols. His work focuses on uncovering unexpected behaviors and vulnerabilities in widely adopted wireless technologies.