Making USB Great Again with usbfilter Dave (Jing) Tian and Nolen Scaife, University of Florida; Adam Bates, University of Illinois at Urbana–Champaign; Kevin R. B. Butler and Patrick Traynor, University of Florida https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/tian
This paper is included in the Proceedings of the 25th USENIX Security Symposium August 10–12, 2016 • Austin, TX ISBN 978-1-931971-32-4
Open access to the Proceedings of the 25th USENIX Security Symposium is sponsored by USENIX Making USB reat gain with USB L E
Dave (Jing) Tian⋆, Nolen Scaife⋆, Adam Bates , Kevin R. B. Butler⋆, and Patrick Traynor⋆ ⋆ University of Florida, Gainesville, FL University of Illinois, Urbana-Champaign, IL {daveti,scaife,adammbates,butler,traynor}@ufl.edu
stract devices allow disparate hardware functions such as a mi- crophone and speakers to appear on the same physical USB provides ubiquitous plug-and-play connectivity for connector (e.g., as provided by a headset). In the host a wide range of devices. However, the complex na- operating system, technologies such as USBIP [21] pro- ture of USB obscures the true functionality of devices vide the capability to remotely connect USB devices to from the user, and operating systems blindly trust any a host over a network. The result is a complex combina- physically-attached device. This has led to a number tion of devices and functionalities that clouds the user’s of attacks, ranging from hidden keyboards to network ability to reason about what is actually connected to the adapters, that rely on the user being unable to identify host. all of the functions attached to the host. In this paper, we Attacks that exploit this uncertainty have become present USBFILTER, which provides the first packet-level more prevalent. Firmware attacks such as BadUSB [27] access control for USB and can prevent unauthorized in- modify benign devices to have malicious behavior (e.g., terfaces from successfully connecting to the host operat- adding keyboard emulation to a storage device or per- ing system. USBFILTER can trace individual USB pack- form automatic tethering to another network). Hardware ets back to their respective processes and block unautho- attacks [1] may inject malware into a host, provide RF rized access to any device. By instrumenting the host’s remote control capabilities, or include embedded proxy USB stack between the device drivers and the USB con- hardware to inject and modify USB packets. Attack- troller, our system is able to filter packets at a granular- ers may also exfiltrate data from the host by leveraging ity that previous works cannot — at the lowest possible raw I/O (e.g., using libusb [14]) to communicate with level in the operating system. USBFILTER is not only able the USB device directly, or bypass the security mecha- to block or permit specific device interfaces it can also nism employed by the USB device controller by sending restrict interfaces to a particular application (e.g., only specific USB packets to the device from the hostUSB Skype can access my webcam). Furthermore, our ex- controller [4]. Unfortunately, the USB Implementers Fo- perimental analysis shows that USBFILTER introduces a rum considers defending against malicious devices to be negligible (3-10µs) increase in latency while providing the responsibility of the user [44], who is unlikely to be mediation of all USB packets on the host. Our system able to independently verify the functionality and intent provides a level of granularity and extensibility that re- of every device simply by its external appearance, and duces the uncertainty of USB connectivity and ensures may just plug in USB devices to take a look [43]. unauthorized devices are unable to communicate with the host. Modern operating systems abstract USB authorization to physical control, automatically authorizing devices connected to the host, installing and activating drivers, 1 ntroduction and enabling functionality. We believe that a finer- grained control over USB is required to protect users. In The Universal Serial Bus (USB) provides an easy-to-use, this paper, we make the following contributions: hot-pluggable architecture for attaching external devices ranging from cameras to network interfaces to a single esign and develop a fine-grained USB ac- host computer. USB ports are pervasive they can of- cess control system: We introduce USBFILTER,a ten be found on the front, back, and inside of a com- packet-level firewall for USB. Our system is the first mon desktop PC. Furthermore, a single USB connector to trace individual USB packets back to the source may connect multiple device classes. These composite or destination process and interface. USBFILTER
USENIX Association 25th USENIX Security Symposium 415 rules can stop attacks on hosts by identifying and dropping unwanted USB packets before they reach EP 0 EP 0 EP 0 EP 0 EP 0 EP 0 their destination in the host operating system. EP 1 EP1 EP 1 EP 1 EP 1 EP 1 EP 2 EP 2 EP 2 EP 2 m lement nd c r cter e erform nce: We EP n EP n In Out In Out In Out demonstrate how USBFILTER imposes minimal Interface 0 Interface 1 Interface 2 overhead on USB traffic. As a result, our system USB Device is well-suited for protecting any USB workload.
emonstr te effect eness n re l world scen r Figure 1: A detailed view of a generic USB device. Sim- os: We explore how USBFILTER can be used ilar to a typical USB headset, this device has three inter- to thwart attacks and provide security guarantees faces and multiple endpoints. for benign devices. USBFILTER can pin devices (e.g., webcams) to approved programs (e.g., Skype, Hangouts) to prevent malicious software on a host device (HID, e.g., keyboard and mouse), printer, or stor- from enabling or accessing protected devices. age. However, the device may have multiple functions internally, known as interfaces. An example device with USBFILTER is different from previous works in this three interfaces is shown in Figure 1. USB devices with space because it enables the creation of rules that explic- more than one interface are known as composite devices. itly allow or deny functionality based on a wide range For example, USB headsets often have at least three in- of features. GoodUSB [41] relies on the user to explic- terfaces: the speaker, the microphone, and the volume itly allow or deny specific functionality based on what control functionalities. Each interface is treated as an in- the device reports, but cannot enforce that the behav- dependent entity by the host controller. The operating ior of a device matches what it reports. SELinux [35] system loads a separate device driver for each interface policies and PinUP [13] provide mechanisms for pinning on the device. processes to filesystem objects, but USBFILTER expands The USB protocol works in a master-slave fashion, this by allowing individual USB packets to be associated where the host USB controller is responsible to poll the with processes. This not only allows our system to per- device both for requests and responses. When a USB mit pinning devices to processes, but also individual in- device is attached to a host machine, the host USB con- terfaces of composite devices. troller queries the device to obtain the configurations of Our policies can be applied to differentiate individual the device, and activates a single configuration supported devices by identifiers presented during device enumera- by the device. For instance, when a smartphone is con- tion. These identifiers, such as serial number, provide nected with a host machine via USB, users can choose a stronger measure of identification than simple prod- it to be a storage or networking device. By parsing the uct and vendor codes. While not a strong authentication current active configuration, the host operating system mechanism, USBFILTER is able to perform filtering with- identifies all the interfaces contained in the configura- out additional hardware. The granularity and extensibil- tion, and loads the corresponding device drivers for each ity of USBFILTER allows it to perform the functions of interface. This whole procedure is called USB enumera- existing filters [41] while permitting much stronger con- tion [10]. Once a USB device driver starts, it first parses trol over USB devices. the endpoints information embedded within this interface The remainder of this paper is structured as follows: In as shown in Figure 1. Section 2, we provide background on the USB protocol and explain why it is not great anymore in Section 3, While the interface provides the basic information for we discuss the security goals, design and implementation the host operating system to load the driver, the endpoint is the communication unit when a driver talks with the of our system in Section 4, we discuss how USBFILTER meets our required security guarantees in Section 5, we USB device hardware. Per specification, the endpoint 0 (EP0) should be supported by default, enabling Control evaluate USBFILTER and discuss individual use cases in Section 6, we provide additional discussion in Section 7, (packet) transfer from a host to a device to further probe we explore related work and in Section 8, we conclude. the device, prepare for data transmission, and check for errors. All other endpoints can be optional though there is usually at least EP1, providing Isochronous, Inter- ckgro nd rupt, or Bulk (packet) transfers, which are used by au- dio/video, keyboard/mouse, and storage/networking de- A USB device refers to a USB transceiver, USB hub, host vices respectively. All endpoints are grouped into either controller, or peripheral device such as a human-interface In pipes, where transfers are from the device to the host,
2 416 25th USENIX Security Symposium USENIX Association or Out pipes, where transfers are from the host to the host. While it may be possible to perform power anal- device. This in/out pipe determines the transmission di- ysis attacks without sending USB packets, we focus on rection of a USB packet. With all endpoints set up, the the problem of connecting malicious devices to the host’s driver is able to communicate with the device hardware operating system. All of these attacks share a common by submitting USB packets with different target end- thread: they attach an unknown interface to a host with- points, packet types, and directions. These packets are out the user’s knowledge. Since operating systems im- delivered to the host controller, which calls the controller plicitly trust any device attached, these hidden functions hardware to encode USB packets into electrical signals are enumerated, their drivers are loaded, and they are and send them to the device. granted access to the host with no further impediment. Data exfiltration from host machines may be the main reason why USB storage is banned or restricted in enter- s re t prise and government environments. Current secure stor- Prior to USB’s introduction in the 1990s, personal com- age solutions rely on access control provided by the host puters used a number of different and often platform- operating system [23] or use network-based device au- specific connectors for peripherals. Serial and parallel thentication [22]. While access controls can be bypassed ports, PS/2, SCSI, ADB, and others were often not hot- by raw I/O, which communicates to the device directly pluggable and required users to manually set configura- from userspace (e.g., using libusb [14]), network-based tion options (such as the SCSI ID). The widespread in- methods are vulnerable to network spoofing (e.g., ARP dustry adoption of USB fixed many of these issues by spoofing [32] and DNS spoofing [36]). It is thusun- providing a common specification for peripherals. Hard- clear whether data exfiltration has occurred or not until ware configuration is now handled exclusively by the the USB port is glued or locked [39]. The remainder of host, which is able to manage many devices on a sin- this paper will show how a packet-level filter for USB gle port. The relative ease with which a USB peripheral permits fine-grained access controls, eliminating the im- can be installed on a host is simultaneously its greatest plicit trust model while providing strong guarantees. and most insecure property. The USB subsystem has been expanded in software Access ontrol as well, with Virtio [30] supporting I/O virtualization in KVM, enabling virtual USB devices in VMs, and pass- The complex nature of the USB protocol and the variety ing through the physical devices into VMs. USBIP [21] of devices that can be attached to it makes developing a transfers USB packets via IP, making remote USB de- robust and efficient access control mechanism challeng- vice sharing possible. Wireless USB (WUSB) [19] and ing. Layers in the operating system between the process Media Agnostic USB (MAUSB) [16] promote the avail- and the hardware device create difficulties when identi- ability of USB devices by leveraging different wireless fying processes. Accordingly, developing a system such communication protocols, making the distinction among as USBFILTER is not as simple as intercepting USB pack- local USB devices, virtual ones, and remote ones vanish. ets and dropping those that match rules. In this section, Overall, the utility and complexity of USB has been we discuss our security goals, design considerations, and steadily increasing in both hardware and software. Ad- implementation of USBFILTER while explaining the chal- vances in circuit and chip design now allow hidden func- lenges of developing such a system. tionality to be placed inside the USB plug [1]. The ease- of-use that made USB great now threatens users by ob- scuring the individual interfaces in a USB device. re t nd r st odels We consider an adversary against our system who has ow ost ts re tness restricted external physical or full network access to a given host. The adversary may launch physical attacks Attacks on USB prey on the fundamental misunderstand- such as attaching unauthorized USB devices to the host ing of how devices are constructed from interfaces. At- system or tampering with the hardware of previously- tacks such as BadUSB [27] and TURNIPSCHOOL [1] authorized devices to add additional functionality. The (itself designed on specifications from nation-state ac- physically-present adversary may not open the device or tors) use composite devices to present multiple interfaces tamper with the internal storage, firmware, or any other to a host. Often these include one benign or expected in- hardware. This type of adversary might (for example) be terface and one or more malicious interfaces, including present in an data center or retail location, where devices keyboards [9, 27] and network interfaces [27, 1]. With- have exposed USB ports, but tampering with the chas- out communicating with the host operating system, a sis of the device would raise suspicion or sound alarms. malicious USB device can only obtain power from the The adversary may also launch network attacks in order
3 USENIX Association 25th USENIX Security Symposium 417 App1 App2 App3 App1 App2 App3
I/O operation User Space usbtables I/O operation Kernel Space User Space netlink Kernel Space Rule USBFILTER Storage Input Video USB packet DB Driver Driver Driver URB mouse camera Host Controller keyboard headset Rule USBFILTER usbfilter DB modules storage wireless USB packet
USB Devices Figure 2: USBFILTER implements a USB-layer reference monitor within the kernel, by filtering USB packets to different USB devices to control the communications be- Figure 3: The architecture of USBFILTER. tween applications and devices based on rules config- ured. defined rule-based filtering for the USB protocol. To achieve this, we first designed our system to satisfy the concept of a reference monitor [2], shown in Figure 2. to enable or access authorized devices from unauthorized While these goals are not re uired for full functionality processes or devices. In either case, the adversary may of USBFILTER, we chose to design for stronger security attempt to exfiltrate data from the host system via both guarantees to ensure that processes attempting to access physical and virtual USB devices. hardware USB devices directly would be unable to cir- We consider the following actions by an adversary: cumvent our system. We define the specific goals as fol- evice ampering: The adversary may attempt lows: to attach or tamper with a previously-authorized 1 omplete Mediation. All physical or virtual USB device to add unauthorized functionality (e.g., packets must pass through USBFILTER before deliv- BadUSB [27]). ery to the intended destination.
Unauthori ed evices: Unauthorized devices at- 2 amperproof. USBFILTER may not be bypassed or tached to the system either physically or virtu- disabled as long as the integrity of the operating sys- ally [21] can be used to discreetly interact with the tem is maintained. host system or to provide data storage for future ex- filtration. 3 erifia le. The user-defined rules input into the system must be verifiably correct. These rules may Unauthori ed ccess: The adversary may attempt not conflict with each other. to enable or access authorized devices on a host (e.g., webcam, microphone, etc.) via unauthorized While the above goals support the security guarantees software to gain access to information or function- that we want USBFILTER to provide, we expand upon ality that would otherwise inaccessible. these to provide additional functionality: 4 ranular. Any mutable data in a USB packet We assume that as a kernel component, the integrity of header must be accessible by a user-defined rule. If USBFILTER depends on the integrity of the operating sys- the ultimate destination of a packet is a userspace tem and the host hardware (except USB devices). Code process, USBFILTER must permit the user to specify running in the kernel space has unrestricted access to the the process in a rule. kernel’s memory, including our code, and we assume that the code running in the kernel will not tamper with USB- Modular. USBFILTER must be extensible and allow FILTER. We discuss how we ensure runtime and platform users to provide submodules to support additional integrity in our experimental setup in Section 3.4. types of analysis.
3.2 esign oals 3.3 esign and mplementation
Inspired by the Netfilter [40] framework in the Linux The core USBFILTER component is statically compiled kernel, we designed USBFILTER to enable administrator- and linked into the Linux kernel image, which hooks the
4 418 25th USENIX Security Symposium USENIX Association flow of USB packets before they reach the USB hostcon- This reverse mapping of interface to driver needs to be troller which serves the USB device drivers, as shown in performed only once per device. The interface index Figure 3. Like Netfilter, this USB firewall checks a user- distinguishes interfaces belonging to the same physical defined rule database for each USB packet that passes device and USB packets submitted by different driver through it and takes the action defined in the first match- instances. Once the mapping has been completed, the ing rule. A user-space program, USBTABLES, provides USB host controller is able to easily trace the originating mediated read/write access to the rule database. Since interface back to the USB packets. USBFILTER intercepts USB packets in the kernel, it can control access to both physical and virtual devices. rocesses Similarly, tracking the destination or source process responsible for a USB packet is not trivial due cket lter ng R les to the way modern operating systems abstract device ac- cess from applications. For example, when communi- To access external USB devices, user-space applications cating with USB storage devices, the operating system request I/O operations which are transformed into USB provides several abstractions between the application and request blocks (URBs) by the operating system. The the raw device, including a filesystem, block layer, and communication path involves the process, the device, and I/O scheduler. Furthermore, applications generally sub- the I/O request itself (USB packet). Similarly, a USBFIL- mit asynchronous I/O requests, causing the kernel to per- TER rule can be described using the process information, form the communications task on a separate background the device information, and the USB packet information. thread. A USBFILTER rule R can be expressed as a triple This problem also appears when inspecting USB net- (N,C ,A) where N is the name of the rule, C is a set of work device packets, including both wireline (e.g., Eth- conditions, and A A OW,DROP is the action that is ernet) dongles and wireless (e.g., WiFi) adapters. It is ∈{ } taken when all of the conditions are satisfied. As long as common for these USB device drivers to have their own the values in conditions, action, and name are valid, this RX/TX queues to boost the system performance using rule is valid, but may not be correct considering other ex- asynchronous I/O. In these cases, USB is an intermedi- isting rules. We discuss verifying the correctness of rules ate layer to encapsulate IP packets into USB packets for in Section 4. processing by the USB networking hardware. These cases are problematic for USBFILTER because r ce ck a na ve traceback approach will often only identify the kernel thread as the origin of a USB packet. To recover USB packets do not carry attribution data that can be the process identifier (PID) of the true origin, we must used to determine the source or destination process of ensure that this information persists between all layers a packet. We therefore need to perform traceback to within the operating system before the I/O request is attribute packets to interfaces and processes. transformed into a USB packet.1 USBFILTER instruments the USB networking driver nterf ces As discussed in Section 2, a USB device can (usbnet), the USB wireless driver (rt usb), the USB have multiple interfaces, each with a discrete function- storage driver (usb storage), as well as the block layer ality served by a device driver in the operating system. and I/O schedulers. Changes to the I/O schedulers are Once a driver is bound with an interface, it is able to needed to avoid the potential merging of two block re- communicate with that interface using USB packets. quests from different processes. By querying the rule Determining the driver responsible for receiving or database and USBFILTER modules, USBFILTER sets up a sending a given USB packet is useful for precisely con- filter for all USB packets right before being dispatched trolling device behaviors. However, identifying the re- to the devices. sponsible driver is not possible at the packet level, since the packets are already in transit and do not contain iden- tifying information. While we could infer the respon- sers ce ontrol sible driver for simple USB devices, such as a mouse, USBTABLES manages USBFILTER rules added in the ker- this becomes unclear with composite USB devices with nel and saves all active rules in a database. Using udev, multiple interfaces (some of which may be served by the saved rules are flushed into the kernel automatically upon same driver). reboot. USBTABLES is also responsible for verifying the To recover this important information from USB correctness of rules as we will discuss in Section 4. Once packets without changing each driver and extending
the packet structure, we save the interface index into 1USBFILTER does not overlap with Netfilter or any other IP packet the kernel endpoint structure during USB enumeration. filtering mechanisms which work along the TCP/IP stack.
5 USENIX Association 25th USENIX Security Symposium 419 verified, new rules will be synchronized with the kernel 4 Security and saved locally. If no user-defined rules are present, USBFILTER en- In this section, we demonstrate that USBFILTER meets forces default rules that are designed to prevent impact the security goals outlined in Section 3 using the deploy- on normal kernel activities (e.g., USB hot-plugs). These ment and configurations described in that section. rules can be overridden or augmented by the user as de- sired. omplete Mediation 1 . As we previously discussed, USBFILTER must mediate all USB packets between de- vices and applications on the host. In order to ensure 3.4 eployment this, we have instrumented USBFILTER into the USB host controller, which is the last hop for USB packets before We now demonstrate how we use existing security tech- leaving the host machine and the first when entering it. ni ues in the deployment of USBFILTER. Attestation and Devices cannot initiate USB packet transmission without MAC policy are necessary for providing complete medi- permission from the controller. ation and tamperproof reference monitor guarantees, but We also instrument the virtual USB host controller not for the functionality of the system. The technologies (vhci) to cover virtual USB devices (e.g., USB/IP). To we reference in this section are illustrative examples of support other non-traditional USB host controllers such how these goals can be met. as Wireless USB [19] and Media Agnostic USB [16], USBFILTER support is easily added via a simple kernel 3.4.1 Platform ntegrity API call and the inclusion of a header file.
We deployed USBFILTER on a physical machine with a amperproof 2 . USBFILTER is statically com- Trusted Platform Module (TPM). The TPM provides a piled and linked into the kernel image to avoid being root of trust that allows for a measured boot of the system unloaded as a kernel module. The integrity of this and provides the basis for remote attestations to prove runtime, the associated database, and user-space tools that the host machine is in a known hardware and soft- is assured through the SELinux policy as described in ware configuration. The BIOS’s core root of trust for Section 3.4.2. Tampering with the kernel or booting a measurement (CRTM) bootstraps a series of code mea- different kernel is the only way to bypass USBFILTER, surements prior to the execution of each platform com- and platform integrity measures provide detection ponent. Once booted, the kernel then measures the code capabilities for this scenario (Section 3.4.1). for user-space components (e.g., provenance recorder) before launching them using the Linux Integrity Mea- ormal erification 3 . The formal verification of surement Architecture (IMA)[31]. The result is then ex- USBFILTER rules is implemented as a logic engine within tended into TPM PCRs, which forms a verifiable chain USBTABLES using GNU Prolog [11]. Instead of trying to of trust that shows the integrity of the system via a dig- prove that an abstract model of rule semantics is correctly ital signature over the measurements. A remote verifier implemented by the code, which is usually intractable for can use this chain to determine the current state of the the Linux kernel, we limit our focus on rule correctness system using TPM attestation. Together with TPM, we 2 and consistency checking. Each time USBTABLES is in- also use Intel’s Trusted Boot (tboot) voked to add a new rule, the new rule and the existing rules are loaded into the logic engine for formal verifica- 3.4.2 untime ntegrity tion. This process only needs to be performed once when adding a new rule and USBFILTER continues to run while After booting into the USBFILTER kernel, the runtime in- the verification takes place. tegrity of the TCB (defined in Section 3.1) must also be The verification checks for rules with the same con- assured. To protect the runtime integrity of the kernel, ditions but different actions. These rules are consid- we deploy a Mandatory Access Control (MAC) policy, ered conflicting and USBTABLES will terminate with er- as implemented by Linux Security Modules. We enable ror when this occurs. We define the correctness of a rule: SELinux’s MLS policy, the security of which was for- mally modeled by Hicks et al. [20]. We also ensure that is correct(R,R) ← USBTABLES executes in a restricted environment and is name uni ue(R) that the access to the rules database saved on the disk ∧ are condition values in range(R) is protected by defining an SELinux Policy Module and ∧ compiling it into the SELinux Policy. has no con f lict with e isting rules(R,R).
2 See http://sf.net/projects/tboot where R is a new USBFILTER rule and R for all other
6 420 25th USENIX Security Symposium USENIX Association existing rules maintained by USBFILTER. If the new rule -d|--debug enable debug mode has a unique name, all the values of conditions are in -c|--config path to configuration file (TBD) -h|--help display this help message range, and it does not conflict with any existing rules, the -p|--dump dump all the rules rule is correct. -a|--add add a new rule -r|--remove remove an existing rule While the name and the value checks are straightfor- -s|--sync synchronize rules with kernel ward, there are different conflicting cases between the -e|--enable enable usbfilter -q|--disable disable usbfilter conditions and the action, particularly when a rule does -b|--behave change the default behavior not contain all conditions. For example, a rule can be -o|--proc process table rule -v|--dev device table rule contradictory with, a sub rule of, or the same as another -k|--pkt packet table rule existing rule. As such, we define the general conflict be- -l|--lum LUM table rule -t|--act table rule action tween two rules as follows: ------proc: pid,ppid,pgid,uid,euid,gid,egid,comm general con f lict(Ra,Rb) dev: busnum,devnum,portnum,ifnum,devpath,product, ← manufacturer,serial Ci C : pkt: types,direction,endpoint,address ∀ lum: name ( Ca R Cb R value(Ca) = value(Cb)) behavior/action: allow|drop ∃ i a ∧∃ i b ∧ i i ∨ a b ( Ci Ra Ci Rb) ∃ ∧∃ ∨ Figure 4: The output of usbtables -h . The per- ( Ca R Cb R ). ∃ i a∧∃ i b mitted conditions are divided into 4 tables: the process table, the device table, the packet table, and the Linux A rule Ra is generally conflicted with another rule Rb if USBFILTER Module (LUM) table. all conditions used by Ra are a subset of the ones spec- ified in Rb. We consider a general conflict to occur if the new rule and an existing rule would fire on the same packet. Based on the general conflict, we define weak conflict and strong conflict as follows: r n l r .AUSBFILTER rule can contain 21 different conditions, excluding the name and action weak con f lict(Ra,Rb) ← field. We further divide these conditions into 4 tables, general con f lict(R ,R ) action(R )=action(R ). a b ∧ a b including the process, device, packet, and the Linux strong con f lict(Ra,Rb) USBFILTER Module (LUM) table, as shown in Figure 4. ← general con f lict(Ra,Rb) action(Ra) = action(Rb). The process table lists conditions specific to target ∧ applications; the device table contains details of USB While weak conflict shows that the new rule could be devices in the system; the packet table includes impor- a duplicate of an existing rule, strong conflict presents tant information about USB packets; and the LUM table that this new rule would not work. The weak conflict, determines the name of the LUM to be used if needed. however, depending on the requirement and the imple- Note that all LUMs should be loaded into the kernel mentation, may be allowed temporarily to shrink the before being used in USBFILTER rules. scope of an existing rule while avoiding the time gap between the old rule removed and the new rule added. For instance, rule A drops any USB packets writing od le tens on . To support customized rule data into any external USB storage devices. Later on, construction and deep USB packet analysis, USBFILTER the user decides to block write operations only for allows system administrators to write Linux USBFIL- the Kingston thumb drive by writing rule B, which is TER Modules (LUMs), and load them into the kernel as weak conflicted with rule A, since both rules havethe needed. To write a LUM, developers need only include same destination and action. When the user wants to the
7 USENIX Association 25th USENIX Security Symposium 421 Evaluation ually types commands in the terminal, while the mouse continually moves the cursor. We can write USBFILTER The USBFILTER host machine is a Dell Optiplex 7010 rules to completely shutdown the keyboard and mouse with an Intel uad-core 3.20 GHz CPU with 8 GB mem- functionalities: ory and is running Ubuntu Linux 14.04 LTS with kernel usbtables -a teensy1 -v ifnum=2,manufacturer= version 3.13. The machine has two USB 2.0 controllers Teensyduino,serial=1509380 -t drop usbtables -a teensy2 -v ifnum=3,manufacturer= and one USB 3.0 controller, provided by the Intel 7 Se- Teensyduino,serial=1509380 -t drop ries/C210 Series chipset. To demonstrate the power of USBFILTER, we first examine different USB devices and In these rules, we use condition “manufacturer” and “se- provide practical use cases which are non-trivial for tra- rial” (serial number) to limit the Teensy’s functionality. ditional access control mechanisms. Finally we measure Different interface numbers represent the keyboard and the overhead introduced by USBFILTER. the mouse respectively. After these rules applied, both The default behavior of USBFILTER in our host ma- the keyboard and the mouse return to normal. chine is to allow the USB packet if no rule matches the packet. A more constrained setting is to change the de- efault-deny input devices. Next, we show how to de- fault behavior to drop, requiring each permitted USB de- fend against HID-based BadUSB attacks using USBFIL- vice to need an allow rule. In this setting, malicious de- TER. These types of devices are a type of tro an horse vices have to impersonate benign devices to allow com- they appear to be one device, such as a storage device, munications, which are still regulated by the rules, e.g., but secretly contain hidden input functionality (e.g., key- no HID traffic allowed for a legit USB storage device. board or mouse). When attached to a host, the device All tests use the same front-end USB 2.0 port on the ma- can send keystrokes to the host and perform actions as chine. the current user. First, we create a BadUSB storage device using a Rub- ber Ducky [18], which looks like a USB thumb drive but .1 ase Studies opens a terminal and injects keystrokes. Then we add Listen-only USB headset. The typical USB headset following rules into the host machine: is a composite device with multiple interfaces includ- usbtables -a mymouse -v busnum=1,devnum=4,portnum=2, devpath=1.2,product="USB Optical Mouse", ing speakers, microphone, and volume control. Sen- manufacturer=PixArt -k types=1 -t allow sitive working environments may ban the use of USB usbtables -a mykeyboard -v busnum=1,devnum=3, portnum=1,devpath=1.1, headsets due to possible eavesdropping using the micro- product="Dell USB Entry Keyboard", phone [17]. Physically disabling the headset microphone manufacturer=DELL -k types=1 -t allow is often the only mechanism for permanently removing usbtables -a noducky -k types=1 -t drop it, as there is no other way to guarantee the microphone The first two rules whitelist the existing keyboard and stays off. Users can mute or unmute the microphone mouse on the host machine the last rule drops any USB using the desktop audio controls at any time after lo- packets from other HID devices. After these rules are gin. However, with USBFILTER, the system administra- inserted into the kernel, reconnecting the malicious de- tor can guarantee that the headset’s microphone remains vice does nothing. Attackers may try to impersonate the disabled and cannot be enabled or accessed by users. keyboard or mouse on the host machine. However, we We use a Logitech H390 Headset to demonstrate how have leveraged information about the physical interface to achieve this guarantee on the USBFILTER host ma- (busnum and portnum) to write the first two rules, chine: which would require the attacker to unplug the existing usbtables -a logitech-headset -v ifnum=2,product= devices, plug the malicious device in, and impersonate "Logitech USB Headset",manufacturer=Logitech -k the original devices including the device’s VID/PID direction=1 -t drop and serial number. We leave authenticating individual This rule drops any incoming packets from the USB devices to future work, however USBFILTER is Logitech USB headset’s microphone. By adding the extensible so that authentication can be added and used interface number (ifnum=2), we avoid breaking other in rules. functionality in the headset. ata exfiltration. To prevent data exfiltration from the ustomi ing devices. To further show how USBFIL- host machine to USB storage devices, we write a LUM TER can filter functionalities provided by USB devices, (Linux USBFILTER Module) to block the SCSI write we use Teensy 3.2 [29] to create a complex USB de- command from the host to the device, as shown in Fig- vice with five interfaces including a keyboard, a mouse, ure 9 in the Appendix. The LUM then registers itself a joystick, and two serial ports. The keyboard contin- with USBFILTER and can be referenced by its name in
8 422 25th USENIX Security Symposium USENIX Association rule constructions. In this case study, we use a Kingston Prolog Engine Min Avg Med Max Dev DT 101 II 2G USB flash drive, and insert the following Time (20 rules) 128.0 239.8 288.0 329.0 73.2 rule: Time (100 rules) 132.0 251.7 298.0 485.0 78.6
usbtables -a nodataexfil -v manufacturer=Kingston -l name=block_scsi_write -t drop Table 1: Prolog reasoning time (µs) averaged by 100 runs. This rule prevents modification of files on the stor- age device. Interestingly, vim reports files on the de- vice to be read-only, despite the filesystem reporting that then injects spoofed DNS replies into the host. The re- the files are read-write. Since USBFILTER is able to trace sulting man-in-the-middle attack gives the attacker ac- packets back to the applications initiating I/O operations cess to the host’s network communications without the at the Linux kernel block layer, we are able to write rules authorization of the user. To prevent this attack, we use blocking (or allowing) specific users or applications from USBFILTER to prevent all USB packets from a Google writing to flash drive: Nexus 4 smartphone:
usbtables -a nodataexfil2 -o uid=1001 usbtables -a n4-charger -v product="Nexus 4" -t drop -v manufacturer=Kingston -l name=block_scsi_write -t drop This rule rule drops any USB packets to/from the usbtables -a nodataexfil3 -o comm=vim -v manufacturer=Kingston phone, which enforces the phone as a pure charging de- -l name=block_scsi_write -t drop vice without any USB functionality. The phone is unable to be used for storage or tethering after the rule is applied. The first rule prevents the user with uid=1001 from We can construct a more specific charge-only rule: writing anything to the USB storage; the second blocks vim from writing to the storage. We can also block any usbtables -a charger -v busnum=1,portnum=4 -t drop writes to USB storage devices: This rule specifies a specific physical port on the host usbtables -a nodataexfil4 and this port can only be used for charging. This type -l name=block_scsi_write -t drop of rule is useful where USB ports may be exposed (e.g., on a point of sale terminal) and cannot be physically USBFILTER logs dropped USB packets, and these logs removed. It is also vital to defend against malicious can easily be used in a centralized alerting system, noti- devices whose firmware can be reprogrammed to forge fying administrators to unauthorized access attempts. the VID/PID such as BadUSB, since this type of rule e c m nn ng. Webcams can easily be enabled and only leverages the physical information on the host accessed by attackers from exploiting vulnerable appli- machine. USBFILTER can partition all physical USB cations. Once access has been established, the attacker ports and limit the USB traffic on each port. can listen or watch the environment around the host com- puter. In this case study, we show how to use USBFILTER to restrict the use of a Logitech Webcam C310 to specific users and applications. enc m rks usbtables -a skype -o uid=1001,comm=skype -v We first measure the performance of the user-space tool, serial=B4482A20 -t allow usbtables -a nowebcam -v serial=B4482A20 -t drop USBTABLES. We then measure the overhead imposed by USBFILTER. The serial number of the Logitech webcam is spec- The measurement host is loaded with the rules men- ified in the rules to differentiate any others thatmay tioned in the case studies above before beginning bench- be attached to the system as well as to prevent other marking. When coupled with the default rules provided webcams from being attached. The first rule allows by USBFILTER, there are 20 total rules loaded in the ker- USB communication with the webcam only if the user is nel. We chose 20 because we believe that a typical en- uid=1001 and the application is Skype. The following terprise host’s USB devices (e.g., keyboard, mouse, re- nowebcam rule drops other USB packets to the webcam movable storage, webcam, etc.) will total less than 20. otherwise. As expected, the user can use the webcam Then we load 100 rules in the kernel to understand the from his Skype but not from Pidgin, and other users scalability of USBFILTER. cannot start video calls even with Skype. cro enc m rk c rge onl . Another form of BadUSB attacks is DNS spoofing using smartphones. Once plugged into the A erform nce. We measure the time used host machine, the malicious phone automatically enables by the Prolog engine to formally verify a rule before it is USB tethering, is recognized as a USB NIC by the host, added into the kernel. We loaded the kernel with 20 and
9 USENIX Association 25th USENIX Security Symposium 423 Figure 5: Filebench throughput (MB/s) using Figure 6: Iperf bandwidth (MB/s) using TCP fileserver workload with different mean with different time intervals. file sizes.
Figure 8: Performance comparison of real- Figure 7: Iperf bandwidth (MB/s) using UDP world workloads. with different time intervals.
Rule Adding Min Avg Med Max Dev USB Enumeration Min Avg Med Max Dev Cost Time (20 rules) 5.1 5.9 6.1 6.6 0.3 Stock Kernel 32.0 33.9 34.1 34.8 0.6 N/A Time (100 rules) 4.9 5.9 6.1 6.8 0.4 USBFILTER (20 rules) 33.2 34.4 34.3 35.8 0.7 1.5 USBFILTER (100 rules) 33.9 34.8 34.6 36.0 0.5 2.7 Table 2: Rule adding operation time (ms) averaged by 100 runs. Table 3: USB enumeration time (ms) averaged by 20 runs.
100 rules and measured the time to process the rules. For each new rule, the Prolog engine needs to go through the locally, passing the rule to the kernel, and waiting for the existing rules and check for conflicts. acknowledgment. As shown in Table 2, the average time We measured 100 trials of each test. The performance of adding a rule using USBTABLES stays at around 6 ms of the Prolog engine is shown in Table 1. The average in both cases, which is a negligible one-time cost. time used by the Prolog engine is 239.8 µs with 20 rules and 251.7 µs with 100 rules. This fast speed is the n mer t on er e d. For this test, we used result of using GNU Prolog (gplc) compiler to compile the Logitech H390 USB headset, which has 4 interfaces. Prolog into assembly for acceleration. We also measure We manually plugged the headset into the host 20 times. the overhead for USBTABLES to add a new rule to the We then compare the results between the USBFILTER kernel space. This includes loading existing rules into kernel with varying numbers of rules loaded and the the Prolog engine, checking for conflicts, saving the rule stock Ubuntu kernel, where USBFILTER is fully disabled,
10 424 25th USENIX Security Symposium USENIX Association Packet Filtering Min Avg Med Max Dev USBFILTER kernel is loaded with 20 rules introduced in Time (20 rules) 2.0 2.6 3.0 5.0 0.5 the case studies before benchmarking. Time (100 rules) 2.0 9.7 10.0 15.0 1.0 le enc . We choose the fileserver workload in Table 4: Packet filtering time (µs) averaged by 1500 filebench, with the following settings: the number offiles packets. in operation is 20 the number of working threads is 1 the run time for each test case is 2 minutes the mean Configuration 1K 10K 100K 1M 10M 100M file size in operation ranges from 1 KB to 100 MB all Stock 97.6 98.1 99.2 105.5 741.7 5177.7 other settings are default provided by filebench. These USBFILTER 97.7 98.2 99.6 106.3 851.5 6088.4 settings emulate a typical usage of USB storage devices, Overhead 0.1 0.1 0.4 0.8 14.8 17.6 where users plug in flash drives to copy or edit some files. All file operations happen in a SanDisk Cruzer Fit16 Table 5: Latency (ms) of the fileserver workload GB flash drive. The throughputs under the stock kernel with different mean file sizes. and the USBFILTER kernel are demonstrated in Figure 5. When the mean file size is less than 1 MB, the through- as shown in Table 3. The average USB enumeration put of USBFILTER is close to the one of the stock kernel. Since there is at most 20 1 MB data involved in block time is 33.9 ms for the stock kernel and 34.4 ms and × I/O operations, both the stock kernel and USBFILTER can 34.8 ms for the USBFILTER kernel with 20 and 100 rules preloaded respectively. Comparing to the stock kernel, handle this data size smoothly. When the mean file size is greater than 1 MB, USBFILTER shows lower throughputs USBFILTER only introduces 1.5 and 2.7 overheads, or less than 1 ms even with 100 rules preloaded. comparing to the stock kernel, as the result of rule match- ing for each USB packet. Compared to the stock kernel, USBFILTER imposes 14.7 and 18.4 overheads when ck ng lter ng er e d. The overhead of USB the mean file sizes are 10 MB and 100 MB respectively. enumeration introduced by USBFILTER is the result That is, when there is 20 100 MB (2 GB) involved in of packet filtering and processing performed on each × USB packet, since there may be hundreds of packets block I/O operations, the throughput decreases from 8.7 during USB enumeration, depending on the number of MB/s to 7.1 MB/s, when USBFILTER is enabled. interface and endpoints of the device. To capture this The corresponding latencies are shown in Table 5. packet filtering overhead, we plug in a Logitech M105 The latency of USBFILTER is higher than the stock USB Optical Mouse, and move it around to generate kernel. Following the throughput model, the latencies enough USB packets. We then measure the time used between the two kernels are close when the mean file by USBFILTER to determine whether the packet should size is less than 1 MB. The overhead introduced by be filtered/dropped or not for 1500 packets, as shown USBFILTER is less than 1.0 . When the mean file sizes in Table 4. The average cost per packet are 2.6 µs and are 10 MB and 100 MB, USBFILTER imposed 14.8 9.7 µs respectively, including the time to traverse all and 17.6 overheads in latency. comparing to the stock kernel. That is, to deal with 20 100 MB data, users the 20/100 rules in the kernel, and the time used by the × benchmark itself to get the timing and print the result. need one more second to finish all the operations with The 100-rule case shows that the overhead of USBFILTER USBFILTER enabled, which is acceptable for most users. is uadruped when the number of rule increases by one order of magnitude. As we mentioned before, most erf. We use iperf to measure bandwidths of upstream common USB usages could be covered within 20 rules. TCP and UDP communications, where the host machine We assume it is rare for a system to have 100 rules for acts as a server, providing local network access via a different USB devices. To search in hundreds of rules Ralink RT5372 300 Mbps USB wireless adapter. The efficiently, we can setup a hash table using e.g.,USB time interval for each transmission is 10 seconds, and port numbers as keys to save rules instead of a linear each test runs 5 minutes (30 intervals). For TCP, we use array (list) currently implemented. the default TCP window size 64 KB for UDP, we use the default available UDP bandwidth size 10 MB. The TCP bandwidths of the two kernels are shown in Fig- ure 6, where we aggregate each two intervals into one, cro enc m rk reducing the number of sampling points from 30 to 15. We use filebench [37] and iperf [42] to measure through- and the average bandwidths are also listed in dot lines. puts and latencies of file operations, and bandwidths Though having different transmission patterns, the aver- of network activities, under the stock kernel and the age bandwidths of both are close, with the stock kernel at USBFILTER kernel, using different USB devices. The 2.75 Mbps and USBFILTER at 2.52 Mbps. Comparing to
11 USENIX Association 25th USENIX Security Symposium 425 the stock kernel, USBFILTER introduces 8.4 overhead. VFS layer, through the block layer, to the USB layer The UDP benchmarking result closely resembles within the kernel. However, it is not always possible to TCP, as shown in Figure 7. Regardless of transmission find the PID for each USB packet received by theUSB patterns, average bandwidth of the two kernels is similar, host controller. One example is HID devices, such as with the stock kernel at 3.48 Mbps and USBFILTER at keyboards and mouses. Keystrokes and mouse move- 3.27 Mbps. Comparing to the TCP transmission, UDP ments happen in the interrupt (IRQ) context, where the transmission is faster due to the simpler design/imple- current stopped process has nothing to do with this USB mentation of UDP, and USBFILTER introduces 6.0 packet. All these packets are delivered to the Xorg server overhead. In both cases, USBFILTER has demonstrated a in the user space, which then dispatches the inputs to dif- low impact to the original networking component. ferent applications registered for different events. USB- FILTER is able to make sure that only Xorg can receive inputs from the keyboard and mouse. To guarantee the USB packet delivered to the desired application, we can Re l world orklo ds enhance the Xorg server to understand USBFILTER rules. To better understand the performance impact of USB- The other example comes from USB networking de- FILTER, we generate a series of real-world workloads to vices. Though we have enhanced the general USB wire- measure typical USB use cases. In the KVM [24] work- line driver usbnet to pass the PID information into load, we create and install a KVM virtual machine au- each USB packet, unlike USB storage devices sharing tomatically from the Ubuntu 14.04 ISO image file (581 the same usb-storage driver, many USB Ethernet MB) saved on USB storage. In the Chrome workload, dongles have their own drivers instead of using the gen- we access the web browser benchmark site [5] via a USB eral one. Even worse, there is no general USB wire- wireless adapter. In the ClamAV [25] workload, we scan less driver at all. Depending of the device type and the unzipped Ubuntu 14.04 ISO image saved on the USB model, one may need to instrument the corresponding storage for virus using ClamAV. In the wget workload, driver to have the PID information, like what we did we download the Linux kernel 4.4 (83 MB) via the USB for rt2800usb driver. Future work will introduce a wireless adapter using wget. The USB storage is the San- new USB networking driver framework to be shared by Disk 16 GB flash drive, and the USB wireless adapter specific drivers, providing a unified interface for passing is the Ralink 300 Mbps wireless card. All time mea- PID information into USB packets. surements are in seconds except the Chrome workload, Another issue of using process table in USBFILTER where scores are given, and are divided by 10 to fit into rules is TOCTTOU (time-of-check-to-time-of-use) at- the figure. Figure 8 shows the comparison between the tacks. A malicious process can submit a USB packet two kernels when running these workloads. In all work- to the kernel and exit. When the packet is finally han- loads, USBFILTER either performs slightly better than the dled by the host controller, USBFILTER is no longer able stock kernel, or imposes a small overhead compared to to find the corresponding process given the PID. Fortu- the stock kernel in our test. It is clear that USBFILTER nately, these attacks does not impact rules without pro- approximates the original system performance. cess tables. When process information is crucial to the system, we recommending using USBTABLES to change mm r the default behavior to “drop”, make sure that no packet would get through without an explicit matching rule. In this section, we showed how USBFILTER can help administrators prevent access to unauthorized (and un- known) device interfaces, restrict access to authorized stem c ng devices using application pinning, and prevent data ex- USBFILTER is able to completely shut down any write op- filtration. Our system introduces between 3 and10 µs of erations to external USB storage devices, preventing any latency on USB packets while checking rules, introduc- form of data exfiltration from the host machine. Sim- ing minimal overhead on the USB stack. ilarly, one can also write a “block scsi read” LUM to stop read operations from storage devices. Nevertheless, sc ss on this LUM may not be desired or work as expected in re- ality. To correctly mount the filesystem in the storage rocess le device, the kernel has to read the metadata saved in the storage. One solution would be to delay the read block- We have successfully traced each USB packet to its orig- ing till the filesystem is mounted. However, for perfor- inating application for USB storage devices by passing mance considerations, the Linux kernel also reads ahead the PID information along the software stack from the some data in the storage, and brings it into the system
12 426 25th USENIX Security Symposium USENIX Association cache (page cache). All following I/O operations will s l t ss es happen in the memory rather than the storage. While memory protection is out of scope for this paper, we rely To write USBFILTER rules, one needs some knowl- on the integrity of the kernel to enforce the MAC model edge about the USB protocol in general, as well as it applies. Write operations, even though in the memory, the target USB device. The lsusb command under Linux provides a lot of useful information that can di- will be flushed into the storage, where USBFILTER is able to provide a strong and useful guarantee. rectly be mapped into rule construction. Another tool usb-devices also helps users understand USB de- vices. Windows has a GUI program USBView to vi- cket An l s s rom e ces sualize the hierarchy and configuration of USB devices plugged into the host machine. While users can write Because of the master-slave nature of the USB proto- some simple rules, we expect that developers will pro- col, we do not setup USBFILTER in the response path, vide useful LUMs, which may require deep understand- which is from the device to the host, due to performance ing of the USB protocol and domain specific knowledge considerations. However, enabling USBFILTER in the re- (e.g., SCSI, and will share these LUMs with the com- sponse path provides new opportunities to defend against munity. We wll also provide more useful LUMs in the malicious devices and users, since the response packet future. could be inspected with the help of USBFILTER. For ex- ample, one can write a LUM to limit the capability of a HID device, such as allowing only three different key Rel ted ork actions from a headset’s volume control button, which is implemented by GoodUSB as a customized keyboard Modern operating systems implicitly approve all inter- driver, or disabling sudo commands for unknown key- faces on any device that has been physically attached boards. Another useful case is to filter the spoofing to the host. Due to this, a wide range of attacks have DNS reply message embedded in the USB packet sent been built on USB including malware and data exfiltra- by malicious smart phones or network adapters, to de- tion on removable storage [15, 34, 46], tampered device fend against DNS cache poisoning. We are planning to firmware [27, 7], and unauthorized devices [1]. These investigate these new case studies in future work. attacks fall into two major categories: those that involve data ingress and egress via removable storage and those that involve the attachment of unknown USB interfaces. l c o s r ers nd Proposals for applying access control to USB storage o ert nnels devices [12, 28, 38, 48] fall short because they cannot guarantee that the USB write requests are blocked from While BadUSB is the most prominent attack that exploits reaching the device. Likewise, defenses against unau- the USB protocol, we observe that using USB communi- thorized or malicious device interfaces [41, 33] and dis- cation as a side channel to steal data from host machines, abling device drivers are coarse and cannot distinguish or to inject malicious code into hosts, is another tech- between desired and undesired usage of a particular in- nically mature and plausible threat. On the Linux plat- terface. Another solution employed by the Windows Em- form, with the development of libusb [14], more USB bedded platform [26] binds USB port numbers with the drivers run within user space and can be delivered as bi- VID/PID/CID (device class ID) information of devices naries. On Windows platform, PE has been a common to accept/reject the device plugged in. While CID helps format of device drivers. To use these devices, users limit the usage of the device, this solution does not work have to run these binary files without knowing if these for composite devices equipped with multiple interfaces drivers are doing something else in the meantime.4 For (with different CIDs). Besides, users may have to update instance, USB storage devices should use bulk packets the policy each time when different devices are plugged to transfer data per the USB spec. However, a malicious into the same port. Given the increasing ubiquity of storage driver may use control packets to stealthily ex- USB, this is not a sustainable solution. Guardat demon- filtrate data as long as the malicious storage is ableto strates a means of expressing a robust set of rules for decode the packet. This works because control transfers storage access but requires substantial new mechanisms are mainly used during the USB enumeration process. for operation within a host computer, such as implemen- With the help of USBFILTER, one can examine each USB tation within a hybrid disk microcontroller [45]. packet, and filter unrecognized ones without breaking the Netfilter [40] has become the de facto network fire- normal functionality of the device. wall standard on Linux due to its ability to perform 4N.B. that there are ways to instrument DLL files on Windows plat- fine-grained filtering on network packets between ap- form, though this does not appear to be commonly done with drivers. plications and the physical network interface. Netfilter
13 USENIX Association 25th USENIX Security Symposium 427 can prevent compromise of a program by preventing un- to discreetly introduce unknown functionality via USB wanted packets from reaching the process. Similarly, our while maintaining high performance. system can defend processes by denying USB traffic be- fore it reaches its destination. Furthermore, fine-grained filtering has been applied to Acknowledgements the usage of filesystem objects by applications [13, 35], This work is supported in part by the US National Sci- however, these filters take place after the host and op- ence Foundation under grant numbers CNS-1540217, erating system have enumerated the device and loaded CNS-1540218 and CNS-1464088. any device drivers. USBFILTER applies filtering at the USB packet layer, preventing unauthorized access to in- References terfaces regardless of whether they have been approved elsewhere. Since our system operates between the device [1] TURNIPSCHOOL - NSA playset. http://www. drivers and the USB host controller and traces packets nsaplayset.org/turnipschool. back to their source or destination application, USBFIL- [2] J. P. Anderson. Computer Security Technology Planning Study. TER can uniquely filter access to any USB interface. Technical Report ESD-TR-73-51, Air Force Electronic Systems Division, 1972. While USBFILTER working in the host operating sys- tem directly, other USB security solutions make use of [3] S. Angel, R. S. Wahby, M. Howald, J. B. Leners, M. Spilo, Z. Sun, A. J. Blumberg, and M. Walfish. Defending against ma- virtualization. GoodUSB [41] leverages a EMU-KVM licious peripherals. arXiv preprint arXiv , 2015. as a honeypot to analyze malicious USB devices, while [4] J. Bang, B. Yoo, and S. Lee. Secure usb bypassing tool. digital Cinch [3] separates the trusted USB host controller and investigation, 7:S114–S120, 2010. untrusted USB devices into two EMU-KVMs, between [5] Basemark, Inc. Basemark browsermark. http://web. which a gateway is used to apply policies on USB pack- basemark.com/, 2015. ets. By mitigating the need for additional components [6] A. Bates, R. Leonard, H. Pruse, K. R. B. Butler, and D. Lowd. for standard operation, be believe that USBFILTER is bet- Leveraging USB to Establish Host Identity Using Commodity ter suited for adoption within operating system kernels. Devices. In Proceedings of the Network and Distributed USBFILTER protects the host machine from malicious System Security Symposium, NDSS ’14, February 2014. USB devices, but there are solutions as well for exploring [7] M. Brocker and S. Checkoway. iseeyou: Disabling the mac- the protection of devices from malicious hosts. USB fin- book webcam indicator led. In rd USENIX Security Symposium (USENIX Security ), pages 337–352, 2014. gerprinting [6] establishes the host machine identity us- ing USB devices, while Kells [8] protects the USB stor- [8] K. R. B. Butler, S. E. McLaughlin, and P. D. McDaniel. Kells: a protection framework for portable data. In Proceedings of the age device by attesting the host machine integrity. th Annual Computer Security Applications Conference, pages Wang and Stavrou [47] suggest that a “USB firewall” 231–240. ACM, 2010. might protect against exploitation attacks but do not dis- [9] A. Caudill and B. Wilson. Phison 2251-03 (2303) Custom cuss the complexities of how such a mechanism could be Firmware Existing Firmware Patches (BadUSB). itHub, 26, designed or implemented. Sept. 2014. [10] Compaq, Hewlett-Packard, Intel, Microsoft, NEC, and Phillips. Universal Serial Bus Specification, Revision 2.0, April 2000. oncl s on [11] D. Diaz et al. The GNU Prolog web site. http://gprolog. org/. USB attacks rely on hosts automatically authorizing any [12] S. A. Diwan, S. Perumal, and A. J. Fatah. Complete security physically-attached device. Attackers can discreetly con- package for USB thumb drive. Computer Engineering and Intel nect unknown and unauthorized interfaces, causing de- ligent Systems, 5(8):30–37, 2014. vice drivers to be automatically loaded and allowing ma- [13] W. Enck, P. McDaniel, and T. Jaeger. PinUP: Pinning user licious devices access to the host. In this paper, we pre- files to known applications. In Computer Security Applications vent unauthorized devices from accessing a host with Conference, ACSAC Annual, pages 55–64. ieeex- plore.ieee.org, Dec. 2008. USBFILTER, the first packet-level access control system for USB. Through tracing each packet back to its associ- [14] J. Erdfelt and D. Drake. Libusb homepage. Online, http www libusb org. ated process, our system can successfully block unautho- rized interfaces and restrict access to devices by process. [15] N. Falliere, L. O. Murchu, and E. Chien. W32. Stuxnet Dossier. 2011. With a default deny policy for new devices, administra- tors can restrict connection of unknown devices using [16] U. I. Forum. Media Agnostic Universal Serial Bus Specification, Release 1.0a, July 2015. granular identifiers such as serial number. Our experi- [17] D. Genkin, A. Shamir, and E. Tromer. RSA key extraction via ments test USBFILTER using a range of I/O benchmarks Low-Bandwidth acoustic cryptanalysis. In Advances in Cryptol and find that it introduces minimal overhead. The re- ogy CRYPTO , Lecture Notes in Computer Science, pages sult is a host that is unresponsive to attacks that may try 444–461. Springer Berlin Heidelberg, 17 Aug. 2014.
14 428 25th USENIX Security Symposium USENIX Association [18] Hak5. Episode 709: USB Rubber Ducky Part 1. http: [39] The Information Assurance Mission at NSA. Defense against //hak5.org/episodes/episode-709, 2013. Malware on Removable Media. https://www.nsa.gov/ ia/_files/factsheets/mitigation_monday_3. [19] Hewlett-Packard, Intel, LSI, Microsoft, NEC, Samsung, and pdf, 2007. ST-Ericsson. Wireless Universal Serial Bus Specification 1.1, September 2010. [40] The Netfilter Core Team. The Netfilter Project: Packet Mangling for Linux 2.4. http://www.netfilter.org/, 1999. [20] B. Hicks, S. Rueda, L. St.Clair, T. Jaeger, and P. McDaniel. A Logical Specification and Analysis for SELinux MLS Policy. [41] D. J. Tian, A. Bates, and K. Butler. Defending against malicious ACM Trans Inf Syst Secur , 13(3):26:1–26:31, July 2010. USB firmware with GoodUSB. In Proceedings of the st An nual Computer Security Applications Conference, ACSAC 2015, [21] T. Hirofuchi, E. Kawai, K. Fujikawa, and H. Sunahara. USB/IP- pages 261–270, New York, NY, USA, 2015. ACM. A peripheral bus extension for device sharing over IP network. In Proceedings of the annual conference on USENIX Annual Tech [42] A. Tirumala, F. in, J. Dugan, J. Ferguson, and K. Gibbs. Iperf: nical Conference, pages 42–42, 2005. The tcp/udp bandwidth measurement tool. htt p dast nlanr net Pro ects, 2005. [22] IronKey, Inc. Access Enterprise. http://www.ironkey. com/en-US/access-enterprise/, 2015. [43] M. Tischer, Z. Durumeric, S. Foster, S. Duan, A. Mori, E. Bursztein, and M. Bailey. Users Really Do Plug in USB Drives [23] Jeremy Moskowitz. Managing hardware restrictions via group They Find. In Proceedings of the th IEEE Symposium on Se policy. https://technet.microsoft.com/en-us/ curity and Privacy (S&P ), San Jose, California, USA, May magazine/2007.06.grouppolicy.aspx, 2007. 2016. [24] A. Kivity, Y. Kamay, D. Laor, U. Lublin, and A. Liguori. kvm: [44] USB Implementers Forum. USB-IF statement regarding the linux virtual machine monitor. In Proceedings of the inu USB security. http://www.usb.org/press/USB-IF_ symposium, volume 1, pages 225–230, 2007. Statement_on_USB_Security_FINAL.pdf. [25] T. Kojm. Clamav, 2004. [45] A. Vahldiek-Oberwagner, E. Elnikety, A. Mehta, D. Garg, P. Dr- [26] Microsoft Windows Embedded 8.1 Industry. Usb filter (in- uschel, R. Rodrigues, J. Gehrke, and A. Post. Guardat: Enforcing dustry 8.1). https://msdn.microsoft.com/en-us/ data policies at the storage layer. In Proceedings of the Tenth Eu library/dn449350(v=winembedded.82).aspx, ropean Conference on Computer Systems, page 13. ACM, 2015. 2014. [46] J. Walter. Flame Attacks : Briefing and Indicators of Compro- [27] K. Nohl and J. Lell. BadUSB–On accessories that turn evil. Black mise. McAfee abs Report, May 2012. Hat USA, 2014. [47] Z. Wang and A. Stavrou. Exploiting Smart-phone USB Connec- [28] D. V. Pham, M. N. Halgamuge, A. Syed, and P. Mendis. Opti- tivity for Fun and Profit. In Proceedings of the th Annual Com mizing Windows Security Features to Block Malware and Hack puter Security Applications Conference, ACSAC ’10, 2010. Tools on USB Storage Devices. In Progress in Electromagnetics [48] B. Yang, D. Feng, Y. in, Y. Zhang, and W. Wang. TMSUI: Research Symposium, 2010. A Trust Management Scheme of USB Storage Devices for In- [29] PJRC. Teensy 3.1. https://www.pjrc.com/teensy/ dustrial Control Systems. Cryptology ePrint Archive, Report http://eprint.iacr.org/ teensy31.html, 2013. 2015/022, 2015. . [30] R. Russell. virtio: towards a de-facto standard for virtual i/o de- vices. ACM SI OPS Operating Systems Review, 42(5):95–103, 2008. [31] R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn. Design and Implementation of a TCG-based Integrity Measurement Archi- tecture. Proceedings of the th USENIX Security Symposium, 2004. [32] SANS Institute. Real World ARP Spoofing. http: //pen-testing.sans.org/resources/papers/ gcih/real-world-arp-spoofing-105411, 2003. [33] S. Schumilo, R. Spenneberg, and H. Schwartke. Don’t trust your USB How to find bugs in USB device drivers. In Blackhat Eu rope, Oct. 2014. [34] S. Shin and G. Gu. Conficker and Beyond: A Large-scale Em- pirical Study. In Proceedings of the th Annual Computer Secu rity Applications Conference, ACSAC ’10, pages 151–160, New York, NY, USA, 2010. ACM. [35] S. Smalley, C. Vance, and W. Salamon. Implementing SELinux as a Linux security module. NAI abs Report, 1:43, 2001. [36] J. Stewart. Dns cache poisoning–the next generation, 2003. [37] Sun Microsystems, Inc. and FSL at Stony Brook Univer- sity. Filebench. http://filebench.sourceforge. net/wiki/index.php/Main_Page, 2011. [38] A. Tetmeyer and H. Saiedian. Security Threats and Mitigating Risk for USB Devices. Technology and Society Maga ine, IEEE, 29(4):44–49, winter 2010.
15 USENIX Association 25th USENIX Security Symposium 429 A end
1 /* 2 * lbsw - A LUM kernel module 3 * used to block SCSI write command within USB packets 4 */ 5 #include
Figure 9: An example Linux USBFILTER Module that blocks writes to USB removable storage.
16 430 25th USENIX Security Symposium USENIX Association