Endpoint DLP: Is hardware access control enough?

I’ve stumbled on this article about using a custom-built hardware to bypass hardware enforcement on most DLP solutions available on market.

The solution uses an Atmel’s AVR microcontroller (the same on the Arduino‘s I’ve been playing around lately) and the V-USB library to create a virtual USB device and is crafted to announce itself as HID (Human-interface device). What common hardware fits this description: the keyboard. As you are not likely to forbid keyboard access to your users (or else they wouldn’t be able to type and thus work), this will gracefully pass through many enforcements.

The HID protocol allows bi-directional communication and this makes a perfect vector for data transfer.

The HID protocol allows communication in both directions by sending and receiving reports and feature requests. I’ve utilised this control channel to allow the PC to transfer files over the HID protocol to the device (…)

Thomas Cannon (the article author) had made experiments with a USB drive and other with an micro SD module attached to the custom-built hardware in order to store the transfered data since the AVR internal memory is quite short (maybe it’s fine for Bill Gates).

White-listing

While I’ve already seen some DLP solutions enforcing pendrives accesses through its vendor and model, I dunno if some had already made a way to enforce a unique fingerprint for each device (maybe yes, sounds feasible).

Can you trust drive signatures? What about the data they traffic?

What if drives signatures cannot be trusted anymore? We are left with the only enforcement left at input level: data monitoring.

Network IPS/IDSs are employed to detect (and sometimes stop) rogue data running on wires. Application IDS/IPSs are employed to detect (and sometimes stop) rogue data that come over inputs. Why not deploy IDS/IPSs at HID level? They are inputs, aren’t?

Suppose you have the latest DLP solution blocking all your USB drives, CD drives, Floppy drives, ZIP drives, iPhone etc etc. You also have all your network connections, email servers, HTTP traffic monitored.

An badly intentioned user won’t be able to upload malware through the drives nor download from web or network but what would stop him from actually TYPING the payload into notepad? Every hex or worse, every bit? Yes, sounds crazy and would take lots of time but hey – never doubt a determined person.

Things can be automated

Ok, so you think ‘Hey Jan, this would never happen, you are crazy. It would be very very very hard to keep track of every 0 or 1 typed’. Sure, I completely agree. The AVR-based hardware thus, does not.

This little beauty needs a piece of code on the host machine to make the data transfer possible so it has a stage where you simply open a notepad and the microcontroller (since he is actually a keyboard) will type it for you! Wow, zero work huh?

Seems that Moore was right after all

There are lot of microcontroller kits like BasicX, Arduino, Parallax and Pololu, just to name a few. Earlier at the São Paulo’s Hackers to Hackers Conference (H2HC) I’ve seen people using and R/C quad-copter holding an embedded system to crack WEP keys. Now we have a ‘robot-keyboard’.

Hardware is getting cheaper, fast as hell. A system is as secure as the complexity need to crack it. Cheaper hardware, more processing per second, greater the complexity has to be.

I wouldn’t be surprised if the next hackers cracking machines will be actually, machines.

Contents

comments powered by Disqus