Potential solutions for PHUKD

Hello,
I'm performing a research about novel attack vectors, and I came across Adrian Crenshaw's very clever use of a HID to attack a (seemingly) well protected PC. The gist of it is that you can identify a dedicated piece of hardware as a HID (a regular keyboard), record data (scripts, whatever) to output in said hardware, and have it output the data as actual keyboard keystrokes into the computer. Read more about it here.

Assuming a computer has been hardened, and no USB devices other than, say, a keyboard, mouse and printer have been allowed to interface with the computer in any way, using the PHUKD is a very effective way to attack the system, seeing as you can't really protect a system from its primary source of input.

Additionally, a piece of hardware such as PHUKD could extract data from a system with relative ease. Even if the PHUKD isn't recognised as a mass storage device, one could, for instance, "write" a program on the system, which transmits binary data through "caps lock morse", that is, interpret binary data, and send it out as caps lock presses. (A keyboard knows that it has caps lock on because the computer continuously tells it so) The PHUKD could then interpret the caps locks as binary data and save it in internal storage. Additionally, one could simply "write" the data to the HID driver, but I consider this relatively trivial to block.

Getting to the point, I've been thinking of ways to defend a system from a PHUKD style attack. So far, I've come up with several possible solutions, each with their own key flaw:

1) Statistical analysis of input and output: One of the most obvious, yet without a doubt the most challenging, manner I could think for protecting a system from malicious HID is to perform statistical analysis of the user's input behaviour, with the goal of recording and analysing activity times and typing patterns.

This is problematic, however, because a PHUKD can be very flexible. One could attempt to mimic regular user keyboard activity in that information isn't typed robotic-ally, with equal intervals between keystrokes. Furthermore, one could perform some simple social engineering (as shown on the article) and perform the initial attack during a victim's active hours. Furthermore, such form of defence might be a major inconvenience to the user. The more rigid a defence one might put up in statistical analysis, the less accepting a system would be to any users other than its regular user. This downside is further emphasised when it comes to multi user systems. In such cases, statistical analysis might never actually formulate an actual user activity pattern, rendering the whole approach totally useless.

2) Standardisation for keyboard hardware: In this approach, all keyboards would have to be digitally signed, in some manner which can't be counterfeited. I'm thinking something along the lines of an interface with a smart card, going maybe as far as having to "log in" to a keyboard before you can use it, and have the HID drivers force a keyboard to authenticate with the OS prior to interacting with it.

The downsides for this approach is that creating a new line of "secure keyboards" doesn't sound like it can happen in the near (or distant) future. Additionally, said keyboards might be hackable, rendering them rather pointless (obviously, the smarter a system is, the more attack vectors it opens up to itself).

Anyway, this is all I could come up with, in order to protect a system. A combination of these two forms of defence MIGHT prove to be effective to slow down a PHUKD attacker and even reveal a sloppy one at that.

What do you guys have to say about this? I'd be very happy to hear comments and suggestions.

Hi, and welcome to AO,

The subject of hardware security risks and potential attack vectors has been discussed on this forum before.

The simplest remedy is to use a laptop and secure it when not in your physical possession.

Now, let's look at some real life reasons why this sort of attack is totally impractical?

1. You would need fairly sophisticated electronics engineering skills, as you would have to modify the keyboard hardware. That is not as easy as it seems as nobody ever learns how to repair them or how they work.........you just replace them when they go wrong. You would also need a good knowledge of firmware programming and implementation.

2. You would need to know the exact make and model of keyboard, as even the most moronic of users is likely to notice if it changes without them complaining several times to IT support (that's real life!:D).

3. Even if you could find that information, it doesn't take long for a keyboard to get personalised.............little marks, coffee stains, sticky keys. This one, for example has half of one character symbol missing and no legs, just two port wine corks superglued to its base, and one of the rubber feet is missing so it has a slight but very distinctive wobble. Please do not underestimate how observant people are if they think that someone has been messing with "their" computer or keyboard!

4. All of #2 and #3 would require physical access, as would substituting the keyboard........and just how would you get that past the scanners? It would have to be an inside job by someone authorised to be in the right place at the right time. Anyways, as I look at the 4 keyboards around me, there is only one you would have a hope of recognising the maker (it says "Logitech" on it), and without that information, how would you find a replacement to modify?

5. What about physical security measures such as surveillance cameras, access control, and the good old lock and key. For example, when I worked in the defence sector, you removed the removable HDD caddy from your PC and locked it in a secure, fireproof safe, then locked your office/project room door..........even to go for a p1$$. :eek: In case you are wondering, you cleaned your own office.

Another one I have used is the employee tracking device..........your location and movements are logged when you pass through an access control point. In that case the issue wasn't security but employer's accountability in case of a fire or other emergency, but the principle holds.

6. Such an attack would have to be targeted, so that would greatly narrow the opportunity for access. It isn't like dumping a poisoned stick drive in the parking lot ;)

7. How would you get the data out?.......other than repeated physical access, which I have already mentioned, it would have to be through WiFi, which is currently detectable, or through the network, which should be monitored. I also wonder if the device would show up as being in promiscuous mode?......probably not?

All taken into consideration, I would say that the "risk" lives in the minds of those in ivory towers rather than in the real world.

Now, where do I see more serious hardware attack vector risks. Well, just about all your peripherals have firmware that can be flashed.........I know that there is supposed to be "secure" hardware, but I still wonder?

The advantage that would have is that it could be done remotely or with no physical signs............difficult if external media are disabled? And you wouldn't need to be an electronics engineer.

There still remains the problem of avoiding traffic detection though.

Just a few thoughts :)

P.S. I know that you can purchase physical keylogging boards, but they wouldn't match what they replaced, and they are quite easy to detect.

EDIT:

On further reflection, the device is really only a keylogger with possibly screen capure capabilities. Depending on the environment it would probably take a very long time to gather anything useful, particularly as you wouldn't know what the target was going to be looking at or working on at any point in time?