It has long been known that locking down USB mass storage devices can improve the security of a system, but we can’t very well go around blocking keyboards. This can present an issue for organizations and individuals who are security conscious. Now the attacker can achieve anything that would be possible while actually using a keyboard, but at much greater speeds than humanly possible. So despite the fact that what the ducky actually contains is a micro-SD card, the host will see keyboard input and treat it as if it were any other keyboard.
#USB BLOCK ERUPTORS CODE#
We can see that the bInterfaceClass code is set to 0x03, which will cause the host to see this as an HID. The capture shown above is from one of the ducky devices I used to do my testing. As mentioned before, the only thing that prevents a device from misrepresenting itself is the manufacturers desire to produce working devices, and in the case of the Rubber Ducky the manufacturer intentionally programmed the device to misidentify itself as an HID. The USB Rubber Ducky takes advantage of the trust that the host has for the descriptors that are sent by the USB device. The host now knows that this is a mass storage device, and it can handle mounting and file transfers accordingly. This is a well behaved USB drive, and it identifies itself correctly using bInterfaceClass code 0x08. There is a lot of information exchanged to ensure that the device gets everything it needs from the host, but we are specifically interested in the highlighted line. The host then requests the device’s configuration descriptors, which will be used to define the capabilities of the device. The device responds, and here we can see the idVendor and idProduct descriptors being exchanged. The device is plugged in, and the host makes a request for the descriptors of that device. A typical process for a USB drive can be seen in the images below: Because most manufacturers want to make devices that actually work, it is in their best interest to make sure their devices identify themselves correctly. For example, if a USB storage device sends a bInterfaceClass descriptor which identifies itself as a printer, it will not show up as a USB drive that users can save files to. If it does not do so, the device will not work as intended. Usually when a USB device is plugged in, it will correctly identify itself as what it really is. There are many, and a complete list can be found on the official USB Implementors Forum website, but for now we are concerned with only two: 0x08 which defines a device as USB mass storage, and 0x03 which defines a device as a Human Interface Device (HID). bInterfaceClass is used to identify what type of device was just plugged in. This is not used by the host beyond labeling purposes in most cases. As you might expect, the idProduct and idVendor descriptors are used to identify the manufacturer and specific device that has been connected. There are three main descriptors that we will want to become familiar with: idProduct, idVendor, and bInterfaceClass. Now there are a lot of USB descriptors defined within the protocol, but we do not need to go into all of them to get a general understanding of what takes place and how the USB Rubber ducky abuses the process. At a high level, when a device is plugged in to a host the host will see that there is something now connected and query the new device for its USB descriptors. This is what allows for new devices to be connected and accurately recognized for what they are. The USB protocol is essentially the agreed upon language that USB devices and hosts use to communicate and set up a connection. If you would like to skip the background information, scroll down a bit to find the actual blocking methods. I will start by talking about the USB protocol itself and how that lead me to the methods I came up with.
The method can easily be expanded to mitigate against other badusb devices as well. This post if going to focus mainly on my own research as part of the team and what I discovered in regard to blocking the USB Rubber Ducky. Please check out Olivia Gallucci’s blog ( January 29, 2021: RITSEC Hak5 Rubber Ducky Research Presentation) if you would like to see what the group worked on as a whole.
#USB BLOCK ERUPTORS HOW TO#
We all approached the project from different angles, and as a result we learned a lot about how to perform attacks, different attacks that were possible, and some possible mitigations. I recently had the pleasure and good fortune to work with a small group of my peers in exploring the HAK5 USB Rubber Duc ky as a part of the RITSE C mentorship group.
And other badusb mitigation with udev rules and Group Policy
0 kommentar(er)
