Publications

Bluetooth vulnerability assessment is still in the dark ages. We still don’t have a good handle on all the devices that are affected by the exploitable-over-the-air vulnerabilities that we disclosed in Texas Instruments and Silicon Labs firmware back in 2020. But we’ve been chipping away at the problem!

We released “Blue2thprinting” in 2023 as our starting point towards something akin to nmap OS fingerprinting, but with a focus on learning what we could about the specific Bluetooth chip or firmware versions, to identify known-vulnerable versions. We delved into the thousands of pages of Bluetooth specs to extract bits and pieces, packets and profiles, that had interesting information to share about what a device is.

But even as we continue to add new types of data to enrich our understanding of what devices are, and whether they’re vulnerable to known CVEs, there’s just so much that’s still unknown! In this talk we’ll discuss the updates to Blue2thprinting to allow for P2P researcher data sharing and crowdsourcing, and how that can help broaden the global knowledge of Bluetooth vulnerability applicability. And we’ll also highlight the ridiculous number of tantalizing known unknowns; and encourage you to join the BlueCrew on our Journey Into Mystery!

If one wants to know (for attack or defense) whether a Bluetooth (BT) device is vulnerable to unauthenticated remote over-the-air exploits, one needs to be able to query what firmware or OS the target is running. Unfortunately there is no universally-available method to get this information across all BT devices. There is also no past work that attempts to rigorously obtain this information. Therefore we have created the “Blue2thprint” project to begin to collect “toothprints” (2thprints) of BT devices, and bring the exciting world of forensic odontology to you!

This research discusses what information is readily available by existing inquiry tools and methods. We show how that information is not what we need, as it has been focused more on tracking individual devices, or on exposing device characteristics, models, and manufacturer information. We will show how some readily-available information is useful for giving partial answers about firmware and OS versions, but how this information is completely inconsistent in its availability or meaning. It turns out many 2thprints are missing teeth!

Thus we’ll show why it is necessary to send custom packets and packet sequences in order to build more robust 2thprints. These custom packets and sequences cannot be created by using existing BT software interfaces. They require utilizing custom firmware on the packet-sending device.

This research will present a new state-of-the-art when it comes to exposing the known, the unknown, and the under-known of BT device identification. And it will show what work remains, before we can approach 100% identification for any random device that shows up in a BT scan.

During the pandemic I took up Bluetooth (BT) sniffing as a way to get out of the house. I didn’t know what was out there for BT devices, but it felt important to know what the implications were of the new over-the-air, no-auth, cross-device, firmware-level exploits on BT chips that my wife and others had started publishing. And because BT Low Energy specifically added anti-tracking functionality that didn’t exist in BT classic, I wanted to understand the in-the-wild state of privacy protection within the BT ecosystem.

Bluedriving left me with questions that are different from those you’d ask based on traditional WiFi wardriving. Is there a correlation between poverty, obesity, and BT sleep apnea medical devices? What are the implications of BT on police body cameras? Are BT sniffers going to be (/ already) used as alternatives to license plate cameras for tracking vehicles? Are fitness trackers still making it easy to track humans instead? Can someone steal heavy-construction equipment thanks to BT keyless ignition? Can hackers be tracked by their “portable multi-tool[s]”? Do hotels using BT door locks “open the door” to easier assassinations?

In this talk I will describe some of the most interesting observations from the past few years, and share some perhaps-surprising answer to those questions and more.

Bluetooth Low Energy (BLE) has seen widespread product adoption and a renewed interest from a security community whose interest in Classic Bluetooth (BT) had waned. Protocols that run “above” the Host Controller Interface (HCI) on the BLE stack are typically handled in full OSes or applications. Vulnerabilities at these layers are plentiful (~70 in Android in 2019) and comparatively well-understood. But for performance and abstraction reasons, protocols below the HCI layer are always handled in firmware running on microprocessors designed for BLE support. Until now, there had been only a single publicly disclosed remote code execution vulnerability in BLE below the HCI layer: CVE-2018-16986, Armis’ BleedingBit. This talk describes my process of going from knowing nothing about Bluetooth, to reverse engineering multiple vendors’ firmwares, and finding remote code execution exploits for multiple new vulnerabilities at the lowest levels of the BLE protocol stack which I will demonstrate. Exploits at this layer are of particular interest because they require neither pairing nor authentication, merely proximity, to exploit.