Discoverability is Not a Mitigating Factor

Four years after BlueSniff: Eve Meets Alice and Bluetooth by Dominic Spill and Andrea Bittau, people are still saying that Bluetooth vulnerabilities can be mitigated by turning off discoverability. If there is one thing that should have been learned from all of the Bluetooth security research done over the last few years, it is that a non-discoverable device is no safer than a discoverable one, but perhaps this message has been buried too deeply in technical presentations. Let me try to make this point clearer.

A discoverable Bluetooth device is one that is willing to respond to an inquiry, a single packet transmitted by any device looking for others. When you tell a device to "find new Bluetooth devices" it transmits a large number of inquiry packets and waits for responses. A discoverable device's inquiry response contains information including the device's address (BD_ADDR). This address can then be used by the inquirer to initiate a connection between the two devices.

Since most Bluetooth vulnerabilities can only be exploited once a connection is established, people used to recommend turning off discoverability. The reasoning was that, without a way to learn the target's address, an attacker would be unable to connect to the target and exploit any vulnerability. This idea that it is possible to keep a Bluetooth device address secret is completely wrong.

Turning off discoverability is like hiding the SSID of an 802.11 network. It prevents people from casually or accidentally connecting to your Bluetooth device. It might be worth doing for this reason alone, but I no longer recommend it as a security practice. Turning off discoverability does nothing to thwart skilled attackers. Worse, it creates a false sense of security and makes it harder for the good guys to notice that Bluetooth devices are in use.

A BD_ADDR is a 48 bit number (it's a MAC address) that is unique to a particular Bluetooth device. It consists of three sections, the 16 bit Non-Significant Address Part (NAP), the 8 bit Upper Address Part (UAP), and the 24 bit Lower Address Part (LAP). In order to connect to a target, an attacker needs only the UAP and LAP.

LAP sniffing is easy. Every Bluetooth packet contains the LAP in cleartext. Spill and Bittau showed how to sniff LAPs with a USRP for about $1000. Now it can be done with an Ubertooth One for about a tenth of that price. It can even be done using Travis Goodspeed's method for promiscuous sniffing with lower cost platforms. LAP sniffing has always been easy, but now the tools and methods are more well known.

The UAP is only slightly more difficult for an attacker to learn. Project Ubertooth and gr-bluetooth include software that implements automatic UAP determination based on passive observation of just a few packets. The function is integrated into the Ubertooth Kismet plugin. Even without this method, it isn't hard to figure out the 8 bit UAP. In Hacking Exposed Wireless, Second Edition, Joshua Wright showed how to determine the UAP with a simple brute force attack.

Turning off discoverable mode doesn't make your Bluetooth device any more secure. If your security model depends on secrecy of the BD_ADDR, you are doing it wrong.

And, by the way, frequency hopping doesn't help you either.