Publications

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.