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.
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.
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.
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
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.
# psm_scan -o 00:12:34:56:78:9A
scanning, this will take some time...
psm: 0x0001 (00001) status: L2CAP_CS_NO_INFO result: L2CAP_CR_SUCCESS (this is SDP)
psm: 0x0003 (00003) status: L2CAP_CS_NO_INFO result: L2CAP_CR_SUCCESS (this is RFCOMM)
psm: 0x0011 (00017) status: L2CAP_CS_NO_INFO result: L2CAP_CR_SUCCESS (HID ctrl)
psm: 0x0013 (00019) status: L2CAP_CS_NO_INFO result: L2CAP_CR_SUCCESS (HID intr)
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.
# hciconfig hci0 -a
hci0: Type: USB
BD Address: 00:12:34:56:78:9A ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:9847 acl:315 sco:0 events:361 errors:0
TX bytes:5723 acl:316 sco:0 commands:34 errors:0
Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'Bluetooth Keyboard'
Service Classes: Unspecified
Device Class: Audio/Video, Unknown (reserved) minor device class
HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver: 0x20d
Manufacturer: Cambridge Silicon Radio (10)
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.
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
I only did very little testing.
[X] Linux BlueZ before 2.25 (bluez-utils)
hidd (the hid host) is running by default and accepts device connections without authentication
depending on the distribution hidd may not be started by default or is started with secure parameters
[O] Windows SP2 (Microsoft stack)
doesn't run a HID server by default
[?] Windows (Widcomm stack)
Think Outside HID host driver (v4.3), doesn't support server mode and by default outgoing connections request a pin
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 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
xkbd-bthid aka Collin's Bluetooth Keyboard
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 ]-