Bad USB - The Exploit from an Attack Surface

Based on the work completed by [1], following is my summary and review on the USB style exploit based on attack surface. I completed these notes as part of work in Oxford University and towards GCHQ accreditation. All comments are my own.

The exploit presented by BadUSB can be classified as a modification attack, in this case the authors are able to manipulate and influence the firmware associated with the USB devices microcontroller chip as such is an increased modification surface of the implementation i.e. the design specification did not intend for this ability. As noted previously, this exploit leverages two main concepts, the inability to determine the number of physical USB devices currently attached and secondly a USB device can re-register at any point as another device class / function. Authors reviewed the update firmware process, reverse engineered the firmware, and determined an ability to inject their own code into empty space within existing firmware files. This means once authors were able to reverse engineer the firmware and inject their own code they could patch the USB device, and re-purpose the USB device for malicious means. Attempts from anti-malware programs are ineffective as the firmware files are not accessible to the anti-malware programs; and if they are it would be conceivable the malicious patched firmware could present different files to the anti malware program.

With USB device's the attack surface has significantly grown with respect to assets i.e. the coverage of USB device function / classes has significantly grown since USB v1.0, January 1996 [2] initial inception. However from the initial specification, this specification outlines the motivations for USB v 1, connection of PC to telephone, ease of use and port expansion. While the description of the devices seem somewhat outdated for todays device terminology, e.g. answering machines, FAX, telephone, PDA etc. In general the use cases remain the same and the description of the motivation is pretty much accurate if you replace the terminology with todays terminology; while the motivations for USB still remain valid. The attack surface has grown but this is due to the extreme success of the USB technology and its uptake. This certainly increases the attack surface from the perspective of additional hardware components. Also mentioned in the original specification the target audience includes independent software vendors (ISV), independent hardware vendors (IHV), system original equipment manufacturers (OEMs) etc., effectively the target audience is any software or hardware vendor. Effectively the point is the original specification was very much targeting dominance for peripheral devices.

Both threat modeling and security are not defined in anyway as part of the specification; searching [2] for following keywords 'security' returns zero, 'threat model' returns zero, while the search term 'model' returns forty two none of which relate to security. Suggesting security and threat modeling for USB devices is delegated to either OS vendor or the ISV/HSV, as [3] has highlighted the responsibility for mitigation for BadUSB remains unclear, no response from chip vendors, peripheral vendors nor any response from OS vendors.

The flexibility, versatility and open architecture of the USB design is its main disadvantage from an attack surface and exploitable perspective. As noted previously the specifications flexibility allows any USB device register and re-register. Two issues can immediately be highlighted, first 'any' device can be attached, meaning no whitelist of devices are defined, and second, devices can re-register. Granted whitelisting device function / classes is not an objective of the specification and in-fact when listing devices; [2] mentions "keyboard/mouse/joysticks interfaces etc." i.e. the objective is for any device, therefore the attack surface increases naturally over time, devices are therefore limited to the imagination of ISVs, HSVs, OEM's etc. While we have seen valid use cases for this re-registering ability (i.e. CD-Rom and then 3G modem), it is not difficult to imagine where re-registering could be exploitable i.e. is their a valid use case for a device to register as a mass storage device and then re-register as a keyboard? This raises a question as to what class of USB device can re-register as a second class? In addition as noted previously the lack of any reliable unique serial number extends the attack surface not all USB classes mandate a serial number, the fact its optional to deregister makes it difficult for a computer to know how many physical devices are attached again makes the attack surface difficult to define i.e. how many physical devices are attached to the computer? As noted previously no defense mechanism has been built into the USB design protocol for when a USB micro controller chip firmware is compromised.

[1] Bad USB Blackhat presentation

[2] USB Revision History 1.0 January 15th, 1996

[3] Karsten Nohl, Sascha Kribler, Jakob Lel

[3] YouTube Presentation, Karsten Nohl, Sascha Kribler et al.