can USB ports be password secured?

[jiml8]

I've been thinking about the "evil maid" threat, as well as the fact that it has been shown that USB thumb drives can be infected with malware at the firmware level. Seems to me, a good way to mitigate both threats is by requiring a user to enter a password within a set number of seconds after a new device is plugged into a USB port.

If the password is not entered or is entered incorrectly, then a predetermined action could be taken (disable USB inputs, shut down system, ignore this USB device, or some other choice).

This seems to me to be obvious enough that someone must have already done it. If no one has done it, I am inclined to do it.

So, does anyone here know if someone has done this?

Oh...and for those who don't know...the "evil maid" threat is where you leave your laptop on standby in the motel room while you go down to the bar. The maid enters, plugs a USB thumb drive into your laptop, and installs a keylogger or other malware. Variants of this have it happening to your desktop while you are out of the office at the coffee machine, or to your laptop at any time when your attention is distracted for a few minutes.

[doktor5000]

Well, evil maid is pretty old - you did read about badusb? There's no protection for that one so far
https://srlabs.de/badusb/
https://github.com/adamcaudill/Psychson
https://nakedsecurity.sophos.com/2014/1 ... tructions/
http://www.wired.com/2014/07/usb-security/



For your original question, you would need to rewrite some default udev rules.
Not sure about the default rule for all usb devices, or if there's even such a rule, but good bet would be /usr/lib/udev/rules.d/50-udev-default.rules
Or check via grep -l -i usb /usr/lib/udev/rules.d/*rules

Maybe you can get away with overwriting all those with some catch-all rule ( /etc/udev/rules.d/01-catchall-usb.rule should work and trigger before all other rules, IIRC)
that will trigger for all USB bus devices and assign them 000 permissions, unless some code is entered when device is plugged in.

Some further documentation:
http://www.opensourceforu.com/2012/06/s ... -examples/ (including some rules to block all usb ports and similar stuff)
http://stackoverflow.com/questions/1281 ... dev-script
https://wiki.archlinux.org/index.php/ud ... USB_insert (probably won't help as udisks is only about block devices AFAIK)
http://www.reactivated.net/writing_udev_rules.html

[jiml8]

Yes, a udev rule to invoke a program or script would seem to be the way to do it. My question was whether it already existed.

I am aware of the badusb problem, which I mentioned in my original post, though I did not call it that. That bad.sh script that you linked to is actually quite illuminating, but I think password-protecting the USB ports the way I am thinking of would protect against this threat in at least many circumstances. Certainly it should protect against a device changing its nature after being plugged in and recognized; the change would have to be recognized as a new device, which would invoke the password prompt again - and which would take whatever protective action was specified when that password was not entered.

Also, granting the bad.sh script is only a proof of concept, any system equipped with a properly functioning firewall should not be vulnerable to this particular script.

[doktor5000]

Yes, a udev rule to invoke a program or script would seem to be the way to do it. My question was whether it already existed.

The first page linked has a pretty similar example:

Selectively allow USB block devices via a custom program

Code: Select all

BUS=="usb", SUBSYSTEM=="block", PROGRAM="/bin/usbc.jar", RESULT!="my", OPTIONS+="ignore_device"

If the output generated by the program is equal to the ‘my’ value that is specified, then allow the USB device; if the output is anything else, then ignore the device.

You can probably quickly whip up some simple zenity dialog asking for the password, or use something more sophisticated.

[jiml8]

Actually, I have been looking at some of these other badusb links you provided, and I guess I don't agree that this situation cannot be defended against.

I'm quite sure I could modify the USB drivers to secure against this. It would require a userspace interaction in the detection process, which would somewhat bastardize the kernel.

Basically, after the southbridge interrupt that signals to the processor that a usb device has been inserted, the kernel activates the core usb driver which interrogates the device to find out what it is, then loads the appropriate driver to handle that type of device. Intervening after device interrogation and prior to any further driver startup to get user approval for this device would stop any evil device in its tracks, so long as the user has the wit to realize that this requester is telling him that the device is idenfitying itself as - for instance - a keyboard, when he has actually plugged in a thumb drive.

So the logic goes like this: 1. user plugs device in. 2. usbcore driver detects device, and makes userspace request for approval to attach device, while reporting exactly what the device says it is. 3. User approves. 4. usbcore driver starts driver appropriate for device type and, and system proceeds. If user does not approve, then one of several things happens: (a) usb port is disabled until device is unplugged; or (b) system is shut down; or (c) USB inputs are disabled; (d) system sounds audible alarm of intrusion attempt; or (e) something else.