This is pretty much the way a Yubikey or other 2FA token works, no? The only difference being that it doesn't send the text until the sensor is covered.
It's one way a Yubikey can work: Yubikey one time password (OTP). The more common (I think? Newer and standardized at least) way (U2F) accesses the key over some other method that doesn't have it act like a keyboard. There are other operation modes for Yubikeys, but personally I only use U2F and the CCID (aka act like a smartcard) modes.
You could require confirmation before accepting a new input device. This could be done with out of band signaling (such as a button on the computer itself that you push to say “yes, I want to use this keyboard”) or you could do it by requiring the user to type in a secret (such as their login password, or even just a PIN displayed on the screen) to enable it for other uses.
I don’t know that people would accept this inconvenience, though.
All kinds of legitimate (well, this is legitimate too really, it's just weird) devices have similar behaviour, and in their cases it's what the user expects and wants.
On all new and old versions of all major operative systems out there you'll be able to plug in any standard USB keyboard, and it'll start working automatically.
That's exactly what's happening there, but the "keyboard" is pre-programmed to enter keys presses automatically in a way that makes a website pop up.
As has been pointed out, you couldn't block this kind of thing without blocking USB keyboards altogether.
I wonder what it would look like to have a background program that would detect and intercept any newly connected device by default, give it a fake (VM?) environment, and log everything it tried to do to the screen while prompting to ask if you want to let it into the "real" system. Obviously this is what security professionals do manually, but I'm talking about a totally transparent and automatic version that could be left running all the time.
My thought was that it would be an excellent, low knowledge way of figuring that out. For example, if it said type "qwerty" and it came through as "azerty", that would get you 95% of the way to having a fully functional keyboard. Mapping out the requisite keys needed to fully identify the keys could probably be done with a fairly short number of key presses for 99+% of likely keyboards.
For this case, I am assuming that the keyboard and os language are fairly compatible, at least translatable.
I used to do the other way around, and disable all my ports until I knew I needed to use one.
Of course, there's always the possibility that I unlock my port and plug in some infected USB of my own volition and it's much more likely than some random person plugging something in.
But, anyway, this thing presents as a keyboard, not a storage device.
I thought about disabling ports, and on some machines I do, but for the most part there would be mutiny if people couldn't charge their phones or use USB sticks for legitimate purposes. I try instead to make sure everyone is skeptical and weary of everything technology related+the corporate network.
I'm in the process of creating a USB drop-test script for employee training purposes. Awareness and preparedness training has been one of my best investments of time and energy with a staggering ROI. My team recently passed my last phishing test 100%.
For phone and device charging, go purchase a bunch of reputable 2 - 4 port chargers and cables and set a policy that phones at other devices should never be plugged into computers. If you want to really dissuade people, add to the policy that the full contents of any phone plugged into a company computer may be silently downloaded and examined by IT.
If the corporate network you're talking about is Windows Active Directory based then I believe that there are Group Policy settings to only allow connection of encrypted external drives. I'm not sure when this was introduced, and it might only be on Windows 10, but hopefully at this point most businesses are either already there or moving in that direction.
The problem is a lot of manufacturing equipment is either not networked, or not networkable. A lot of equipment relies on USB interfaces to load/store programs. Disabling USB ports across the board is not practical.
And with some of the crazy hardware[1] out there for retrofitting antique equipment with modern functionality; blanket encryption is not always possible either. The cited USB emulator requires that the USB stick be formatted into hundreds of minuscule FAT partitions, simulating floppy disks images and all the documentation comes in one language: Engrish. After that the machines will only load programs that follow a certain naming convention/format/ect...
[1]http://www.gotekemulator.com/
So the choices for many organizations are;
a) upgrade dozens of custom pieces manufacturing equipment so that they're securely networkable at astronomical cost (if it's even possible).
b) Air-gap all the old scary stuff running on ancient OSs & proprietary PLC drivers from god-knows-where and only talk to them via USB/direct interfaces and worry about them when they break.
On my Macs, when I try to connect a new Bluetooth keyboard, the system pops up a dialogue asking me to type a randomly-generated passcode before it'll accept any further data from the keyboard.
But it just completely trusts any USB device I plug into it to do whatever. I wonder how much work it would be to have it ask for the user to type a randomly-generated passcode before accepting input from a new USB device?
There are a variety of physical port blockers available as well as devices to lock cables in place. Some protrude, others are flush and require a key for removal.
If you have business policies and training in place, hopefully the additional steps of removing a lock will also provide time for adequate second thoughts to percolate through those with poor judgment. Malicious actors won't be seriously deterred, but that's a different matter.
At Defcon, a buddy of mine screwed around with a bluetooth HID device, that when connected to, would automatically attempt to open a webpage and send them to an innocuous site (Which obviously could have been a less innocuous site).
Couldn't believe we got multiple people to connect to it under the guise the device would do a cool thing.
Adults who know each other and the dangers well should be (and are) allowed to play with flamethrowers. I’m not sure I’d want to live in a place where they couldn’t.
Qubes OS has an interesting way of combatting these kinds of attacks. You can manually attach a usb drive to a specific program VM, limiting the damage possible by a malicious flash drive.
I want to say it even lets you disable or whitelist usb keyboards/mice entirely but I’m not 100% certain.
QubesOS is pretty different from other OSes though, I wish those sorts of device isolation were possible or more easily accomplished in other operating systems.
41 comments
[ 3.6 ms ] story [ 72.7 ms ] threadYou can't really prevent that.
I don’t know that people would accept this inconvenience, though.
how would you accomplish this given that the normal situation is that you're plugging in a keyboard?
This is somewhat similar to how bluetooth keyboards are enabled on macOS (or were the last time I connected one).
All kinds of legitimate (well, this is legitimate too really, it's just weird) devices have similar behaviour, and in their cases it's what the user expects and wants.
That's exactly what's happening there, but the "keyboard" is pre-programmed to enter keys presses automatically in a way that makes a website pop up.
I wonder what it would look like to have a background program that would detect and intercept any newly connected device by default, give it a fake (VM?) environment, and log everything it tried to do to the screen while prompting to ask if you want to let it into the "real" system. Obviously this is what security professionals do manually, but I'm talking about a totally transparent and automatic version that could be left running all the time.
?
Generally though, places that I've worked at with the same restrictions, also don't let you have liquids at the desk with said stations.
I've been in plenty of machine rooms where liquids == fired/escorted from the building.
• It should allow the keyboard through—or have a timeout that defaults to "yes"—if a mouse or keyboard is not already connected.
• I should have the option to disable it.
For this case, I am assuming that the keyboard and os language are fairly compatible, at least translatable.
It doesn't stop the attack, but in my small(ish) network I can easily recognize unauthorized devices. https://github.com/zelon88/Workstation_USB_Monitor
Of course, there's always the possibility that I unlock my port and plug in some infected USB of my own volition and it's much more likely than some random person plugging something in.
But, anyway, this thing presents as a keyboard, not a storage device.
I'm in the process of creating a USB drop-test script for employee training purposes. Awareness and preparedness training has been one of my best investments of time and energy with a staggering ROI. My team recently passed my last phishing test 100%.
If the corporate network you're talking about is Windows Active Directory based then I believe that there are Group Policy settings to only allow connection of encrypted external drives. I'm not sure when this was introduced, and it might only be on Windows 10, but hopefully at this point most businesses are either already there or moving in that direction.
And with some of the crazy hardware[1] out there for retrofitting antique equipment with modern functionality; blanket encryption is not always possible either. The cited USB emulator requires that the USB stick be formatted into hundreds of minuscule FAT partitions, simulating floppy disks images and all the documentation comes in one language: Engrish. After that the machines will only load programs that follow a certain naming convention/format/ect... [1]http://www.gotekemulator.com/
So the choices for many organizations are; a) upgrade dozens of custom pieces manufacturing equipment so that they're securely networkable at astronomical cost (if it's even possible). b) Air-gap all the old scary stuff running on ancient OSs & proprietary PLC drivers from god-knows-where and only talk to them via USB/direct interfaces and worry about them when they break.
But it just completely trusts any USB device I plug into it to do whatever. I wonder how much work it would be to have it ask for the user to type a randomly-generated passcode before accepting input from a new USB device?
I mean, it's a product you can literally buy and it's impossible to adequately defend against.
https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payloads
https://shop.hak5.org/products/usb-rubber-ducky-deluxe
And i'm pretty sure using this exploit for totally benign marketing purposes is a new one.
If you have business policies and training in place, hopefully the additional steps of removing a lock will also provide time for adequate second thoughts to percolate through those with poor judgment. Malicious actors won't be seriously deterred, but that's a different matter.
Couldn't believe we got multiple people to connect to it under the guise the device would do a cool thing.
Sometimes I feel like all this worrying about computer security makes it harder for people to share new things.
It's one thing to theorize, discuss and build something dangerous, it's another to actually use it.
See Flamethrowers.
Adults who know each other and the dangers well should be (and are) allowed to play with flamethrowers. I’m not sure I’d want to live in a place where they couldn’t.
I want to say it even lets you disable or whitelist usb keyboards/mice entirely but I’m not 100% certain.
QubesOS is pretty different from other OSes though, I wish those sorts of device isolation were possible or more easily accomplished in other operating systems.