Nicholas Zahansky
November 15, 2022

While I was in school, there was an interesting device I had discovered that allowed for keystroke injections. While this sounds dangerous, and it can be in the wrong hands, what piqued my curiosity about the device was that it would allow me to automate tasks even though I had little to no experience in scripting at the time. I set out to purchase the device known as the Rubber Ducky, and within short while after receiving had written a script that would back up specific folders to a USB drive.

At the time I remember thinking to myself about how dangerous this device could be because it acted just like a keyboard. Plug it in and it would start typing the characters that you programmed it to type. One keyboard shortcut and it could easily open a shell or command prompt to start typing out commands with whatever privileges the user logged in had. Since it was mimicking a normal keyboard, there were really no ways in which to stop this kind of attack from taking place. It wasn’t until later in my academic career, after gaining some more knowledge, that I began making connections on how to stop an attack that exploited the inherent trust of human interface devices such as keyboards.

My first and foremost thought, was to solve the problem with administrative policy. A policy that prohibits users from inserting unauthorized devices into workstations or other machines is a good start but, that only goes so far. While this is a great deterrent, the second someone decides to ignore policy or someone outside the organization with one of these devices gains physical access to a machine, that policy does nothing to protect the organization.

My next consideration was to solve it via technical means. Shutting down ports that were not being used by an existing device would surely lower the attack surface by preventing any unsuspecting personnel from plugging in the device. However, that would not prevent someone from unplugging a keyboard or mouse plugged into an enabled port and swapping it with the duck.

Another safeguard that can be used came to me while visiting a friend in the hospital. Immediately drawn to technology, I noticed each room was equipped with a workstation for nurses and doctors to get or enter information. However, there was no physical device, just a monitor, keyboard, and mouse. Underneath was a locked door which I assumed contained the physical machine. Aha, I thought. This was a surefire way to prevent someone from connecting the infamous rubber duck. Except it is not. Locks can be picked, and keys can be stolen.

The problem with all the aforementioned solutions is that they assume that external USB devices are not a business need. Furthermore, even though using each together hardens our defense against this particular attack by using administrative, technical, and physical controls, they all work on one level of a much larger system. Rather than rely on any one of these solutions or any combination thereof, we should assume a determined attacker will find some way to connect the device and look deeper into our defense in depth arsenal to solve the problem.

We can leverage things like least privilege to ensure that if a system is compromised using this attack, the attack can only go so far. We can utilize network segregation to prevent more critical assets from being exposed and we can use IDP/IPS to detect anomalous behavior that sends an alert or disconnects a suspect machine altogether.

The bottom line is that it can take many controls, across many different layers to provide a suitable solution. While risk will never be zero, the different layers act like outfielders backing up infielders in a baseball game. If the ball is missed, the outfielder is there to scoop it up. Except in our case, we tend to rely on more than just one layer of outfielder.