BadUSB Uncovered
The recent demonstration at Black Hat 2014 of BadUSB, a security vulnerability that surfaces when using the USB interface, is a hot topic in the international press. But the topic that the international press hasn’t covered is what is really behind a BadUSB attack and how does it work?
Every USB flash drive consists of a controller chip and at least one memory module. The controller is in charge of the communication with the computer via the USB interface and manages the memory module. In principle, a USB flash drive can be thought of as a microcomputer that, upon being plugged in, boots its operating system (the firmware) from a non-visible part of the flash memory. Then the USB stick sets its flash memory as an available drive.
For economic reasons, the firmware in USB flash drives is designed so that it can be updated. There are two possible ways to update the firmware: a safer method with secure boot, and a simpler one relying on the obfuscation of undocumented commands. The latter method applies in general to all classic USB sticks and is the method vulnerable to BadUSB.
The first step of a BadUSB attack is the manipulation of the firmware in the USB stick. To accomplish this, it is first necessary to reverse-engineer the firmware and develop new custom firmware for a particular controller. The cracker will also need to circumvent the obfuscation of the firmware update process in order to load the new firmware onto the USB stick.
At this point, it is important to note that a hack is controller-specific and would not generically apply to any USB device. The malicious effort must be repeated for each device embedding a different controller. According to reports, most of the attacked USB flash drives use a controller chip from Phison. The attack is reported to have taken extensive effort in reverse engineering and manipulating the firmware of Phison’s controller. This immediately begs questions about the cost-benefit ratio for crackers.
The second step of a BadUSB attack is that the USB stick with the modified firmware is connected to a computer and presents itself as a human interface device (HID), specifically a keyboard, to the computer. The computer detects the new keyboard and initializes it automatically – an action for which a normal user doesn’t usually get suspicious and is commonly not prohibited by the operating system. After sending a command string such as <WIN>+r <ENTER> cmd <ENTER>, this "keyboard" can then load malware from the Internet and run it from the opened console window. Since any installed virus scanner will immediately check the downloaded malware, it is just a matter of time before most of the attack patterns are detected and prevented.
A BadUSB attack can be successfully accomplished only with logged-in users who have administrator privileges to their computer. In principle, the attack would also work for OS X and Linux; only the actual commands from the “keyboard” would be different.
The basics for this attack were previously announced at Black Hat 2005 under the title "Plug and Root - the USB Key to the Kingdom." To this day, there is no known evidence of a comprehensive and successful attack of this kind. Over the last nine years, the issue has been extensively covered by the security community. Nevertheless, measures aimed at protecting both the operating system and the processes, such as secure boot, should be implemented in the near future.
Implications for Wibu-Systems’ hardware
The attack reported by the press has no significance for WibuKey or CodeMeter, even if the entire source code of the attack was published.
WibuKey
WibuKey uses a smart card controller and signed firmware. Only firmware signed by Wibu-Systems can be downloaded into the controller. A BadUSB attack is not possible.
CmStick, CmStick/C, CmStick/I, CmStick/IV
The CmStick uses a smart card controller without flash memory and with signed firmware. Only firmware signed by Wibu-Systems can be downloaded into the controller. A BadUSB attack is not possible.
CmCard/SD, CmCard/CF, CmCard/µSD, CmCard/CFast
These devices cannot be identified as HID units since they do not use a USB interface. A BadUSB attack is not possible.
CmStick/M (pre-2014)
Although the stick comes with flash memory, CmSticks/M are not affected. The stick uses a custom controller for which a similar attack is not known at present. A future attack is thus unlikely due to the extreme effort required.
CmStick/M (2014)
Beginning in 2014, Wibu-Systems revolutionized the already high security level of CmStick/M. The firmware of all the chips used is encrypted and signed. The root key is stored in read-only memory (ROM). The root key can be written once only during manufacturing and cannot be subsequently changed in the field under any circumstances. The root key becomes therefore the anchor for a complete secure boot process that relies on the stick. The inter-chip communication is also encrypted to make future attacks on the hardware impossible. This version of CmStick/M is thus immune to firmware attacks such as BadUSB and to any similar attacks that should arise in the future.
The BadUSB attack is a completely independent activity with no effect to the protection offered by CodeMeter, which is implemented on a separate chip that has its own memory and a cryptographically secure firmware.
A key finding of the recent Black Hat presentation is that secure boot is essential even for the smallest of devices.