HID Attack (attacking HID host implementations)

by Collin R. Mulliner collinbetaversion.net

I release this bescause of Thierry's talk at 23c3, also see the article on heise security.

SecurityFocus BugTraqID

Introduction

Bluetooth keyboards and mice take a large percentage of sold Bluetooth devices, most of the high quality wireless desktops now use Bluetooth. All the keyboards, mice, joysticks and drawing tablets use the HID protocol (HID = Human Interface Device). HID is independent from Bluetooth and is also used for USB devices, of course it was used for USB long before Bluetooth even existed. The Bluetooth SIG just specified a small wrapper protocol to transport HID over Bluetooth.

The described attack will basically hijack the system keyboard of a computer.

History

I started using Bluetooth HID devices (Apple Keyboard) in 2003. The HID security research was just started very recently in November 2005, while doing some development on a Bluetooth soft-HID keyboard.

HID Details

This is directed towards keyboards, mice are basically handled equally.

In HID there are two instances: the host (PC, laptop, PDA, cellphone, etc...) and the device (keyboard, mouse, etc...). The two instances are connected through two channels (PSMs) on the Bluetooth L2CAP layer. These are the control and the interrupt channel. The control channel is used for signaling and the interrupt channel is used for data transfer. More details can be found by following the links in the reference section.

In order to use a HID device it needs to be attached to the host in someway, since there are no cables to be plugged the process is a little more complex. Which is very interesting to us.

Attaching a HID device to a host can be done in two ways. The most common way is where the host initiates the connection. Here the host first needs to discover the device, this is done using a specific Bluetooth inquiry scan for HID devices. Now the host needs to discover the type and service profiles of the found HID device. This is done via SDP (Service Discovery Protocol), which is heavily utilized by HID. It specifies trivial things like L2CAP PSMs for the control and interrupt channels and high-level HID features, like number of keys, language sets, etc. A sample dump can be found here.

The second attachment mode is where the device connects to the host. Here the host also queries the devices SDP information.

In both cases the control channel needs to be established before connecting the interrupt channel. Part of the connection process is deciding on the protocol to be used. There are two protocols for keyboards: the boot protocol which is used by Bluetooth aware BIOSs for using Bluetooth keyboards as console input and second the report protocol is a little more complicated and involves stuff like key mapping tables. We will use the boot protocol here.

Attacking Bluetooth HID

Like we said in the introduction we will hijack the console keyboard of a computer or more precise we will introduce a (new) keyboard to the system.

Basically we just utilize the HID host in server mode, the one where the HID host accepts incoming connections from devices. We can also try to do a passive attack and just wait until somebody searches for a Bluetooth keyboard, as soon as we get an incoming connection we take control and inject what ever key press sequence we want.

Howto discover a HID host in server mode? We just need to check for the two HID channel, since the PSMs for HID are standardized we just port scan the target host. Use bt audit, the Bluetooth port scanner suite to do this. The last two ports (PSMs) are the interesting ones. 0x11 (17) is the HID PSM for the control channel and 0x13 (19) is the interrupt channel. As indicated by L2CAP_CR_SUCCESS no security layer is enabled and the connection attempt would be successful. More on the Bluetooth low-level security and HID later.

Now we can just take our own HID device implementation and connect it to the host. This really gives you full control over the computers keyboard input. Of course other keyboards are still working so you don't take total control of the victim's computer.

The same counts for the earlier mentioned passive attack, where we wait until somebody connects to us. For this to happen we need a few modifications of the local Bluetooth interface, so we can mime a Bluetooth HID device. Important settings are: the device and service Class must reflect HID (e.g. 0x002540), the device should not try to become a piconet master (SLAVE), the device must be discoverable and connectable (ISCAN, PSCAN) and the device name should be somehow suggestive to be Bluetooth Keyboard.

For both attack types a valid SDP keyboard record is required, because HID hosts need the configuration information to process the connection and therefore will mostly reject the connection if the record is not available.

These attacks of course only work when the Bluetooth low-level security (mode2/3) is not invoked during connection time (like above). From what I have seen: my guess is that either the connecting host invokes the security mode (PIN request) or that some HID devices require the a secure connection.

In some cases changing the BD_ADDR (Bluetooth MAC address) of the attacking device may help (e.g. to fool proprietary drives that check for a certain vendor). If you want to mime Apple hardware one may want to prefix their new BD_ADDR with 00:0A:95.

Tools

hidattack

hidattack reads /dev/input/event like events from a file. Through this tool one can very easily generate control-sequences like Ctrl-Alt-Del.

hidattack can also listen for incoming connections, to do the passive attack.

Collin's Bluetooth Keyboard

This is a full fledged Bluetooth soft-HID keyboard (this was the main reason for playing with HID). This is a on-screen keyboard based on Matthew Allum's xkbd. I just ripped out XTest stuff and replaced it with my bthid code. This soft-HID keyboard can also be used for both attack types. Since this is a separate project it has it's own website here.

Vulnerable Implementations

I only did very little testing.

[X] Linux BlueZ before 2.25 (bluez-utils)
[O] Windows SP2 (Microsoft stack)
[?] Windows (Widcomm stack)
[?] MacOSX
[O] PocketPC
[?] PalmOS

Threat

The threat potential is high, it basically is like getting physical access to the target system. But the like hood to actually successfully attack a target is low. This is because of multiple reasons. Not many HID hosts implement server mode or at least don't have it switched on all the time. And most of the hosts use secure connections when attaching new HID devices thought outgoing connections.

Also fully automated attacks are hard to do because they are blind. Since you don't have any clues about what application has the keyboard focus, etc. Using hot-key combinations (open start menu or run dialog) can remedy part of this but of course not totally.

The most likely type of attack would be Denial of Service. Where you either flood the input queue or send destructive key-sequences.

Future work

Future work would be, a full audit of the most common HID host implementations. This is the thing that is mostly missing here. Also the interaction with allready paired Bluetooth HID equipment could be interesting.

Downloads

hidattack package
xkbd-bthid aka Collin's Bluetooth Keyboard

References

Bluetooth SIG Specs.
USB HID page
the trifinite group
Bluetooth Device Security Database (btdsd)
xkbd Matthew Allum's xkbd


Version: 1.0, December 29th 2005 (released 31th December 2006)
updated: Wed Jan 17 08:28:31 CET 2007
-[ Home ]-[ Weblog ]-[ Bluetooth ]-[ Windows Mobile ]-[ Symbian ]-[ PalmOS ]-[ J2ME ]-[ Maemo ]-[ Security ]-[ iPhone ]-[ Android ]-[ NFC ]-[ Contact ]-