Thursday, January 27, 2022

BadUSB, or There and Back Again

In that often misunderstood time between mullets and the switch to laptops without normal USB ports (I am looking at you, Apple), a traditional part of an on-premises pentesting was to grab all those USB drives you got from those many conferences you attended, wipe them to remove the informercials, white papers, and and other cruft, put a little script that would be called when the drive was automounted in a Windows or Mac (primarily Windows because it was easier), and then drop them on the parking lot of the company you are doing your engagement on.

The script was pretty simple: when run it would collect the IP, some computer info, and username. And then it would send that info to a collecting site (cannot call it C&C because it is not doing that much work), which would then parse all the info in a nice spreadsheet which you would then bring to your meeting with your customer as the list of users that may need some security retraining. After all, if a pentester can do that, so can a malicious attacker (are there non-malicious attackers?). It is a nice way to deploy a virus, or a program to help the attacker to get a foothold in the system.

Those were simpler times.

Talks were given and dongles were created to avert such an attack because, well, it was easier to buy them than asking IT department to push a group policy to disable automount. Or telling users not to mount any USB device they find on their computers.

But, we are talking about BadUSB! Yes, and it was first mentioned in 2014. The short version is that thanks to the typical development methodologies similar to those used in IoT development, namely get a product out there as quickly and cheaply as possiblw with complete disregard to supply chain security or security testing in general, a lot of USB devices are built on controllers which can be reprogrammed in the field. And reprogrammed they are, this time carrying malicious payloads like programs to spy on the user or get a foothold on the system.

Sounds familiar? I think so. Adding your code to the USB device's hardware to it is but an evolution of the principle of having code in a USB drive that is run when it automounts.

Fast forward almost a decade and we begin the year with the FBI sending warnings about this new attack vector called BadUSB that groups like FIN7 created to deploy ransomware even though they have been doing that for many years now.

There is no one-size-fits-all technical solution for BadUSB, not that have stopped vendors peddling software to address it. We will go over detailed a plan of action to minimize the effectiveness in a future article, but it sufices to say the old adage of "select your partners and wear protection" still applies. Also, end users are one of the most important lines of defense in the security domain. Work with them, empower them to understand and make the call; it can work if you do it right. Make the presentation enjoyable and memorable. I mean, if I could make that work at a medical institution to the point our box of found USB drives had to be replaced with a bucket, so can you.