It Was Harder To Sniff Bluetooth Through My Mask During The Pandemic

It Was Harder To Sniff Bluetooth Through My Mask During The Pandemic

Speakers: Xeno Kovah, Founder, Open Security Training 2

Conference: HITB Phuket

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

Overview

In this insightful presentation from HITB Phuket, Xeno Kovah, founder of Open Security Training 2, delves into the pervasive yet often overlooked realm of Bluetooth device identification and tracking. Titled "It Was Harder To Sniff Bluetooth Through My Mask During The Pandemic," the talk highlights the critical need to understand the specific Bluetooth chips embedded within countless everyday devices. This understanding is paramount because numerous pre-authentication firmware vulnerabilities exist for these chips, allowing attackers in Bluetooth range to compromise device firmware and potentially pivot to the application processor.

Kovah's research is driven by a fundamental problem: despite known vulnerabilities in chips from manufacturers like Texas Instruments, Broadcom, and Silicon Labs, there's no comprehensive public knowledge of which devices use these susceptible components. His work, therefore, focuses on developing methodologies to passively and actively identify these underlying chips, thereby mapping potential attack surfaces. The presentation showcases an extensive collection of anecdotal evidence gathered from around the world, illustrating the sheer volume and diversity of trackable Bluetooth devices, from Disney Magic Bands to medical implants and heavy machinery.

Beyond the technical exposition of chip identification, Kovah's talk serves as a stark reminder of the widespread privacy implications inherent in modern Bluetooth ecosystems. The ease with which devices can be tracked, even those employing randomization mechanisms, raises significant concerns about surveillance, both by authorities and the public. Ultimately, the research underscores Bluetooth as a critical, underdeveloped area in security, urging both defenders and the community to contribute to a more robust understanding and defense against these ubiquitous wireless threats.

Background

▶ Watch: Motivation: finding Bluetooth firmware vulnerabilities (1:15)

The impetus for Xeno Kovah's extensive Bluetooth research stems from a crucial gap in our collective security knowledge: the precise identification of Bluetooth chips within myriad devices. Prior work by Armis (with their Bleeding Bit vulnerability targeting Texas Instruments firmware), Veronica Kovah (finding vulnerabilities in Texas Instruments and Silicon Labs firmware), and researchers at the Technical University of Darmstadt (exploiting Broadcom firmware) demonstrated that pre-authentication, over-the-air firmware exploits are a tangible threat. However, the applicability of these exploits remains largely unknown due to the lack of visibility into which devices contain these vulnerable chips. Kovah's primary goal is to bridge this gap by establishing methods to ascertain the specific Bluetooth chip inside any given device.

His initial methodology was straightforward: "know that I know nothing," collect vast amounts of Bluetooth data, and then analyze what remains unknown. For hardware, Kovah experimented with several options, ultimately finding the Raspberry Pi Zero to be the "all-around champ." Despite its low cost and limited RAM (0.5GB), the Pi Zero proved superior in terms of battery runtime (up to 90 hours off a single USB pack) and, surprisingly, data collection, often outperforming the more powerful Raspberry Pi 4 and the Beaglebone Black Wireless, even with its external antenna. This allowed Kovah to employ a "let them drive to me" strategy, placing sniffers in high-traffic areas like near freeways, where a single Pi Zero could collect between 10,000 and 16,000 named devices over a few days.

On the software front, Kovah relies on a pragmatic setup of Bash scripts orchestrating standard Linux command-line tools like btmon for log collection and hcitool for querying devices. Python scripts are then used for post-processing and parsing the collected data. He notes that an earlier attempt to build a C-based BlueZ D-Bus API MySQL application was abandoned due to its complexity and inability to capture the full dataset provided by the simpler CLI tools.

A core concept in Bluetooth identification is the BD Adder (Bluetooth Device Address). In Bluetooth Classic, addresses are fixed and contain a 24-bit OUI (Organizationally Unique Identifier), which uniquely identifies a company, making devices easily trackable. Bluetooth Low Energy (BLE) introduced address randomization to combat tracking:

• Public Addresses: Identical to Classic, include an OUI, and are trackable.
• Static Addresses: Randomly generated but typically fixed for the device's lifetime, making them trackable. Their most significant bits start with 1 (hex nibbles F, E, D, C).
• Resolvable Addresses: Designed to change over time, making tracking harder. They use a mechanism where devices sharing a key can resolve the identity. Their most significant bits start with 01 (hex nibbles 7, 6, 5, 4).
• Non-resolvable Addresses: Fully random, intended to be untrackable. Their most significant bits start with 00 (hex nibbles 0, 1, 2, 3).

Kovah also highlights Wigle, a crowdsourced platform primarily known for Wi-Fi stumbling, which added Bluetooth support in 2019. While useful for geographical visualization and initial data, Wigle often lacks the granular Bluetooth information needed for chip identification. Nevertheless, his data consistently shows Bluetooth devices outnumbering Wi-Fi devices by a factor greater than 10:1, up from 4:1 in 2004, underscoring the sheer scale and importance of this often-underestimated attack surface.

Key Findings

▶ Watch: Bluetooth address types and device trackability (5:45)

Xeno Kovah's extensive data collection across various geographical locations and device types revealed a consistent pattern: Bluetooth devices, despite randomization efforts, are often highly trackable and frequently expose information that can lead to chip identification.

During a leisure trip to Disney World, Kovah observed a massive proliferation of devices advertising as "Disney mbole." These devices, likely Magic Bands used for park access and payments, broadcast public, infinitely trackable addresses. Their presence was noted not only within the parks but also along roads and at resorts, suggesting widespread deployment. While the specific chip wasn't identified from the name, the sheer volume demonstrates a significant tracking potential.

At hacker conferences like hardware.io and Defcon, a new signal emerged: Flipper Zero devices. These popular multi-tool devices beacon continuously, advertising public BD adders and non-randomized names (e.g., "flipper hero new"). Kovah discovered that these names are written into one-time programmable (OTP) memory, making them static and trackable. Despite a low transmit power of 0 dBm (providing only 15-21 meters of indoor range), the unique names allow backtracking of owners to their home locations via crowdsourced data like Wigle, raising privacy concerns for attendees.

In Las Vegas, Kovah encountered Pay Range vending machine systems. While advertising "pay range," querying these devices revealed names like "blue radios" or "blue key pay range." Further investigation identified Blue Radios Inc. as the module maker, which in turn uses Nordic chips. This illustrated a key takeaway: identifying the module maker can significantly narrow down the possible underlying Bluetooth chips. Similarly, IGT card readers were found ubiquitously in various Las Vegas casinos (Win, Texas Station, Bellagio, etc.). These devices, from gaming machine hardware maker IGT, broadcast with extremely low transmit power (-72 dBm), suggesting "tap" interaction for virtual card payments. Whether their advertisements were misconfigured or intentional remains an open question.

International travels also yielded valuable insights. In Seoul, Kick Going scooters were found to advertise with an OUI directly attributable to Espressif, a known Bluetooth chip maker, providing direct chip identification. Another Korean finding was the KFTC Bank Pass, a point-of-sale terminal. While its name was often only available via a scan response, it consistently broadcast Apple iBeacon manufacturer-specific data containing a unique 128-bit UUID. This demonstrated that parsing iBeacon data can effectively identify unnamed devices by their unique identifiers. Further in Korea, analysis of BNCOM Bluetooth modules through the FCC database revealed they used Nordic NRF1 and CSR Cambridge Silicon Radio chips, highlighting the utility of publicly available certification documents for chip identification.

Automotive examples included Tesla Model 3/Y (trackable via random static BD adders and unchanging names, as detailed by Martin Herford) and Rivian vehicles, which broadcast public, trackable addresses and use Texas Instruments chips, confirmed by OUI data and FCC filings.

Surveillance cameras like Nest Cams presented a nuanced case. While they use theoretically less trackable resolvable random BD adders, they employ static names (e.g., "n0001," following a regex n[A-Z0-9]{4}). This makes them highly trackable, potentially revealing movement between residences. Kovah emphasized the importance of 16-bit service UUIDs (e.g., FEAF for Nest Labs) to confirm vendor association and avoid false positives when relying solely on generic names.

Wearable devices, particularly Fitbits, demonstrated the power of 128-bit service UUIDs. Even when a device had no human-readable name, these vendor-specific UUIDs consistently identified specific Fitbit models (e.g., Versa, Inspire, Flex2). This allows for passive identification of product lines and potentially insights into firmware changes across generations.

Medical devices posed significant security and privacy concerns. Dexcom continuous glucose monitoring systems (CGM) use random static addresses and constantly advertise "Dexcom," along with a uuid16 for the Dexcom company. This effectively broadcasts the presence of a diabetic individual. Similarly, the Tandem t:slim X2 insulin pump is trackable via a random static address and advertises "Tandem Diabetes Care." Kovah stressed the severe implications of hacking such devices, where incorrect readings could lead to life-threatening insulin overdoses. GATT (Generic Attribute Profile) information collected from these devices further revealed custom 16-bit UUIDs, offering deeper insights into their functionality. Even seemingly innocuous devices like the Philips Respironics System One CPAP (for sleep apnea) were found to be trackable via both Bluetooth Classic and BLE. A geographical analysis in the Washington D.C. area showed a correlation between CPAP device density and income levels, with richer neighborhoods having more Bluetooth-enabled CPAPs, indicating a socio-economic barrier to advanced medical tech.

Finally, heavy machinery provided a compelling study in threat modeling. Caterpillar Bluetooth Network Transceivers (BNT), used in construction equipment, act as a gateway to the CAN data link for operator identification. These devices use Texas Instruments (TI) chips (OUI 50:65:83), broadcasting public, trackable BD adders. While a Bluetooth exploit could potentially allow control of the machinery, Kovah discovered that the physical security baseline for construction equipment is remarkably low, with universal physical keys available for under $10 on eBay capable of starting virtually any Cat machine. This led to a crucial insight: a Bluetooth attack, even if feasible, represents a significantly higher bar for an adversary compared to a $9 physical key, thus constituting a "net security improvement" when considering the full threat model.

Technical Deep Dive

▶ Watch: Flipper Zero devices are easily trackable (28:50)

Kovah's research hinges on extracting specific pieces of information from Bluetooth advertisements and responses to identify the underlying silicon chip. This approach is critical for mapping known firmware vulnerabilities to actual devices.

The most direct identifier is the OUI (Organizationally Unique Identifier), the first 24 bits of a Bluetooth Classic or BLE Public Address. This OUI directly maps to a specific company, which could be the device manufacturer or, more importantly for Kovah's goal, the Bluetooth chip vendor. For instance, finding an OUI associated with Espressif (as seen with the Kick Going scooters) immediately identifies the chip. Similarly, Texas Instruments OUIs were found in Rivian vehicles and Caterpillar BNTs. This mechanism provides a strong signal for chip identification without requiring any active interaction.

While BLE introduced address randomization (static, resolvable, and non-resolvable addresses) to enhance privacy, Kovah's findings consistently demonstrated that this is often circumvented. Static device names (e.g., "Nest cam," "Flipper Zero") or vendor-specific data frequently act as persistent identifiers, making devices trackable even if their BD Adder changes. This highlights a common oversight in privacy implementations, where one layer of randomization is undermined by another static identifier.

Beyond OUIs and device names, Kovah leverages other data points within Bluetooth advertisements:

• 16-bit Service UUIDs: These are standardized identifiers for specific services or profiles. However, they are also used by vendors to identify their products or product lines. For example, the FEAF UUID consistently identified Nest Labs devices, providing a robust method to confirm a device's vendor even if its name was generic or ambiguous. These UUIDs are crucial for differentiating between devices with similar names or for identifying unnamed devices.
• 128-bit Service UUIDs: These are typically vendor-specific and offer a higher degree of granularity. Fitbit devices, for instance, used distinct 128-bit UUIDs to identify specific models (e.g., Versa, Inspire), allowing for passive model identification even when no human-readable name was advertised. This capability is powerful for researchers, as it allows for detailed profiling of devices without active queries.
• Manufacturer Specific Data: Advertisement packets can include custom data blocks defined by the manufacturer. While the content varies, these blocks often contain vendor-specific identifiers or product information, as seen with Dexcom devices.

For more in-depth analysis, Kovah employs various tools and techniques:

• btmon: This fundamental Linux command-line tool captures and parses HCI (Host Controller Interface) logs, providing a raw view of Bluetooth communication. Kovah's custom Bash and Python scripts automate the collection and processing of btmon output, transforming raw log data into structured database entries.
• FCC Database: A less conventional but highly effective source of information. Devices transmitting over radio waves in the US must be certified by the FCC, and their filings often include internal photos of modules. These photos can directly reveal the embedded Bluetooth chip, a technique Kovah used to identify chips within BNCOM modules. External documents in FCC filings also provide detailed information on module makers and their components.
• GATT (Generic Attribute Profile): This protocol allows devices to expose detailed information about their services and characteristics. While requiring an active connection or scan response, GATT queries can retrieve device names, appearance profiles, and custom vendor-defined characteristics. Kovah collected GATT information from devices like the Tandem t:slim X2 insulin pump, revealing custom 16-bit UUIDs that provide deeper insight into their proprietary functions.
• Passive vs. Active Scanning: Kovah highlights the distinction between passive scanning (simply listening to broadcasted advertisement packets) and active scanning (sending scan requests to elicit scan responses). Passive scanning is excellent for collecting OUIs, UUIDs, and manufacturer-specific data. Active scanning is often necessary to retrieve the device's human-readable name, which might not always be present in passive advertisements.

Looking forward, Kovah is developing "Toothprinting," an advanced technique that aims to leverage LMP (Link Management Protocol) packets in Bluetooth Classic. These low-level, pre-authentication packets can be queried to request information that might directly reveal the silicon vendor. This approach seeks to overcome limitations of the current Linux BlueZ stack, which often filters or doesn't expose all the raw HCI data that could be valuable for chip identification. Toothprinting represents a more proactive and precise method for determining the underlying Bluetooth hardware, moving beyond inference from OUIs and names to direct interrogation of the chip itself.

Demo / Proof of Concept

▶ Watch: Critical security of Bluetooth medical devices (44:00)

This talk did not feature a live demo or a specific proof-of-concept exploit. Instead, Xeno Kovah presented a comprehensive collection of real-world data and anecdotal findings, illustrating the pervasive nature of Bluetooth device identification and tracking based on his extensive sniffing efforts. The focus was on the methodologies and observations from collected data rather than demonstrating a live attack or a new tool.

Defensive Implications

▶ Watch: Low security baseline for heavy equipment (52:00)

Xeno Kovah's research highlights critical defensive implications for both device manufacturers and end-users, underscoring the need for a more robust approach to Bluetooth security and privacy.

For Device Manufacturers:

1. Effective Address Randomization: Simply implementing BLE's random addresses is insufficient if other identifiers remain static. Manufacturers must ensure that resolvable private addresses are properly implemented and that they are not undermined by unchanging device names or persistent vendor-specific data in advertisements.
2. Dynamic Device Naming: Hard-coded or static device names, as seen with Nest Cams and Flipper Zero, negate the privacy benefits of address randomization. Manufacturers should implement dynamic naming conventions, allowing user-configurable names, or ensuring names change frequently, similar to how MAC address randomization works on Wi-Fi.
3. Minimize Advertisement Data: Only broadcast essential information in advertisement packets. Revealing OUIs, 16-bit, or 128-bit UUIDs when not strictly necessary for device functionality can aid in device identification and tracking. A "need-to-know" principle should apply to publicly broadcasted Bluetooth data.
4. Secure Firmware Development: Given the prevalence of pre-authentication firmware vulnerabilities, rigorous security auditing of Bluetooth chip firmware is paramount. Manufacturers should maintain transparency about the chips used in their devices to allow for external security assessments and vulnerability patching.
5. Comprehensive Threat Modeling: The case of Caterpillar heavy equipment illustrates the importance of a holistic approach. While a Bluetooth exploit might be technically feasible, it's crucial to evaluate it within the context of the device's overall security posture. If existing physical security is trivially bypassed (e.g., $9 universal keys), then even a vulnerable Bluetooth interface might represent a net security improvement by raising the bar for attackers. Security architects must consider all attack vectors, not just advanced digital ones.

For Individuals and Organizations:

1. Privacy Awareness: Users should be aware that their Bluetooth-enabled devices, including wearables, cars, and medical implants, can be passively tracked. This has significant implications for personal privacy and location data.
2. Disable Bluetooth When Not in Use: As a basic security hygiene practice, disabling Bluetooth on devices when not actively being used can reduce exposure to sniffing and tracking.
3. Scrutinize Device Settings: If available, users should explore privacy settings related to Bluetooth, such as options for address randomization or changing device names.
4. Geographic Data Sensitivity: Organizations deploying Bluetooth devices (e.g., hotels with smart locks, police with body cams) must understand the implications of their devices broadcasting trackable identifiers. This data can be collected and aggregated to reveal patterns of movement or presence, potentially impacting operational security or public trust.

For Researchers and Community:

1. Improve Sniffing Tools: The current state of Bluetooth sniffing tools, particularly for deep data extraction beyond basic advertisements, is underdeveloped compared to Wi-Fi. There's a strong call to action for developers to enhance open-source tools (like Wigle's Android app) to capture and expose more granular Bluetooth data (e.g., 16/128-bit UUIDs, manufacturer-specific data, raw HCI logs).
2. Crowdsource Device Identification: Establishing platforms for crowdsourcing the mapping of unknown Bluetooth device names and UUIDs to specific products and vendors is crucial. This "wiki-like" contribution would help build a comprehensive database for the entire community.
3. Continued Firmware Research: The focus on identifying underlying chips should be complemented by ongoing research into firmware vulnerabilities, ensuring that newly identified susceptible devices can be addressed.

Key Takeaways

• Bluetooth sniffing goals diverge significantly from Wi-Fi, and current sniffing technology is largely underdeveloped to meet these specific needs. While tools like Wigle exist, they often lack the granular data (e.g., specific UUIDs, manufacturer-specific data) required for in-depth security analysis.
• Many Bluetooth devices, even those employing randomization, remain highly trackable due to static identifiers like OUIs, persistent device names, or vendor-specific UUIDs. This pervasive trackability raises significant privacy concerns for individuals and assets.
• Identifying the underlying Bluetooth chip is crucial for assessing firmware-level vulnerabilities. Methods include analyzing OUIs in BD Adders, extracting 16-bit and 128-bit service UUIDs, parsing manufacturer-specific data, and utilizing public resources like the FCC database.
• The widespread deployment of Bluetooth across diverse devices (medical, automotive, IoT) creates a massive, often unaddressed attack surface. Pre-authentication firmware exploits pose a severe risk, demanding greater transparency and security rigor from manufacturers.
• A comprehensive understanding of the full threat model is essential for effective security decisions. A technically "vulnerable" Bluetooth feature might paradoxically represent a security improvement if the existing baseline (e.g., physical keys for heavy equipment) is far weaker.
• Community collaboration and enhanced open-source tools are vital for advancing Bluetooth security research. Crowdsourcing device identification and improving data collection capabilities will enable better mapping of chips to devices and a more informed defense posture.

About the Speaker(s)

Xeno Kovah is the founder of Open Security Training 2 (OST2), a non-profit organization dedicated to providing 100% free, open-access, and open-source classes in security. This initiative is a successor to his earlier hobby project, opensecuritytraining.info, which significantly contributed to the security community. Kovah dedicates approximately 75% of his time to educational philanthropy through OST2, with the remaining 25% spent on consulting and research. He often describes his research efforts as a "Trojan horse" to promote OST2 at conferences. His work, and that of his wife Veronica Kovah, frequently involves discovering and analyzing firmware-level vulnerabilities in various Bluetooth chips and other embedded systems.