Abstract

Human Interface Devices attacks are as powerful as disregarded. In this article, we'll define the foundations of this family of attacks, the underlying concepts, and why this kind of attack can be a game changer for a successful intrusion test.

What is HID

HID stands for Human Interface Devices. It is a full class of devices thought to model the interaction between the User (that's why Human...) and the computer. In this class of devices, one finds keyboards, mice, trackballs, controllers, and the like. A good description of this family of devices and the underlying protocols can be found on the Microsoft website, although a very in-depth knowledge of the technology is not crucial for our purposes.

The key aspect to understand here is that the devices belonging to this class are thought to be used by a human. Somebody in the long story of hacking (who? I never knew this - but once again, it's not crucial for our purposes) has thought to create a more evil version of such a device: a "thing" that emulates a keyboard disguised into other devices, like an "innocent" usb stick. These objects can be programmed to inject a predetermined string as if it were written directly in the host's keyboard - the attack scenarios are obvious! The concept behind these tools make them OS independent. As long as the system can be influenced by the behaviour of a keyboard, this attack can be mounted, at least in principle. The most effective defence is, in fact, disabling USB input, or whitelisting only given devices - but the majority of computers that we find around don't implement this measure. This is a very fortunate situation for us, innocent testers paid to violate the corporate networks!

The first and most famous Bad USB stick is Hak5's Rubber Ducky; but many other solutions can be found on the market. However Hak5 has created a standard, the scripting language that is used to code the payloads.

In this series of articles, we will go deep in the anatomy of a HID attack, we will learn the Duck Script, and we'll devise some real case scenarios.

Attack scenario 1: slashing bunnies with an axe

You have been engaged to test the security posture of the ACME company. WLOG, we can assume that:

• The company belongs to any industry.

• Size of the company: another invariant aspect. To fix the ideas, we'll assume it's a small company (e.g. 10 to 50 heads)

• Structure: Let us assume that we are not attacking a corporation; for sometimes corps have a more structured security program that could block our attacks, especially if the company works into intellectual property, or finance.

Our target will obviously be a naive employee. Our objective is obtaining a foothold in the company. How nice would it be having - say - a machine inside the target network that spawns a reverse shell every time it's turned on? Remember that a reverse shell usually leverages the HTTP protocol, and that quite often internal firewalls are configured not to block HTTP communication generated from within the corporate network.

Well, by the mean of a successful HID attack, we could obtain such a thing.

Suppose that just in front of the company's main building, on a sunny morning, a kiosk pretending to give everybody the opportunity to win a brand new iPhone (or Flat TV, or a trip to Bora-Bora, or whatever sounds expensive and juicy). The only thing that the participant needs to do is to answer to a survey, contained into [what looks like] a usual USB stick. Plus, the USB stick also remains to the participant!

Yay, double victory.

Chances are that some of the potential participants will try immediately when they reach their office to run their race and - guess what? They have already opened their defences to you! And now, from the machine on the internal network, you have your so-much-coveted reverse shell..

Another innocent bunny sees the axe!

Why is this type of attack successful? Basically, the crucial point is that the computer blindly trusts the human interface device and the operator. This aspect is crucial because it is a structural one, so the effects reverberate strongly.

Concerns and points of attention

For the time being, let's assume we have a fair understanding of how the Bad USB attack works: shortly put, one plugs an USB device in, the device "does the magic", and boom! You're in.

Actually there is a lot more to this, and there are some points of attention that must be considered; such as:

• typing speed: would this introduce problems?

• visibility: the largest part of commands issued by keyboard has also some visual output. How to manage this?

• OS: do we know which OS runs on the target machine? What if it is not what we expected?

In principle, typing speed should not be an issue, meaning that the USB stick is obviously faster than a human being, at writing. This may induce problems, for the output of a given command may take some more time than the expected. There is no human patrolling, and the stick may not know when the previous command is finished. Long story short: caution must be taken when designing payloads; trials and errors will be the usual way of developing.

Hiding the output of commands is another crucial aspect to our attack, because we want to be stealthy. We shall show how to obtain this ninjutsu when introducing the Ducky Script.

OS: this is less problematic than it seems, and we'll address also this topic in a further stage.