Lowering the USB Fuzzing Barrier by Transparent Two-Way Emulation

Rijnard van Tonder Herman Engelbrecht

[email protected] [email protected]
MIH Media Lab, Stellenbosch University MIH Media Lab, Stellenbosch University

Abstract which enables the injection of input into the USB chan-
Increased focus on the Universal Serial Bus (USB) at- nel [8]. One such piece of hardware, the Facedancer [2],
tack surface of devices has recently resulted in a number is a bespoke USB testing device that emulates a USB
of new vulnerabilities. Much of this advance has been device with the aid of software. This approach lends it-
aided by the advent of hardware-based USB emulation self well to finding bugs throughout the USB software
techniques. However, existing tools and methods are far stack, including core drivers, third-party drivers, and ap-
from ideal, requiring a significant investment of time, plication software which handle USB data. Dedicated
money, and effort. In this work, we present a USB test- USB equipment, such as USB analyzers, are arguably
ing framework that improves significantly over existing the most effective for this task, but often prove to be pro-
methods in providing a cost-effective and flexible way to hibitively expensive. Other viable approaches for test-
read and modify USB communication. Amongst other ing specific USB software without the use of hardware
benefits, the framework enables man-in-the-middle fuzz have also been demonstrated [6]. Here, fuzz testing (or
testing between a host and peripheral. We achieve this fuzzing) is made possible by emulating the presence of
by performing two-way emulation using inexpensive USB devices in a guest operating system. Unfortunately,
bespoke USB testing hardware, thereby delivering capa- this carries the limitation that USB software has to func-
bilities of a USB analyzer at a tenth of the cost. Mutation tion within the constraints of the virtual operating sys-
fuzzing is applied during live communication between a tem. Because the USB protocol interacts closely with
host and peripheral, yielding new security-relevant bugs. hardware devices, this makes it difficult to achieve full
Lastly, we comment on the potential of the framework USB functionality.
to improve current exploitation techniques on the USB We therefore argue that a hardware-based approach
channel. should be preferred when exploring the USB attack
surface. The cost-effectiveness and flexibility of a
Keywords: USB, emulation, fuzzing, man-in-the- hardware-based approach, however, affect our ability to
middle explore it efficiently. In practice, it is difficult to achieve
both these goals with currently available solutions, which
1 Introduction are discussed in depth in Section 5.
This paper presents a novel approach for finding bugs
Exploration of the USB attack surface has drawn in USB software that is both cost-effective and highly
attention among security researchers as far back as flexible. The goal of the design is to allow one to tap
2005 [7], and while USB bugs and exploits have been into USB communication between a host and peripheral
sporadically reported since 2009 [14], it is only in the device. The data should not only be readable (affording
last two years that considerable headway has been made. functionality analogous to a bus-pirate device), but also
This is evidenced by a slew of new vulnerability reports modifiable, as typically made possible by a USB ana-
in 2013, registering far more USB security advisories lyzer. Moreover, this is achieved with two bespoke USB
than previous years combined.1 These bugs are exhib- emulation devices which establish two-way communica-
ited mostly in USB drivers of operating systems, and of- tion that is transparent to the host and peripheral. The at-
ten lead to memory corruption vulnerabilities. tributes of the Transparent Two-Way Emulation (TTWE)
Perhaps the primary reason for the discovery of re- framework thus enable us to perform man-in-the-middle
cent bugs is the maturity of cost-effective USB hardware fuzzing. Beyond supplying USB analyzer capabilities at

1
a tenth of the cost, the framework also allows full control 2.1 Requests and Descriptors
over the software that handles USB communication, un-
like traditional bundled USB analyzer software. While The USB specification defines eleven standard
the framework makes use of affordable hardware, it is requests. A request from the host, such as
a hybrid approach, and relies on a software component. get descriptor, expects to receive a descriptor
This software component enables the desired flexibility from the peripheral, while other requests such as
and efficiency when exploring the USB attack surface, set address require the peripheral to perform an ac-
since its role is to transparently mediate USB communi- tion. The peripheral responds with descriptors of varying
cation between a host and peripheral. types, containing the respective information. Requests
In this paper we discuss the architecture of the frame- and descriptors allow the USB host to learn about the ca-
work, demonstrate the practical application thereof, and pabilities of the peripheral, and are also used to load the
show that it is effective at finding USB bugs that may appropriate software driver.
have security implications. The contributions of this The USB specification defines eleven standard de-
work in particular are: scriptor types, including device, configuration, and end-
point descriptors. Other descriptors may exist, like the
1. A USB testing framework that Human Interface Device (HID) descriptor for keyboards
(a) Is flexible, by allowing man-in-the-middle and other input devices. A complete listing of requests
modification of USB host/peripheral commu- and descriptors are available in the USB Device Working
nication through software, Group documentation [5].
(b) Is cost-effective in affording USB analyzer
functionality by combining two inexpensive 2.2 Endpoints
USB controllers, and
USB endpoints provide a way for the host and periph-
(c) Lowers the knowledge requirement for USB
eral to agree on the direction and address for a given
testing by exposing existing host/device com-
transfer. The address is a number between 0 and 15. End-
munication; no prior knowledge of the USB
point 0 is a special address; it is a bi-directional endpoint
protocol is required to test (or fuzz) software.
that is used during control transfers (see Section 2.3 be-
2. Bug-finding results and analysis, for which we de- low). All USB devices must support communication on
liver an interpretation of the effectiveness in finding endpoint 0. Control transfers require bi-directional com-
bugs using this approach. munication between host and peripheral, and therefore
endpoint 0 uses both an IN and OUT direction. Endpoints
3. Enhanced USB testing methods where we suggest
for non-control transfers carry data that is particular to
further applications that the TTWE framework af-
the peripheral. These endpoints, numbered 1 through 15,
fords, such as cataloging USB host/peripheral re-
are unidirectional; an endpoint can either support an IN
sponses.
or an OUT direction, but not both. If bi-directional com-
As a departure point for discussing the framework ar- munication is required outside of endpoint 0, then sep-
chitecture, an overview of the USB protocol is provided arate endpoints are needed. For example, a USB mass-
in Section 2. We proceed by discussing the architecture storage device may designate in its endpoint descriptor
in depth, and the necessary logic for achieving the test- that it will use endpoint 1 with an IN direction, and end-
ing framework in Section 3. This is followed by our bug- point 2 with an OUT direction.
finding results in Section 4 and an analysis of the frame- Endpoint directions are always specified from the per-
work in Section 5. Finally, we discuss related work and spective of the host. Furthermore, endpoint addresses are
conclude in Sections 6 and 7, respectively. always defined by the peripheral’s USB controller.

2 Background 2.3 Transfer types

This section aims to give a high-level overview of the Four USB transfer types exist: control, bulk, interrupt,
USB specification so that the framework implementation and isochronous. Transfer types are used for different
can be understood. In particular, the USB specification purposes; in this paper, we distinguish simply between
makes use of varying transfer types; transfers contain re- control and non-control transfers. Control transfers es-
quests, descriptors, or data which are sent over endpoints tablish initial communication between a host and periph-
to facilitate communication between a host and periph- eral, whereas non-control transfers typically carry data
eral. We explain these in turn before considering the de- specific to peripheral functionality. For instance, a mass-
sign of the framework. storage USB device would transfer file data using a bulk

2
transfer, and a keyboard would transfer keystrokes using 3 Framework Architecture
an interrupt transfer. In both instances, these peripherals
would first establish basic communication with control We remind the reader that the goal of the framework
transfers. is to allow one to tap into USB communication between
a host and peripheral device in order to read and modify
2.3.1 Control transfers the data being transferred. In this section we consider a
conceptual overview of the framework, proceeded by the
Control transfers constitute the means by which a host hardware and software requirements to achieve effective
learns about the peripheral attached to it. Control trans- operation.
fers comprise requests and descriptors as discussed in
Section 2.1. The host enumerates the peripheral by send-
ing requests, and the peripheral responds either with data 3.1 Design
(in a descriptor) or by performing an appropriate action.
Control transfers only take place over endpoint 0. Once With the aid of two bespoke hardware testing de-
enumeration over endpoint 0 is complete, the host and vices, namely, two Facedancer devices [2], we are able
peripheral can start exchanging data over non-control to expose USB communication to a Mediating Computer
endpoints. (MC) with a man-in-the-middle strategy. These devices
Control transfers have additional structure in the form are essentially USB controllers that can act as either a
of stages: setup, data, and status stages. Depending on USB host or device; detail of their hardware is given in
the request, different stages take place. For instance, 3.2. On its own, the Facedancer device can perform USB
a peripheral will respond with a descriptor in the data host or device emulation via software driven commands
stage in response to a get descriptor request. In a from a computer.
set address request, however, there is no data stage, In our design, and with reference to Figure 1, we
and the peripheral will only respond with a status stage, place one Facedancer in Peripheral Emulation Mode to
indicating whether it was successful (ACK), is still busy interact with a USB HOST, and a second Facedancer act-
(NAK), or failed (STALL). In Section 3.2 we consider how ing in Host Emulation Mode to interact with a USB
these considerations play a role in the implementation of PERIPHERAL. By monitoring the hardware interrupts
the framework. triggered on the Facedancer USB controllers, the MC is
able to mediate communication by forwarding requests
2.3.2 Non-control transfers from the HOST, and responses from the PERIPHERAL.
The HOST is under the impression that it is communi-
Non-control transfers (bulk, interrupt, and
cating with an authentic USB peripheral, but in fact it
isochronous transfers) take place after the host has
is an emulated USB peripheral whose responses are pre-
enumerated the peripheral. In summary, bulk transfers
cisely that of the authentic USB PERIPHERAL monitored
are used for large, time-insensitive data, isochronous for
by the Facedancer in Host Emulation Mode. Similarly,
time-critical, real-time data, and interrupt transfers for
the PERIPHERAL device is under the impression that it is
periodic, low-bandwidth data. On most USB controller
communicating with an authentic host, whose requests
chips, bulk and interrupt transfers are treated the same;
are in fact emulated by continuously monitoring the au-
it is up to the host to signal when data is to be sent or
thentic HOST using the Facedancer in Peripheral Emula-
received. Furthermore, non-control transfers may rely on
tion Mode.
additional, peripheral-specific protocols. One example
includes mass-storage devices that commonly use the The MC monitors the host by checking whether the
SCSI (Small Computer System Interface) protocol. Facedancer has received host requests or data, and also
Some examples of data that is sent using non-control forwards device responses to the host via the Facedancer.
transfers are provided in the table below. This operation is performed by a USB client driver on the
MC. In likewise manner, a USB Host driver monitors the
Peripheral Type Action Transfer Type Facedancer, and forwards host requests. The USB client
Keyboard Key presses Interrupt and host driver exchange data via named pipes on the
Mouse Navigation and clicks Interrupt MC—this allows the USB data to be exposed and manip-
Mass-storage File operations Bulk ulated by any intermediary software, such as a mutation
Printer File transfer Bulk fuzzer, before the data continues on its normal course.
Microphone Audio recording Isochronous Whereas understanding the design is straightforward,
Speaker Audio playback Isochronous there are a number of caveats which present themselves
when implementing the framework; we address these in
the next section.

3
 ever, any device with similar functionality can serve
HOST as a substitute; the framework is not specific to the
Facedancer. For this reason, we briefly mention the ma-
jor hardware components that bring about the required
functionality.3
EP1OUT EP0 EP3IN As shown in Figure 2, the main hardware components
of the Facedancer are an FTDI USB/serial adapter chip,
a 16-bit microcontroller, and a MAX3421E USB con-
troller chip. USB emulation can be performed by send-
Facedancer
(Peripheral Emulation Mode)
ing software-driven USB data and commands to the mi-
crocontroller via the FTDI adapter. The microcontroller
USB Peripheral drives the USB controller, which may be placed in either
Controller
Interrupts host or peripheral mode by toggling a mode bit in one of
USB Peripheral the controller registers. Recall that in Figure 1, we place
Emulation Driver one Facedancer’s USB controller in host mode, and the
Mediating other in peripheral mode. The microcontroller listens for
Computer Named pipes responses from the USB controller, which are in turn for-
(MC) warded back to the computer driving emulation. Basic
USB Host firmware is required for the microcontroller to perform
USB Host Emulation Driver these actions; such firmware is readily available for the
Controller Facedancer components [1].
Interrupts

Facedancer Target
(Host Emulation Mode)
USB
controller

EP2OUT EP0 EP1IN

16-bit
Microcontroller

PERIPHERAL

Figure 1: The TTWE Framework Architecture FTDI USB/serial

adapter

3.2 Implementation MC

The design addresses the conceptual way in which we Figure 2: The Facedancer hardware design for perform-
are able to mediate and tap into USB communication. ing USB device emulation
There are, however, aspects of the USB protocol that
do not translate readily to the framework design. These
aspects include a) endpoint address numbering, and b)
USB handshaking that pertain to control transfers with- 3.2.2 Software
out data stages. In this section we discuss the hardware The USB host and client drivers monitor the respective
and software requirements of the framework, and further- USB controller interrupts to determine when data can
more emphasize the role of software in overcoming the be sent and received. The drivers process the endpoint
caveats mentioned. source and destination of data once it is available, and
this data is sent between the drivers on dedicated named
3.2.1 Hardware pipes. Another important responsibility of the software
is handling special cases of the USB protocol. Problems
The functionality of the Facedancer device is cen- that arise due to endpoint numbering are addressed by
tral to the operation of the framework. Currently, the an endpoint hijacking approach. Complications in USB
Facedancer is an affordable device 2 with attractive USB handshaking are handled by emulating certain aspects of
testing abilities for the purposes of our framework. How- the handshake procedure.

4
Endpoint Hijacking When a host receives an end- not have a data stage. These control transfers include
point descriptor from a device in response to a set address, set configuration, set interface,
get configuration request, it is informed of the end- and clear feature requests. Because these transfers
point address(es) that the device intends to use for non- do not have a data stage, the peripheral would simply
control transfers. For example, consider the USB device respond with a status packet, such as an ACK. The frame-
in Figure 1 (depicted as a mass-storage stick), which re- work makes provision for mediating data transfers across
quires a bulk IN endpoint with address 1, and a bulk OUT the pipes, but for status packets, one of two work-around
endpoint with address 2. Recall from Section 2.2 that the solutions is required:
direction is always from the perspective of the host, but
the endpoint addresses, directions, and transfer types are 1. After forwarding the host request, blindly acknowl-
specified in an endpoint descriptor which are fixed by the edge it with the peripheral emulator, without know-
peripheral’s USB controller, ing the authentic peripheral’s status result.
When the MAX3421E USB controller operates in 2. Communicate the authentic peripheral’s status re-
Host Emulation Mode, it is able to send and receive on sult once available. This requires extra logic so that
any endpoint number. However, when the MAX3421E custom status messages can be communicated be-
USB controller of the Facedancer in Figure 2 is operated tween emulator drivers.
in Peripheral Emulation Mode, its endpoint capabilities
are fixed in hardware, and cannot be changed. These ca- We opted for the former approach. This allows us to
pabilities are as follows: asynchronously ACK requests, and assume that the re-
quest will be successfully processed by the authentic pe-
Endpoint Address Direction Transfer Type
ripheral. This poses the question, what if the request is
EP0 IN/OUT Control
not processed successfully, and the authentic peripheral
EP1 OUT Non-control
EP2 IN Non-control
responds with something other than an ACK? In such an
EP3 IN Non-control event, subsequent requests from the host would not re-
ceive a response, and the breakdown of communication
Consider that an authentic USB peripheral may have would become apparent on the host and client driver soft-
different endpoint capabilities, which are also fixed. It is ware. During testing, we observed this communication
thus possible that endpoint addresses can be mismatched breakdown when we neglected to blindly ACK the afore-
between the emulated peripheral’s USB controller and mentioned requests. After doing so, we did not encounter
the authentic USB peripheral’s. In our case, the USB the scenario again in obtaining the results of Section 4,
controller supports only an OUT direction on EP1, yet so the approach proved sufficient for such purposes.
the authentic peripheral specifies that it must use EP1
with an IN direction. To overcome this problem, we 4 Results
“hijack” and modify the endpoint descriptor with the
MC. When the MC detects an endpoint descriptor be- In this section we discuss the preliminary results of
ing sent from the authentic peripheral in response to a our framework in exposing USB communication, as well
get endpoint descriptor from the host, it creates a as USB testing and fuzzing. The first significant result
new mapping whereby everything received on EP1IN of is the ability to expose USB communication between an
the USB host emulator will be sent on EP3IN of the USB authentic host and device, enabling man-in-the-middle
peripheral emulator. Similarly, a mapping is created for attacks without requiring prior knowledge of the USB
the EP2OUT/EP1OUT pipe. protocol. The second significant result is the discovery
With the endpoint mapping in place, the authentic host of new bugs in USB software. Due to the recent imple-
and device can continue communication on the perceived mentation of our USB framework, a limited time of ap-
information pipes. Since the USB specification does not proximately one week was spent fuzzing various hosts.
mandate the capabilities of endpoints other than endpoint Despite this brief period of dedicated testing, we discov-
0, the nature of the endpoint addressing scheme in our ered security-relevant bugs. As vulnerability disclosure
framework is thus obscured from the host and device, is still being coordinated at the time of writing, critical
allowing a transparent data channel. With this scheme details have been omitted.
we can cope with any manner of endpoint addressing that
a peripheral may require, provided the USB controller
supports the same number of endpoints. 4.1 USB Enumeration & Functionality
Device Enumeration We have been able to success-
Emulating Handshaking A further consideration in fully mediate communication between host and periph-
our framework concerns USB control transfers which do eral pairs, allowing the host to fully enumerate a vari-

5
ety of USB peripheral classes. These include the USB achieve functionality in this fashion by writing additional
HID, mass-storage, printer, and imaging device classes. software for the Facedancer that handles, for example,
Because of the generic manner in which enumeration is the granularity of bulk transfers in 512-byte blocks. If
performed, we expect most device classes to work with we wanted to support HID functionality, it would require
this framework in a plug-and-play manner. writing additional software that simply monitors the in-
terrupt endpoints on the Facedancer. Thus, achieving de-
Device Functionality USB mass-storage functionality vice functionality after enumeration may require addi-
can be achieved successfully after device enumeration tional code, but fortunately this is a software restriction,
takes place. This means that we can perform mount, not a hardware one. Furthermore, this additional imple-
browse, read, and write actions on the mass-storage de- mentation in software pertains only to endpoint types,
vice from the host while tapping into USB communi- and is not device or vendor specific.
cation. Consider Table 1 which presents mass-storage
functionality by Two-Way Emulation on a Linux host. 4.2 USB Fuzzing
The orange row indicates the peripheral’s endpoint de-
scriptor, sent in the IN direction (DIR) on endpoint (EP) USB Printer Driver We discovered a bug in a pop-
0. The bold values 1 and 130 are the endpoint addresses ular operating system’s core USB printer driver, which
that are to be hijacked and modified on the fly. The end- causes a kernel panic and system crash. Analysis of
point address corresponds to the lower nibble of the hex- the crash dump revealed that this is due to an arbitrary
adecimal representation of these values: 1h and 2h re- memory read, resulting after heap corruption on the host.
spectively, with direction specified in the most signifi- At present this bug causes a denial-of-service, but it
cant bit (0h, or OUT, and 1h, or IN respectively). The may also allow arbitrary code execution. The bug was
subsequent yellow rows indicate the start of SCSI data found by rudimentary fuzzing techniques—bytes were
transmitting on the desired endpoints EP1OUT and EP3IN randomly mutated in flight during USB device enumera-
after enumeration. Finally, the green row indicates a tion. Initially, the bug was found by using a real printer;
set configuration request by the host in the OUT di- this was important since the host issued different requests
rection; here, the host would receive a blind ACK, and the depending on the printer’s malformed responses. In par-
request is forwarded to the mass-storage device. ticular, the bug is only triggered in response to a host
request for a specific string descriptor. After inducing a
DIR
OUT
EP
[0]
DATA (Base 10)
[128, 6, 0, 1, 0, 0, 64, 0]
system crash on the host, we could analyze the printer
IN [0] [18, 1, 0, 2, 0, 0, 0, 64, 143, 5, 135, 99, 2, 1, 1, 2, 3, 1] response and replay it, this time using only peripheral
OUT [0] [0, 5, 25, 0, 0, 0, 0, 0]
OUT [0] [128, 6, 0, 1, 0, 0, 18, 0] emulation.
IN [0] [18, 1, 0, 2, 0, 0, 0, 64, 143, 5, 135, 99, 2, 1, 1, 2, 3, 1]
OUT [0] [128, 6, 0, 6, 0, 0, 10, 0]
IN [0] [10, 6, 0, 2, 0, 0, 0, 64, 1, 0]
OUT [0] [128, 6, 0, 2, 0, 0, 9, 0]
USB Host Printer denial-of-service Another bug was
IN [0] [9, 2, 32, 0, 1, 1, 0, 128, 100] discovered in a popular operating system which would
OUT [0] [128, 6, 0, 2, 0, 0, 32, 0]
IN [0] [9, 2, 32, 0, 1, 1, 0, 128, 100, 9, 4, 0, 0, 2, 8, 6, 80, 0, 7, cause an application to hang as soon as the user attempts
5, 1, 2, 64, 0, 0, 7, 5, 130, 2, 64, 0, 0]
OUT [0] [128, 6, 0, 3, 0, 0, 255, 0]
to print something. This was not specific to any appli-
IN [0] [4, 3, 9, 4] cation, and would occur in word-processing programs,
OUT [0] [128, 6, 2, 3, 9, 4, 255, 0]
IN [0] [26, 3, 77, 0, 97, 0, 115, 0, 115, 0, 32, 0, 83, 0, 116, 0, 111, browsers, editors, and so forth. We could thus envision
0, 114, 0, 97, 0, 103, 0, 101, 0]
OUT [0] [128, 6, 1, 3, 9, 4, 255, 0] a scenario where an attacker may use a malicious USB
IN [0] [16, 3, 71, 0, 101, 0, 110, 0, 101, 0, 114, 0, 105, 0, 99, 0] device to perform a denial-of-service attack on a locally
OUT [0] [128, 6, 3, 3, 9, 4, 255, 0]
IN [0] [18, 3, 49, 0, 57, 0, 54, 0, 50, 0, 51, 0, 55, 0, 51, 0, 54, 0] accessible computer. As long as the device remained in
OUT [0] [0, 9, 1, 0, 0, 0, 0, 0]
OUT [0] [161, 254, 0, 0, 0, 0, 1, 0] the computer, the user would need to forcibly terminate
IN [0] [0]
OUT [1] [85, 83, 66, 67, 1, 0, 0, 0, 36, 0, 0, 0, 128, 0, 6, 18, 0, 0, 0,
the application from which they attempted to print. It
36, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] was found that this bug was a result of the host waiting
IN [3] [0, 128, 4, 2, 31, 0, 0, 0, 71, 101, 110, 101, 114, 105, 99, 32,
70, 108, 97, 115, 104, 32, 68, 105, 115, 107, 32, 32, 32, 32, 32, in a busy-loop for certain USB ACK responses from the
32, 56, 46, 48, 55]
IN [3] [85, 83, 66, 83, 1, 0, 0, 0, 0, 0, 0, 0, 0]
peripheral. Again, this bug was found with the aid of a
OUT [1] [85, 83, 66, 67, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 6, 0, 0, 0, 0, 0, real printer. After discovering the cause, we could re-
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
IN [3] [85, 83, 66, 83, 2, 0, 0, 0, 0, 0, 0, 0, 1] produce the attack by replaying it using pure emulation.
OUT [1] [85, 83, 66, 67, 3, 0, 0, 0, 18, 0, 0, 0, 128, 0, 6, 3, 0, 0, 0,
18, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] As before, the bug was triggered by refraining from re-
... ... ... sponding to a specific host request.
Table 1: Mass-storage device functionality by TTWE on a Linux Host
USB Host Printer denial-of-service A certain printer
Other communication in this table corresponds to stan- which supports printing from a USB mass-storage de-
dard USB enumeration behavior. We were able to vice was found to contain a bug which causes the printer

6
to crash. By using a real USB mass-storage device and requests. For rudimentary fuzzing purposes, our solution
fuzzing the printer host, the bug is triggered by a mal- requires very little knowledge about the underlying
formed SCSI response. As with previous bugs, we were protocol, since the Facedancers simply relay device
able to replay the responses so that the printer could be responses. By exposing the raw communication, users
crashed at will. are able to capture, modify, and replay data between host
and device.
5 Analysis
Limitations There is a notable delay in USB com-
Preliminary results indicate that our framework is ef- munication between the host and peripheral due to the
fective, having detected novel bugs that would otherwise emulation devices. Currently, the average delay be-
require much more effort to find using traditional emu- tween USB control transfers is 300 milliseconds, grant-
lation techniques. There are a number of improvements ing enough time to perform USB enumeration in our
that the framework delivers over traditional solutions. setup. However, it was found that general mass-storage
actions, as discussed in Section 4, take an extended
Flexibility While the framework allows platform- amount of time. For example, it may take a few min-
independent man-in-the-middle attacks on the USB pro- utes to mount a mass-storage device, or list its contents.
tocol, this important feature is also possible with a USB This delayed behavior can therefore impact the speed of
analyzer [4]. However, Davis [9] mentions the limita- fuzzing throughput on certain aspects of USB code.
tions of the software provided with the tools: they lack One way to address the delay in communication
a proper software API, requiring the user to make use of may be to optimize the interrupt handling code in the
a custom scripting language [10]. Our framework does Facedancer client and host drivers. Currently, the authen-
not place restrictions on the user’s ability to manipulate tic peripheral is polled until a response is received, which
USB data. The host and client emulation drivers are im- is then forwarded to the host. Some hosts have a shorter
plemented in Python and expose the raw USB data over timeout for peripheral responses, and may reissue redun-
Unix pipes. If desired, other forms of inter-process com- dant requests if the data is not relayed when it’s immedi-
munication (IPC) such as Unix sockets could also be em- ately available; fine-grained tuning of poll intervals could
ployed. We opted for named pipes due to the simplicity thus quicken transmission. This could also be explored in
of having host and peripheral emulation drivers attach to tandem with communicating the entire handshaking pro-
these endpoints, instead of implementing extra IPC func- cess instead of performing blind ACKs for some requests,
tionality in the drivers themselves. Moreover, the user is as mentioned in Section 3.2.2.
not restricted to Python, and if desired, may implement
drivers that interact with the Facedancer in any preferred
language. A further advantage of our framework is the
6 Related Work
ability to immediately replay USB communication from
The Facedancer [2] presents recent advances in the arena
either a host or peripheral in an emulated fashion—the
of USB software testing by way of device emulation
user need not write additional scripts to generate USB
techniques. Bratus et al. demonstrate how this technique
traffic.
enables “efficient injection of arbitrary traffic” into the
USB bus, while being affordable [8].
Cost Effective Despite the software limitation of the Software-only techniques for USB testing have been
USB analyzer, its capabilities go beyond that of other considered, where USB devices are emulated in a guest
tools and pure software solutions. Davis [11] attested in operating system environment [6]. Similar fuzzing in
2013 that it is the preferred device for finding USB bugs, various virtualized OS environments by Jodeit et al. [12]
although at a cost of approximately $1,400. In contrast, has triggered bugs in virtualization software and USB
the hardware required by the Facedancer’s in our solution drivers. Although this technique has proven its ability to
would cost approximately $150 [3]. find bugs, its effectiveness is limited to the capabilities
of the virtualization software. According to Jodeit et al.,
Background Knowledge Requirement As men- a further limitation includes the difficulty in reproducing
tioned, a USB analyzer would typically require crashes.
understanding of the USB protocol for generating USB Davis’s use of USB analyzers has produced a number
traffic, as well as knowledge of a custom scripting lan- of CVE (Common Vulnerabilities and Exposures) iden-
guage. Similarly, a single bespoke testing device such as tifiers relating to USB security on Windows, Solaris, and
the Facedancer requires knowledge of the USB protocol OS X [9, 11]. Davis also demonstrates the Frisbee USB
so that it can be programmed to respond appropriately to testing automation by using USB analyzers within the

7
confines of a cumbersome scripting language [10]. Still, References
this has proven to be one of the best approaches to date.
[1] Facedancer Firmware Source Repository. https:
//goodfet.svn.sourceforge.net/svnroot/goodfet.
Accessed 25/05/2014.
[2] GoodFET Facedancer. https://goodfet.sourceforge.
7 Conclusion net/hardware/facedancer21/. Accessed 25/05/2014.
[3] int3cc. http://int3.cc/products/facedancer21. Ac-
In this work we presented a framework that exposes cessed 25/05/2014.
USB communication between a host and peripheral in a [4] MQP Electronics. http://www.mqp.com/usb500.htm. Ac-
flexible, cost-effective way. The framework contributes cessed 25/05/2014.
to the growing demands of USB testing software by en- [5] USB Device Working Group. http://www.usb.org/
abling man-in-the-middle attacks, and allowing users to developers/docs/devclass_docs/. Accessed 25/05/2014.
fuzz host and device USB software. We detected novel [6] MWR InfoSecurity. https://labs.mwrinfosecurity.com/
bugs that resulted by modifying USB data during real- blog/2011/07/14/usb-fuzzing-for-the-masses/, 2011.
Accessed 25/05/2014.
time communication, and found that the bugs can be re-
[7] BARRALL , D., AND D EWEY, D. Plug and root, the USB key to
produced by replaying the captured responses in an em- the kingdom. In Black Hat Briefings (jul. 2005).
ulated fashion.
[8] B RATUS , S., G OODSPEED , T., J OHNSON , P. C., S MITH , S. W.,
We believe there are a number of additional applica- AND S PEERS , R. Perimeter-crossing buses: A new attack surface
tions for the TTWE framework beyond those covered for embedded systems. In 8th Workshop on Embedded Systems
in this paper. For one, the framework could be used Security (WESS) (sept. 2013).
to capture authentic host/peripheral USB communica- [9] DAVIS , A. USB - Undermining security barriers. In Black Hat
Briefings (aug. 2011).
tion which may be catalogued to serve as seed values
for randomized fuzzing. This ability could speed up [10] DAVIS , A. Fuzzing USB devices using frisbeelite. Tech. rep.,
NGS Secure Research, jan. 2012.
fuzzing, and in some instances substitute for the need of
[11] DAVIS , A. USB driver vulnerabilities whitepaper. Tech. rep.,
a physical device. Secondly, we envision that the frame-
NCC Group, jan. 2013.
work can be leveraged in exploitation techniques such as
[12] J ODEIT, M., AND J OHNS , M. USB device drivers: A stepping
Mulliner’s mass-storage TOCTTOU attack [13]. In lieu stone into your kernel. In 2010 European Conference on Com-
of maintaining two emulated mass-storage filesystems as puter Network Defense (2010).
per the original approach, and having to “switch between [13] M ULLINER , C., AND M ICHELE , B. Read it twice! A mass-
the original and modified filesystem image” in order to storage-based tocttou attack. In 6th USENIX Workshop on Offen-
exploit the “read-it-twice” condition, one could instead sive Technologies (aug. 2012).
modify the data on the fly from a single filesystem image [14] V EGA , R. D. Linux kernel USB device driver - buffer overflow.
at the exact moment that modification is desired. Such Tech. rep., MWR InfoSecurity, oct. 2009.
an ability is made evident from the discussion in Sec- [15] W RIGHT, J. http://code.google.com/p/zigbee-
tion 4.1. security/. Accessed 25/05/2014.

The prospects of vulnerability discovery and exploita-

tion of the USB attack surface are expected to increase Notes
as the tools for doing so improve. To echo the words of 1 CVE advisories related to USB software bugs
Joshua Wright, “Security will not get better until tools
for practical exploration of the attack surface are made 2013 2012 2011 2010 2009
CVE-2013-1285 CVE-2012-2693 CVE-2011-0712 CVE-2010-4656 CVE-2009-4067
available” [15]. We believe that the TTWE framework CVE-2013-1286 CVE-2012-3723 CVE-2011-2295
CVE-2013-1287
makes practical exploration of the USB attack surface CVE-2013-2888
CVE-2013-2889
flexible and affordable, thereby contributing to the effort CVE-2013-2890
CVE-2013-2891
of securing USB software. CVE-2013-2892
CVE-2013-2893
CVE-2013-2894
CVE-2013-2895
CVE-2013-2896
CVE-2013-2897
CVE-2013-2898
8 Acknowledgements CVE-2013-2899
CVE-2013-3200

2 $75 at the time of writing

A hearty thank you to Willem Bester for taking the time 3 A complete bill of materials for the Facedancer may be found at
outside of his regular duties to deliver insightful com- http://goodfet.sourceforge.net/hardware/facedancer21/
ments during the review of this work. The authors also
wish to thank Naspers for their financial support during
the course of this research.