Michael Ossmann gave a really interesting talk on bluetooth keyboard security at ShmooCon. He specifically covered the bluetooth HID profile from 2003 and the bluetooth 1.2 spec from the same time, which all current keyboards on the market implement. He covered many attacks on the system that take advantage of bluetooth not authenticating its devices.

Mike opened by quoting from the February 2003 issue of Bruce Schneier’s Crypto-Gram on the importance of authentication.

Last year I had a conversation with an engineer involved with security for the Bluetooth wireless protocol. I told him that Bluetooth has only privacy and not per-packet authentication. He responded with the prototypical lame responses: 1) pseudorandom frequency hopping makes it “nearly impossible” for an attacker to get in, and 2) the range is only 8 feet, so the attacks are naturally limited.

I tried to argue the point, but eventually gave up. Then I said something like: “I can hardly wait for Bluetooth to become universal, because I really want a wireless keyboard and mouse with the “base station” built into my computer.” He said: “Yes, but you really probably don’t want to use Bluetooth for that, because then somebody could stuff keystrokes or mouse clicks into your system.” I didn’t know whether to laugh or cry. Talk about not getting it.

The bluetooth HID profile is essentially USB HID implemented over bluetooth. The bluetooth dongle has two USB protocols it can use to communicate to the computer either “boot” protocol or “report” protocol. The report protocol is very flexible to suit whatever the device needs. The “boot” protocol on the other hand is fixed. The boot protocol is designed this way because it’s in the computer BIOS which allows the keyboard to be used at boot time without needing a full USB stack. Many dongles default to this boot protocol when plugged in and just enumerate as a mouse and keyboard instead of a full bluetooth host (which you can later switch to in software).

Mike developed the btbb plugin for WireShark which lets you look at bluetooth baseband packets captured over the air with the USRP software radio. While working on it he noticed the keystrokes were being sent in the clear. He sent a few captures to Joshua Wright who used them to develop btaptap which takes a pcap file and spits out the keystrokes. The dongle they were captured from was in boot mode, but just being in boot mode doesn’t guarantee they’re sent in the clear. Some computers with bluetooth now ship with boot mode as the default.

The next thing Mike talked about was HID Attack by Collin Mulliner. Collin developed xkbd-bthid as a virtual bluetooth keyboard to send keystrokes to bluetooth devices. It was designed to hunt down machines that were waiting for keyboards to connect. Most of these holes have been patched now. Mike demoed injecting mouse commands by using a dongle on the victim’s machine while the mouse was turned off. The interesting part of the demo was that he injected keystrokes using the mouse since it’s the same HID boot protocol. Support for encryption in mice isn’t required by the USB HID spec only for keyboards.

To do the spoof, you have to know the BD_ADDR of the device you’re spoofing. If you have physical access, you could just read it off of the device or OS. Kismet now ships with kismet-btscan for actively sending inquiries to recover the BD_ADDR of local devices. kismet-bluetooth is also being developed to passively monitor the baseband using the USRP.

When bluetooth devices are using encryption there’s a link key that you must crack. Much research has been done on this with BT Crack by Thierry Zoller and btpincrack by David Hulton. They work but require a lot of time and usually capturing the actual device pairing. Mike suggested in jest that all pairing should be done inside of a Faraday cage.

bthidproxy is yet another handy piece of software. Using it you can man in the middle bluetooth connections by using two dongles and spoofing the host and device addresses. Because of ‘virtual cabling’, a one to one connection is made between device and host. This means that almost all attacks must be performed when either the device or host are off allowing you to take their place. This isn’t too much of a problem since machines get powered down often and many mice have off switches to save battery.

Mike talked about K Chen’s Apple Keyboard firmware attack. The USB keyboard doesn’t check the firmware’s signature so it can be rewritten. Bluetooth HID is USB over bluetooth, so Mike decided to see if the same thing was possible. He was able to modify the firmware on his Apple bluetooth keyboard by sending it packets over the air. His keyboard is the older three battery version which required the link key to be used, but he said that the newer two battery version doesn’t have this protection.

It was a great presentation and Mike has the slides and additional resources on his site. He even includes a checklist for verifying how secure your bluetooth devices are. The link key puts most attacks out of reach of your average hacker, but as he pointed out it is often not implemented. For future work, he plans on developing baseband injection using the USRP.