Distributed Architecture to Enhance Systems Protection against Unauthorized Activity via USB Devices

Abstract

Cyberattacks exploiting Universal Serial Bus (USB) interfaces may have a high impact on individual and corporate systems. The BadUSB is an attack where a USB device’s firmware is spoofed and, once mounted, allows attackers to execute a set of malicious actions in a target system. The countermeasures against this type of attack can be grouped into two strategies: phyiscal blocking of USB ports and software blocking. This paper proposes a distributed architecture that uses software blocking to enhance system protection against BadUSB attacks. This architecture is composed of multiple agents and external databases, and it is designed for personal or corporate computers using Microsoft Windows Operating System. When a USB device is connected, the agent inspects the device, provides filtered information about its functionality and presents a threat assessment to the user, based on all previous user choices stored in external databases. By providing valuable information to the user, and also threat assessments from multiple users, the proposed distributed architecture improves system protection.

1. Introduction

Public and private institutions are constantly dealing with new cyberthreats and cyberattacks [1] intended to disrupt infrastructure sectors such as water, power, transportation, communication and health-care systems [2,3,4]. At the same time, according to [5], the use of USB drives to transfer data between systems is increasing.

The USB devices offer a large attack surface on computer systems, since they are affordable, accessible and require low interaction to install and use [6]. The USB-related attacks exist in multiple forms, such as USB Mass Storage devices that contain malware, smart drives that include malicious auto-run payloads or programmable Human Interface Device (HID), where malicious code is embedded in the device’s firmware and asks to install a hidden USB human interface, such as keyboard, mouse or other interface devices [7]. An example of the latter attack is known as BadUSB [8,9], which exploits an vulnerability in USB firmware by reprogramming the USB device to act as a defined HID and discreetly execute commands or run malicious programs on a target.

The BadUSB attacks can be prevented by adopting specific strategies, such as disabling USB ports on computers or disabling the Plug and Play (PnP) devices’ installation (i.e., disable all peripheral devices). However, these fixes permanently disable the USB capability and prevent new devices from being mounted. Additional efforts have been made to allow USB devices to be mounted only after a user verification. Previous work in [10] proposed a system protection agent that blocks USB devices’ installation and enables users to check and mount each device after being informed about its category. However, this proposal had the following limitations: (1) the filtering process is based on a short and less accurate vendor-defined Identifier (ID) and (2) the devices are presented to the user without any prior or distributed threat assessment.

This document proposes a distributed architecture to enhance system protection against BadUSB attacks. The architecture is composed of agents running in Microsoft Windows Operating System (OS) and a set external Database (DB). The architecture allows the intersecting of the installation of the device driver and presents the user with a local and remote threat assessment based on the identified functionalities of the HID. The threat assessment is carried out on the basis of information collected anonymously by other users.

This paper is organized as follows. Section 2 presents context and the related work. Section 3 details the proposed distributed architecture. Section 4 describes the implementation of a functional prototype and provides results. Section 5 draws conclusions.

2. Related Work

The USB is a communication standard [11], commonly used for connecting peripherals to computers. Introduced in the 1990s, the USB interface and protocol increased in popularity because it facilitated communication between peripherals and hosts [12]. However, according to [13], one of the major weaknesses of the USB protocol is its flexibility, and potential threats increase if the device is connected to other devices, networks or the Internet [14]. An infected computer might uncover confidential information or personal data, participate in distributed attacks against other computer systems [15], or it might sabotage computer-controlled industrial processes. As explained in [16,17], a regular user may plug a USB flash drive found on the ground into a corporate computer without knowing that it may be an infected device, ready to start an attack. USB drives may turn into a security threat when they are used to transport and spread malware such, as the worm Conficker, which impacted a set of computers in Manchester City Council [18,19], or Stuxnet, a computer worm conveyed in an infected USB thumb drive [20], intended to hit particular industry sectors [21]. An overview on USB-related attacks can be found in [22,23].

To classify malicious USB devices, the authors extended the categories defined in [24] and proposed the following updated list [10]:

1.

USB Mass Storage devices containing malware: consists of external USB storage that is used to inject malicious code to a computer. Examples can be found in [20,25]. If these devices are shared between multiple computers, the malicious code can be widely disseminated. Microsoft Windows allowed autorun by default, allowing automatic file execution, a feature that was later abandoned [26];

2.

U3 smart drives: These devices are similar to Mass Storage Devices but have a special partition that is recognized by Microsoft Windows as a CD-ROM. CD-ROMs can use the autorun feature to execute malicious code. If the U3 Thumb Drive runs a malicious autorun payload, then the intention was to harm the system by delivering malware [24];

3.

USB devices in the Middle (USBiM): a USB device that installs activity loggers in the host computer, such as keyloggers. Some of these devices are available as forensic tools [27]; however, other devices with malicious purposes fit into this category, such as printer loggers, or hardware USB sniffers. In [28], a proof of concept is presented, where a device is capable of achieving the same results as hardware keyloggers, keyboard emulation and BadUSB hardware implants;

4.

Denial of Service USB devices: USB devices intending to disrupt services. An example of Permanent Denial of Service (PDoS) hardware used in this type of attack is the USB killer [29] that uses the USB power lines to charge capacitors and, when fully charged, discharge high voltage (200 volts) over the data lines of the host device, permanently damaging any circuit board with no electrical surge protection. Another example would be [30] where attackers have compromised over 25,000 devices and used them to launch a Distributed Denial of Service (DDoS);

5.

USB with programmable HID consists of malicious code that is embedded in device’s firmware and requests a USB human interface. As pointed out in [31], this procedure provides unacknowledged and malicious functionality that lies outside the apparent purpose of the device.

The BadUSB attack can be included in the last category. As detailed in [8], this attack consists of a reprogrammed USB chip capable of emulating other devices. As explained in [16], unlike USB drives that cannot automatically execute code, HID such as keyboards do not require user confirmation, nor do they require USB autorun to be enabled in the target system. Thus, if a device is identified as a keyboard, it is automatically installed and may send a fast set of keystrokes intended to compromise the machine it is connected to. The authors in [24] presented a programmable USB device that is capable of performing the BadUSB attack by emulating a keyboard and typing out commands defined inside a script stored on the device. Another example is found in [32], where a USB device can be recognized on a computer as a keyboard and mouse. Current efforts have been made to tackle BadUSB attacks. Security software firms such as Symantec [33] proposed a set recommendations, while they do not provide an effective solution to this type of attack. The authors of [34] proposed protecting data against BadUSB attacks in corporate environments by using the cloud as a storage method to share information through the internet between company members. The defenses against BadUSB attacks can be categorized into two types: physical blocking of USB ports and software blocking.

In physical blocking, the attacker is not able to connect any device to the target system. Strategies for the physical obstruction of the USB ports may range from the simple filling of ports with epoxy resin [35] to commercial solutions such as [36], which deposit a lockable plug into the port. In [37], a simple adapter to physically cover the USB port is presented.

In the software blocking, USB ports are blocked by software/applications. The authors of [5] propose an application to block the system when a USB drive is inserted. However, while protecting against BadUSB, blocking the OS operations prevents the regular usage of the system as well. In [31], GoodUSB is proposed as a system that blocks any USB device and waits for user authentication before proceeding with installation; however, no further information regarding threat assessment is provided to aid the user decision.

In the previous work [10], the authors propose a system based on an agent that blocks PnP device installation on Registry and listens to OS events, waiting for device change notifications. The solution is available in [38]. For every device that is plugged or removed, the agent captures the event and then makes a new list of devices that are already plugged. If a new device is added, the agent obtains its vendor-related IDs to identify and notify the user about the functionalities before installing. The main limitations of this proposal are that it uses a short vendor-defined ID, which makes filtering procedures less accurate and effective, and there is no remote threat assessment to help the user choose whether to install the device or not.

The current paper proposes a distributed architecture that can be included in the software blocking category, addresses the limitations of the previous proposals, and thus enhances the system’s protection against BadUSB attacks. The proposed architecture is detailed in the next section.

3. Distributed Agent Architecture

The proposed architecture is presented in Figure 1 and is composed of computers, agents, an External DB, and, in case of a corporate environment, a Corporate DB. The computers have Microsoft Windows OS installed and the agents are applications installed in the computers. The External DB holds threat assessment information, which is available to all agents. In case of a corporate environment, the Corporate DB has a partial threat assessment information only related to corporate computers.

In case a USB PnP device, such as a keyboard, mouse or other, is plugged into a home computer (1), OS detects the device, overrides the driver installations and forwards information (2) to the agent. The agent (3) identifies the device functionality using information on the OS driver’s files.

Then, the agent requests a threat assessment from External DB (4), presents it to the user, and requests action prior to installation (5). In a corporate environment, the procedure is similar to one for the home computer, but it may use the two Threat Assements (TAs), one from Corporate DB (4) and the other from the External DB (5), prior to the installation on (6).

Figure 2 details the internal procedures inside each computer with an agent. First, when the agent starts, it blocks the PnP device installation on Registry (1), collects all the information of the devices mounted on the system, and inserts this in a list.

In step (2), the OS generates notifications for every action that occurs on USB ports. These notifications can be captured by overriding an event handler. If there is an event of device change (addition or removal), the agent collects a list of mounted devices on the system.

The mounted devices list is sent to the Agent (3), filtered and inserted in a Devices List. To allow other PnP devices by default, the agent automatically installs non-USB devices by retrieving the vendor-defined IDs (Compatible ID and Hardware ID) in a string format, and then matches this with USB and HID; if a match is found, the agent keeps the devices blocked.

In (4), the agent compares the new list of devices with the list obtained prior to the notification in step (2), to check if a new device was added. If a device is not found in the previous list from step (2), the agent requests functionality and threat assessment information (5).

The functionality information is obtained through the INF files, which contain information such as driver name and location, driver version information and Registry information [39]. Algorithm 1 presents the procedure used to collect the INF file path and Functionality Assessment. The agent searches for INF files on the system, which can be found on two separate folders in Microsoft Windows. The INF path is the path of the file containing the vendor-defined IDs of the device. The functionality is obtained by the string associated with the keywords class (class of the device), devicedesc (device description) and svcdesc (service description).

Algorithm 1: INF File Path/Functionality Assessment Algorithm (step 5)

Algorithm 2 presents the threat assessment procedure and user interaction. The manager performs a query regarding the External DB in order to collect a threat assessment for the device, and adds it to the list of devices. The result is obtained by searching the device using the vendor-defined IDs and retrieving the number of users that previously accepted the device, $U_A$, and the number of users that previously blocked the device, $U_B$. The threat assessment estimation is a ratio between $U_A$, and the sum of $U_A$ with $U_B$. In step (6), the agent lists all blocked devices and their respective threat assessment. The user may choose to install the device or declare it as a threat. If the user accepts a device (7), the agent proceeds with the installation of the driver, which requires the INF file path and vendor-defined ID of the device. The user actions are sent to the External DB.

Algorithm 2: Threat Assessment Algorithm (step 5) and User Interaction (steps 6 and 7)

4. Implementation and Results

The proposed distributed agent architecture was implemented as a functional prototype with the topology presented in Figure 3. The topology is composed of a corporate computer and a DB server. The corporate computer features an i7-6700HQ CPU, 16GB DDR4 2133MHz of RAM and 256GB M.2 SSD of storage capacity. The agent was developed using C# programming language and deployed in a Microsoft Windows 10 Pro Creators Update, version 10.0.15063. The DB server runs on a computer featuring an Intel Core 2 Duo, with 4GB DDR2 of RAM and a 125GB Kingston SSD. In the DB server, a WampServer [40] was configured with two MySQL DBs, a Corporate and an External DB.

When running and inserting USB devices, the agent presents an User Interface (UI) with two tabs: analysed devices and pending devices. Figure 4 presents the analysed devices tab, with the working devices on the system. Figure 5 shows the pending devices tab, with a filtered list of pending devices and their threat assessment from Corporate DBs and External DBs. In this tab, the User Experience (UX) enables users to accept devices or declare a threat, thus blocking the device.

The threat assessments provided by the Corporate DB and the External DB (presented in Figure 5, respectively, as “Corporate” and “Public”) aid users to take action based on previous classifications by other users. Thus, we assume that the higher the number of devices already classified, the higher the quality of the threat assessments presented to the users.

Multiple USB devices, such as network and Bluetooth adapters, mass storage devices, keyboards, and mouses, were connected to assess the performance of the proposed architecture regarding the time needed to find the device functionality. As an example, the set of devices presented in

Table 1. Performance results for some devices tested with ratio included.

Description	Name Obtained from OS	Agent Delay (s)(1)	Installation Delay (s)(2)	Total Delay (s) (3) = (1) + (2)	Delay Ratio (%)$\frac{\left(\mathbf{1}\right)}{\left(\mathbf{3}\right)}\times$100
Card Reader Writer	USB 2.0-CRW	0.56	1.59	2.15	26.04
Kingston DataTraveler Mass Storage Device	DataTraveler G2	0.54	4.45	4.99	10.82
TP-Link Network Adapter	802.11n NIC	0.58	2.03	2.61	22.22
Bluetooth Adapter	ISSCEDRBTA	0.80	1.06	1.86	43.01
Kingston DataTraveler Mass Storage Device	DT 101 G2	0.75	0.67	1.42	52.81

was tested. For each device inserted, the device name from the OS was obtained, and the agent delay (1) and the installation delay (2) was measured in seconds. The total delay (3) was determined by the sum of both delays and a ratio between agent delay (1) and total delay (3) was calculated.

From the set of tested devices, the agent spent between 0.56 and 0.8 s to find the functionality, corresponding to the time taken to install the device, which ranged between 10.82% and 52.81%. Thus, the additional delay introduced by the agent is considered to not affect the user experience. Further tests can be conducted to assess how much these delays vary when using other devices, operating systems or hardware.

5. Conclusions and Future Work

Security attacks using USB devices impose high risks to users and companies. In particular, the BadUSB attack allows attackers to inject a malicious set of keystrokes on the OS without the user’s knowledge.

This paper proposes a distributed system protection architecture against BadUSB attacks designed for personal or corporate computers running Microsoft Windows OS. This architecture uses software blocking to enhance system protection against BadUSB attacks and it is composed of multiple agents and external DBs. When a USB device is connected, the agent inspects the device, and provides filtered information about the functionality and a threat assessment based on all previous user actions, stored in external DBs. While the agent is running, all connected USB devices must be approved by the user before use.

A prototype of the proposed architecture was developed and tested. The filtered information presented in the user interface of the agent intends to aid users in the choice to either accept or block new devices and, from a set of USB devices tested, the additional delay introduced by the agent seems not to significantly affect the user experience.

The authors consider that this architecture should be available as an open-source project, and future work can address this. The UI/UX can be improved, and, taking the results of a system usability scale tool into account, the option to uninstall devices can be added, and the overall resilience of the distributed architecture can be enhanced by using a cloud server DBs.