Clear Hat Consulting, Inc.

Clear Hat Consulting, Inc. www.clearhatconsulting.com Assessment of Software & Hardware Approaches to Building a USB Fuzzer 1. Background The USB protocol defines communication between a host controller and a USB device. The USB host acts in the role of bus master and must initiate all data transfers with devices. The USB devices act in the role of slaves on the bus and are required to respond to requests from the USB host. Requests sent to the device by the host fall into one of three categories: Standard Requests Class Specific Requests Vendor Specific Requests Some examples of Standard Requests include: Get Status Clear Feature Set Feature Set Address Get Descriptor Get Configuration Get Interface Set Interface In response to a request from the host controller, a device stores the requested data in a USB Descriptors. There are several types of descriptors, but the primary ones are Device, Configuration, Interface, and String descriptors. The type of descriptor returned differs depending on the request. When a new USB device is plugged into the system, the host will make a sequence of requests designed to discover information about the device. It uses this information to determine what driver needs to be loaded. The typical sequence of events and requests that occur when a new device is plugged in are summarized as follows: 1. The hub detects the device based on the voltages on the D+ and D- lines on its ports. 2. The hub reports the new device to the host. In response, the host sends the hub a Get Port Status request. 3. The hub detects if the device is low or full speed. 4. The host sends the hub a Set Port Feature request that asks the hub to reset the port.

2 5. The host learns if a full speed device supports high speed. 6. The host verifies that the device has exited the reset state by sending a Get Port Status request. 7. The host sends a Get Descriptor request to learn the maximum packet size 8. The host assigns a unique address to the device by sending a Get Address request. 9. The host sends a Get Descriptor request to the new address to read the device descriptor. The descriptor contains the maximum packet size, the number of configurations that the device supports, and other information about the device. Based upon the information in the device descriptor, the host requests the configuration descriptor specified in the device descriptor. Finally it requests the interface descriptors. 10. Based upon all of the descriptor information, the host assigns a device driver to the device and loads it. 11. The device driver selects a configuration based on the descriptor information by sending a Set Configuration request. The device is now in the configured state and is ready for use. 2. Windows USB Architecture

3 Windows implements the USB specification in a layered driver architecture. The mini port drivers usbuhci.sys and usbehci.sys are located at the bottom of the stack. From diassembling them in IDA pro, they appear to implement the port based requests like Get Port Status and Set Port Feature. Therefore, these drivers would probably implement the first six events that occur during the initialization of a new device. The usbd.sys driver sits above the port drivers. It is the Windows USB bus driver. From disassembling usbd.sys in IDA Pro, most of its functions appear to be related to getting and parsing configuration descriptors. Therefore, it appears that usbd.sys would handle events 7-9 in the above list. The Windows hub driver usbhub.sys sits above usbd.sys and the port drivers. It seems to handle the interpretation of the descriptor information and determination of which class driver should be loaded. Finally, the USB class drivers are at the top of the Windows USB driver stack. The class driver is based on the type of device. Class drivers may be either system or vendor supplied. Windows supplies several class drivers including: 1. Bthusb.sys (bluetooth class) 2. Usbccid.sys (smart card interface devices) 3. Hidusb.sys (human interface device class) 4. Usbstor.sys (mass storage class) 5. Usbprint.sys (printing class) 6. WpdUsb.sys (scanning / imaging) 7. WpdUsb.sys (media transfer class) 8. Usbaudio.sys (usb audio class) 9. Usbser.sys (usb modem class) 10. Usbvideo.sys (video class) There are a few software tools that allow us to view USB traffic. One of these is the Snoopy Pro tool. Figure 1 shows Snoopy s view of the device requests that occur when a USB mass storage driver is plugged in. The first request is a Get Descriptor request to get the device descriptor (bdescriptortype = 1). This corresponds to step 9 in the previous list of initialization steps. The request for the device descriptor is followed by requests for the configuration descriptor. The reason we don t see the first 8 initialization steps becomes clear if we use the Windows DDK Device Tree tool to view the driver stack after installing Snoopy. The Snoopy driver usbsnoop.sys has 6 filter devices associated with it. These filters attach to the Windows drivers usbhub.sys, hidusb.sys, usbstor.sys, usbscan.sys, and usbprint.sys. Because usbhub.sys is the lowest level driver that Snoopy attaches too, we don t see the port requests that were made by the lower level port drivers in the Windows device stack (usbuhci.sys, usbehci.sys, ect). The first 8 initialization steps must have been handled by these lower level drivers.

4 Figure 1: Snoopy output after plugging in a USB flash drive. 3. USB Fuzzer Design Goals The goal of fuzzing the Windows USB interface is to efficiently exercise the code paths in the Windows port, hub, and class drivers to identify bugs related to assumptions about how devices implement / obey the protocol specification. Therefore, a good starting point for a fuzzer might be to focus on the requests that involve the transmission of device data to the host. As mentioned previously, device data returned in descriptors. Furthermore, there are several different types of descriptors and the exact type of

5 descriptor used is dependent on the specific host request. Ideally, a USB fuzzer should have the following qualities: It should be able to send malformed descriptor data in response to different requests from the host. The Black Hat USB vulnerability presented by Darrin Baral and David Dewey was an example of a vulnerability during device initialization involving a malformed device string descriptor. It should be able to emulate different USB devices by returning descriptor data that is capable of impersonating different device classes. By impersonating different types of devices, we may be able to exercise code paths in some of the Windows upper level class drivers. The hope is that some of these drivers have not been as well debugged as some of the core drivers. Based upon our research, we feel that it might be possible to take several different approaches to developing a USB fuzzer. Each of these approaches has a different cost profile that is associated with different strengths and weaknesses. In the following section we analyze three possible approaches to the problem. 4 Software Based Fuzzers It may be possible to implement a Software based fuzzer using a low level USB filter driver similar to Snoopy. Using a filter, we should be able to intercept and modify USB related request data as it is passed up the USB device stack. The placement of the filter in the device stack would determine the type of USB requests we would be able to control and the driver code paths that we would be able to influence. For example, the Snoopy driver attaches to usbhub.sys so it is unable to influence any requests that are handled by the lower level port drivers. A software based fuzzer solution does not have any associated hardware cost, but it may have a high cost of development due to the complexity of the Windows USB stack. It may, however, be possible to reduce the development cost and complexity somewhat by modifying an open source USB sniffer like Snoopy. One issue that we foresee with a filter driver based solution concerns traffic generation. For a fuzzer to be efficient and achieve maximum code coverage it needs to have a constant stream of traffic into the various host drivers. While filter drivers may be used to modify existing USB traffic, it may be more difficult to use them to generate new traffic. Furthermore, many of the bugs may exist in the initialization sequence for a device. Initialization occurs in response to voltage changes associated with plugging a device into a hardware USB port. Manually plugging and unplugging a USB device from a physical port is clearly not an efficient way to fuzz those paths. Therefore, we need a means of causing software based attach and detach events. Although these may be a solvable problems, our experience with the USB protocol is limited and the Windows USB driver stack is complex. The solution to these issues is not immediately clear. The final drawback to a software based solution is that it is Operating System dependent and cannot be used to fuzz USB drivers on other systems like Linux or Mac.

6 5. Hardware Fuzzers (Programmable USB Development Board) We could implement a USB fuzzer using a programmable USB device. There are a variety of USB development boards on the market and they are relatively in-expensive. Ideally, we need a development board with flashable firmware and good software support. Software support is essential because we will need to implement the handling for most of the host s device requests. Development cost could be high if we have to implement all of a USB device s firmware functionality from scratch. If the device already has firmware, source availability, good documentation, and is flashable, development should be easier because we will be able to modify the existing firmware. In some aspects, modifying device firmware may be easier than modifying a Windows USB filter driver. That is because we only need to understand the USB specification rather than needing to understand both the USB specs and the Windows USB driver stack. Generating traffic should also be easier with a hardware device because the signals that control device attachment should be able to be manipulated by the device firmware. Finally, a hardware approach is Operating System independent and could be eventually be used to fuzz other platforms. We have surveyed some of the USB development boards that are available. Some of following boards look like they could suit our needs. 5.1 DevaSys USB Development Device. WEBSITE: http://www.devasys.com/pd11.htm PROS: The firmware is flashable and example firmware is provided. The device is also very reasonably priced at $79.00 CONS: The example firmware was written on Borland Turbo C and would require porting to another Development environment. The website also claims that the device is temporarily out of stock. Not clear if there is a firmware backup. 5.2 Acquire Devices

7 The Pike USB 2.0 EZ-USB FX2 Based Prototyping Board is ideal for rapid prototyping, evaluation, small-scale production, and educational use for developing USB applications. The Pike USB 2.0 EZ-USB FX2 Based Prototyping Board functions as a USB High Speed device with supported transfer rates up to 480Mbit/s, and the EZ-USB FX2 chip is fully backward compatible as a USB Full Speed device with data rates up to 12Mbit/s. The Pike Board uses the 56-Pin Cypress CY68013A EZ-USB FX2 High Speed transceiver, and supports any existing EZ-USB FX2 firmware and host software. WEBSITE: http://www.acquiredevices.com/products.jsp PROS: The firmware is flashable and it supports any existing EZ-USB FX2 firmware. Firmware examples and software documentation are readily available. There is also a Windows development kit available from Cypress. http://www.cypress.com/?rid=14321 The hardware and development kit are both able to be ordered online. CONS: The website claims the development kit is out of stock. 6. Hardware Fuzzer (Traffic Generator / Scriptable Device Emulator) During our research, we looked at USB traffic generators. A USB traffic generator is a hardware component that is often used for testing USB devices. It is usually capable of generating abnormal traffic (i.e. traffic that does not follow the USB specifications) for testing purposes. Because the goal of a fuzzer is to generate abnormal traffic, a traffic generator seemed like it might be an ideal solution. Unfortunately, most available traffic generators only generate host side traffic to exercise the device logic. We actually need to generate device side traffic to exercise the host logic. We did, however, find a few companies with devices of interest. 6.1 NitAI Consulting Services NitAI Consulting Services is one of the few companies that claims to offer a USB device emulator for host / hub testing. It is implemented as an add in PC PCI card and the

8 feature list claims that the descriptor contents for host requests are scriptable which might make development easier than having to implement / modify the firmware. The company website lists the following features for their USB device emulator. WEBSITE: http://www.nital.com/corporate/usb2builder-d.html PROS: Fuzzing might be able to be performed using a script which could make development easier. CONS: Scriptable interface could limit flexibility if it is not designed to be vey configurable. Details of pricing and the scripting functionality were not readily available on the company website and contacting the company has been difficult. We attempted to contact the company by phone to get some more information about the scriptability support and pricing, but we were unable to reach a company representative. We also sent an email to the company but we have not yet received a reply. 6.2 Centrillium IT Consulting Centrillium advertises a USB emulator that that claims to turn a PC into a USB device. Their USB Device Emulator claims to have a USB loop back device capable of performing verification of the Host controller and driver stack. WEBSITE: http://www.centrillium-it.com/products/usbde/ PROS: You could use a second PC as a fuzzer for the host controller drivers on another PC without needing a separate USB development board. Claims to have an API and class library.

9 CONS: Website does not provide any pricing information or any documentation of API interface. 4. Recommendations Based on our research, we feel that a hardware solution for fuzzing USB may offer the best cost vs. benefit in terms of development time, complexity, and flexibility. USB development boards are relatively in-expensive. Furthermore, fuzzer development on a standalone device firmware may be easier than trying to intercept and modify device data in within the Windows USB software framework. This is because we only need to understand the USB specification rather than the USB Specification and the highly complex Windows USB Stack. Therefore, we anticipate that development costs may be a little bit less for a hardware based fuzzer. Finally, a hardware approach is Operating System independent and could be eventually be used to fuzz other platforms. There are at least 2 options for a hardware based solution. These include using a standalone programmable USB development board or using a device emulator that allows a PC to function as a USB device. Some of the USB device emulators have support for developing test traffic using scripts. This could simplify the fuzzing process, but it also may limit flexibility depending on how configurable the script interface is. We are leaning toward a standalone USB development board because we want maximum configurability. Of the development boards we looked at, we favor the USB 2.0 EZ-USB FX2. We like this board because it is flashable, it has an available development kit, and firmware examples are readily available. The company website currently lists the development kit as out of stock, but we intend to call their sales department about availability.