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. 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. # 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' Class: 0x002450 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. 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) 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) [?] MacOSX [O] PocketPC Think Outside HID host driver (v4.3), doesn't support server mode and by default outgoing connections request a pin [?] 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.