Plugging things in your USB port has been known as a dangerous activity for quite some time.[1,2] It's surprising that someone at Elsevier thought it would be a good idea to use these techniques though.
This is a known attack vector. For a major company to use it is probably criminal, under the Computer Fraud and Abuse Act. There's no sign of an EULA here, authorizing them access.
Elsevier knows this is an attack. They published a book titled "Seven Deadliest USB Attacks", by Brian Anderson. So they can't claim this wasn't done knowingly.
Well it's not "just typing stuff", it's typing some rather specific stuff to make your computer do something quite unexpected. The reasonable expectation (for a promotional item) is that it's a memory stick, not that it suddenly starts typing system control global keyboard shortcuts into your computer.
Say you'd post a persistent XSS to a forum, but only use it include Fartscroll.js, is that an attack or not? Cause I consider that to be pretty much the same category as the "surprise" automatic typing USB thing.
This weekend actually I used a USB device where this was in fact the intended behaviour: a barcode scanner. It registers as a keyboard and just types the numbers (or string) of whatever it scans. Very clever idea because it makes it very easy to write apps for, you don't need a driver or anything. Except I had momentarily forgotten that was how it works, so it surprised me anyway. Fortunately the numbers didn't do much in the program I had focused but still, that feeling of something else unexpectedly typing on my computer! Yeah if it had sent global keyboard shortcuts in order to make my computer start applications and load webpages, I'd be pretty pissed.
It's not "typing stuff", it's exercing forced, unasked control of your computer (plus unknown behavior on other operating systems), isn't it?
If the user's expectation when handed a thumb drive looking USB device from a big company is that it will display files, and instead it just pretends to be him and controls his computer interface, for me it is at least a gray area regarding computer abuse. But I am not a lawyer.
What exactly makes this an attack? I don't see it doing anything malicious. And in any case, how is plugging in a keyboard to your computer not authorizing it to send keypresses?
After reading this, my guess would be that someone in marketing probably bought these from some vendor without understanding them very well or understanding why people would be freaked out by that.
It appears to be a keyboard emulator that simply types winkey+R http://[some URL]
It's (sadly) a well-known fact that all unknown USB devices should be considered malicious unless proven otherwise. This is why there are so many things like http://www.umbrellausb.com/
Yeah, this is known as BadUSB and can be used to infect even air-gapped systems. In high security systems (Banks, industrial facilities) USB devices should be completely forbidden because of social engineering attacks.
I would like to find some reasonably prices screamers to use. You plug them in, they charge an internal battery for a short time, and then they let out the loudest scream that is allowed by law. They are charged up so they continue to scream once unplugged.
Put a few in different areas around work and wait for the magic to happen.
I misread your design the first time I read it, but I think the misinterpretation might be an interesting alternative.
Instead of screaming a few seconds after being plugged in, perhaps it should silently charge whenever plugged in, and then scream only when unplugged. The only way to silence it is to plug it in again, or smash it to little bits.
If you are having fun with anthropomorphic social engineering, you might even have the scream be a loud but plaintive "Help me! My batteries are dying! Plug me in, plug me in, find the nearest air gapped computer and plug me in!".
This is both brilliant and sick. A psychological virus which guilts you into spreading itself. Bonus points if it can identify you already plugged it into the specific machine and keep yelling until it finds a new parasitic host!
Careful. This is a deeper rabbit hole than you think it is.
Screamers are 100db+. To get that you have to drive a piezo at about 100V near it's maximum resonance point and engineer the case to create a resonant cavity.
To generate that voltage, you're likely going to need an autotransformer. And nobody stocks these off the shelf--they're a custom order magnetics part. (If you find a better circuit topology or a place that stocks the appropriate autotransformer, do please let me know.)
Of course, if you just want a wimpy beep, there's lots of options. :) But if you want something offensively loud, you're going to find that there is more engineering here than you think.
This would be great fun when crossing a border into a nation that allows its agents to do bad things. Or when one has access to the coat or laptop bag of someone about to cross such a border.
Just a quibble; BadUSB is about hacking the firmware of USB devices. In this case the behaviour of of the USB device was intentional. It was a keyboard emulator that looked like a mass storage device. More of a hardware Trojan.
Quibble2: stuxnet was thought to have been spread using a Windows Explorer exploit. Also not BadUSB...
If they just removed the internal connections then they'd disable the USB ports but they'd also get notices of which staff were security risks / IT policy offenders (in the form of support requests "I plugged this USB drive in and ...").
Someone could hook up those ports with a new cable, but at that point they could also just open the case and bypass the glued port.
You can get PS/2 to USB adaptors which will at least allow you to use a USB keyboard. Probably not functionally the same as a USB port. Can't test this right now, but I wonder whether it would show up as a storage device if one plugged a USB drive into the adaptor?
Can we have a usb condom for this situation? The actual product called "usb condom" is about charging phones and blocking all data pins on the usb drive. Can we have one that will only allow devices to connect as mass storage devices, or is this at odds with the usb protocol?
I wonder if you actually need a hardware device for this?
Seems you could have an OS feature so when you insert a USB device it first confirms you're happy for the device to register as an X (mass storage, input, audio etc) before it lets it do it.
Though saying yes to registering your keyboard, mouse etc every time you boot might get a little tedious (not to mention impossible if you have no other input devices!).
Perhaps an extension to USB that has 512-bits worth of persistent storage per device. When you register a device the OS produces a random number and writes it and saves the list of allowed IDs.
Or perhaps you could ask the OS to only apply the ask to register feature to certain USB ports?
You can do something like this with grsecurity. It's not a whitelist but you can deny any new usb devices after you toggle a switch:
If you say Y here, a new sysctl option with name "deny_new_usb"
will be created. Setting its value to 1 will prevent any new
USB devices from being recognized by the OS. Any attempted USB
device insertion will be logged. This option is intended to be
used against custom USB devices designed to exploit vulnerabilities
in various USB device drivers.
Various devices tend to either have serial number empty (for example both my keyboard and mouse, Sun and Logitech respectively, so not exactly cheap Chinese crap) or filled with some random garbage that is not unique at all ("123456", "Serial" and so on).
One would assume that "garbage in iSerial" is workaround for Windows' behavior of identifying devices by either it's serial or physical port and requiring distinct driver registrations for devices that are "different" according to this logic.
USB ports are individually addressable, even through hubs, so you can do what everyone hated about Win98 and show a new hardware wizard if a particular port ever has its device change (devices can be recognized by vendor, product, type, and in some cases serial number).
Is the order deterministic? More to the point, if i leave a bad USB stick plugged in, how do i guarantee my keyboard gets the free pass rather than the evil stick?
The OS can know that you had the same keyboard (the same ID) plugged in for the whole last year at the same socket, but the new 'keyboard' is plugged in that socket where you usually plug in random USB data storage devices.
Users will just click yes, or whichever default for "just make it work" you choose.
Advanced protection/admin features left to consumers simply don't work, I thought we understood that by now. You must have something that will intelligently handle them on its own (e.g. heuristic AVs, smart firewalls etc). Because there is no way for a system to say "well, this looks like a storage device, but it's telling me it's an input one, something is fishy", you're just going to have a whitelist nobody really uses, like IE's "trusted sites" zones.
I was thinking about this. I tinkered a bit with the usb (OTG) drivers on linux. But I don't have the skills to create a hardware device from scratch. It would be great if there was a simple device that had two USB chips and that you could program, something like a raspberry PI or a smartphone. (Actually, many smartphones can be used as a USB host as well as a device, but not at the same time.)
Does anybody know if some platform like this exists? I heard you could do it with the BeagleBone?
The Intel Galileo has one host port and one device port and runs Linux. In my project I was able to relay enough USB packets to support USB keyboards and mice successfully. It isn't too expensive either.
Plug in a microUSB device and it can only charge; you have to hit the button in order to enable the data pins.
But I think this is designed for risks going the other way, i.e. to protect your cell phone from data-scraping USB-A female ports in airports and the like.
Would any such countermeasure really be worth it to use random 8GB USB drives from conferences? They are so cheap, and I have a hard time believing this would ever be better than simply not using these ever.
They're distributed because people need/want to access the data that way.
It's a somewhat efficient way to distribute a gigabyte of data to a hundred people so that they all have access to it now despite all sharing a lousy wifi at a conference center.
This is an operating system problem. When a new device is plugged in and claims to be a keyboard, it should lock the screen and not be accepted as input until it has typed the user's login password.
Or have the OS block it initially and popup a message saying what the device claims to be. The user either accepts or rejects, and if rejected the block stays in place. Only exception would be for the first keyboard/mouse plugged (unless there is a built in one, in which case even this wouldn't be an exception).
Different protocol for startup, where you select the keyboard you want. For a desktop with a good keyboard and a malicious USB both plugged in, it is going to need some way to know which one to go with anyways. The real threat is someone plugging in the bad USB after they are logged into their machine, at which point you already have a good keyboard (or are using mouse + onscreen keyboard).
Maybe even don't go with any keyboards to start, only a mouse and an onscreen keyboard and all others have to be approved.
I suppose you'd need a user interface for authorizing things like that. Ideally, it'd be on the lock screen; show a message which says "New keyboard detected; sign in with that keyboard or click here and sign in with your existing keyboard to enable it". It's extra work, and makes it cross-cut through more modules, but it's hardly insurmountable.
I wonder whether it's smart enough to adapt its keystrokes for non-Windows platforms, or whether it just does random things to peoples' computers in that case?
> So will this USB firmware situation eventually be solved in some newer version or are we all just silently ignoring this?
No, it will not be fixed. There is no vulnerability. We need to plug in keyboards, and if users are willing to plug random devices into the ports where their keyboards lie, those peripherals can inject keystrokes.
We can play whack-a-mole and blacklist the vendor/product IDs (like systemd does), but if this were a real attack and not a stupid marketing stunt, the device would just present itself as some popular cheap keyboard and there'd be no way for the computer to tell it apart from one.
There are many other ways you could attack USB or other connectors if you get a user to plug your hardware in there, most are more involved than this one. The only solution is to educate people to not plug hardware they don't trust into their machines.
> No, it will not be fixed. There is no vulnerability. … The only solution is to educate people to not plug hardware they don't trust into their machines.
“We just need to educate users about passwords”
“We just need to educate users about how to verify SSL certificates”
“We just need to educate users about how to install only software from trusted publishers”
etc.
This reaction is understandable but it's a non-starter if we ever want to make meaningful progress on security. The underlying problem here is that everything local was assumed to be trustworthy and that's not true and, thanks to reflashable firmware, not even something which can be assumed to stay true even if it happens to be the case when you start.
Fixing problems like this will require changes – X-Istence mentioned OS prompting for new device classes, which would particularly effective on devices like laptops (i.e. the default for most users) which could require confirmation on the built-in hardware any time an external device tries to duplicate built-in functionality (keyboard, mouse, network, etc.), but we probably need more ambitious measures like adding a public-key exchange for certain device classes or a hardware switch which controls whether a port is allowed to control the computer or provide block storage but not both.
The one thing which is certain is that the .gov / .mil security people who seal ports with epoxy aren't looking as paranoid these days…
I think signed firmware would probably solve most problems.
Hobbyists would have to run their system in an insecure mode, though and it's a whole new story if a certificate-based system would actually work in a market as volatile as USB peripherals.
So, I don't think there's one magic bullet but it's far too silent on that front!
I don't see how signed firmware solves that issue at all. It could solve BadUSB, where one corrupts a legitimate device with poisoned firmware, but it doesn't address at all a user tricked into plugging a bad device...
It adds an accountability mechanism for spoofing device types: the vendor's signing certificate can be revoked if they release devices which pretend to be from a different vendor or which misrepresent the device class.
A reasonable criticism is that this would likely result in several examples of customers being screwed when SmallCorp Inc. loses control of their signing key, it's used to sign malware, and the revocation takes out all of the legitimate users but that's arguably an unavoidable cost of the industry maturing.
Also, if "large device manufacturer" ever losse its key, zillions of devices could become unusable overnight (scenario: Evie signs malware with the leaked key, Apple and Microsoft revoke it in a high-priority update; all devices signed with the key become unusable; the world is 'not happy')
You likely also would need a way to update the key or flash new firmware and, possibly, a way for the updater to detect whether the device it is talking to has been tampered with. That's expensive for low-margin products such as USB sticks and mice.
Also, the average user would not know how to update the firmware, and even if he knew, might not be able to because his keyboard and mouse are fried.
In this case there was no faking of the vendor installed. HID is a generic input class, you're not making any promise about who manufactured a device when you make it represent as HID.
A lot of people seem to think that this was a device with hacked or other illegitimate firmware. It was not. It was a device called a WebKey, which is available from a number of vendors and is intended to do exactly what the author is describing.
Is it a dumb product? Yes. But this is not any kind of firmware exploit. It's just a keyboard that doesn't look like a keyboard, some as a YubiKey or one of several other sorts of non-keyboard devices that present as keyboards.
Right, note that up-thread (https://news.ycombinator.com/item?id=10204222) I was agreeing with the general call for OS safeguards such as confirming that a particular device be allowed to act as a particular class.
Signatures become relevant due to what will inevitably happen if those safeguards become common: right now someone is selling devices like this to marketing people. If Windows 11 breaks that with a permission check, the companies have the choice of either dropping that product or changing it to pretend to be a Microsoft USB keyboard on the whitelist. If it's some fly-by-night marketing services company in China, there's limited recurse to go after them unless you have a lever such as being able to revoke signing keys.
Agreed – signed firmware is going to be the way forward for a lot of things but it's going to open up other problems like fighting to retain the user's ability to decide whose signatures to trust and I'm sure we'll see a bunch of horrible key management by vendors.
That systemd thing is hilarious in its tragic misunderstanding.
Basically a patch was offered that would lock a computer if a new device was plugged in. This to counter act police mouse wigglers etc.
But Poettering decided that no that was too heavy handed, lets instead black list the specific product id. Never mind that changing a product id is a firmware flash away (one could probably make a wiggler that randomize its id on each insertion).
It is too heavy-handed. Locking the computer every time I plug in a controller or some other HID?
What if the battery dies in my wireless keyboard, and I need to plug in another one temporarily? How could I possibly type in the password at a lock screen with one dead keyboard and all new keyboards forbidden?
Not all lockscreens do. Using MATE on this machine, no such button. I don't believe the KDE 4.4 one does either. The greeter might, but not the lockscreen.
We can watch for unusual situations and ask questions about them.
----
USB device: hi computer i'm a new usb device, i can provide keystroke input
computer: that's a little weird, I already have a keyboard. hey user, do you really want two keyboards at once?
user: wtf no
computer: cool. sorry, usb device. no keystrokes from you.
----
USB device: hi computer I'm a new usb device, I can do keyboard input and provide mass storage
computer: that's a weird combination there buddy. hey user, does this sound cool?
user: weeeird, hmm, yeah how about mass storage so I can see what's on this thing, but no keyboard input.
computer: a pox upon your possibly-suspicious data, my hot-pluggable friend! but tell me about your filesystem.
USB device: hey here are some keystroke events anyway
computer: I'm not listeniiiiiing plus I just told on you to the user
USB device: curses, foiled again
----
USB device: hi computer I'm a new usb device, I can do keyboard input and provide mass storage
computer: that's a weird combination there buddy. plus i already have a keyboard plugged in. oh wait the user said you were okay and told me to never ask again.
USB device: cool
----
USB device: hi computer I'm a new usb device, I can do @$T%^&#R&ssnhf^23&298>>>
computer: that's a nice buffer overflow you have there, darling. take me, I'm yours!
USB device: p0n'd. here's a payload!
user: huh, that usb key I found in the parking lot of the nuclear plant doesn't work. Oh well. throws it away
payload: all yr base belong to us
----
Obviously "not plugging untrusted hardware into their machine" is still useful. And users often just say 'okay' to everything anyway. But "a weird thing is happening, are you cool with this?" would be a nice line of defense.
Uh, even a prompt like "A new keyboard was added, do you wish to use it?" would work (after the system is up and there is already an input device). Yes you can come up with edge cases, but it should be easy enough to detect the difference between someone trying to get a keyboard working versus someone going about their day and a new USB device showing up as a keyboard.
> The only solution is to educate people to not plug hardware they don't trust into their machines.
Solution to what problem? If the problem is "people keep getting hacked by plugging things into USB ports" then there are lots of other solutions. Filling in the USB ports with glue works well.
If the problem is "we need a way to plug in hardware easily without introducing security vulnerabilities" then educating people doesn't help at all.
How many keyboards do you need to type with? If a keyboard exists and a second one suddenly appears, giving it a separate buffer and keeping that buffer from doing anything until asked, would seem to be pretty sane.
Four, typically, along with three things that could be called pointing devices. (That would be a laptop's built-in keyboard, a proper external keyboard, the hotkeys on a Wacom tablet, and a programmable keypad to make Ctrl+Alt+Shift+[optional Fn if using a compact/laptop keyboard]+[whatever]+"hold your tongue in precisely this position while trying to do things with the other hand using a pressure-sensitive pen" key combinations into a single simple keystroke, the laptop's pointing device, an external mouse, and the actual tablet part of the Wacom.) And yes, there are home and travelling versions of the set-up. People seriously working in 3D, non-linear editing, and so forth, would have more. Things can get rather complicated in a hurry when the computer becomes the core of a dedicated toolset that can also be used, on occasion, to perform simple administrative tasks like email, invoicing, ...
This is not a USB firmware situation, it's the issue that any device you plug into USB can emulate one of the allowed devices (i.e. keyboard/mouse/other).
What we need is for the OS to ask the user what to do if an existing keyboard/mouse already exists, with a way to whitelist the new device so that we don't have to repeat the same steps each and every time we reboot our computers, or unplug/replug the device.
It can even emulate more than one device on the same port, and introduce new ones after arbitrary delay. This attack could be made stealthier by first presenting a valid mass storage device and adding the emulated keyboard later.
I think the idea is the machine only allows one keyboard and one mouse, and if you insert another input device you have to explicitly enable it. This would probably stop 90% of attacks.
If the computer requires a password to log in, then just look for the right password from the keyboard on a restart, and at that time tell the user that this keyboard is new. Sure, it's possible for evil keyboards to do bad things, but at least the user would be aware that there is now a new HID plugged in.
Distributing a USB device that pretends to be a keyboard and types commands is somewhere between faux pas and criminal hacking attempt. Even if the intent was innocent, it has to be investigated like a breakin to be sure. In this case it sounds like it was closer to the faux pas side.
What bothers me in these situations where there is (arguably) room for interpretation over the gravity of the act is the double standards. BigCompany does something harmless but illegal? They have the resources to make it sound completely benign to a court. Some random person gets hauled to court over an arguably harmless/moral grey zone matter and the story ends much differently.
I suspect that a legal approach might work here. Elsevier was being deliberately misleading and was deliberately making a computer do something that the owner of that computer had not authorized. There must be some computer crime statute they could be charged under.
On a naive reading it breaches the Computer Misuse Act in the UK and the CFAA in the USA both of which have terms guarding against unauthorised access. You need more wrangling to read it in to a normal interpretation of the CFAA however.
Might be nice if it could bump a post back to "new" when the dupe detector finds a dupe with not-very-much-attention - that way, effectively the comments are merged.
This is common in the pentesting world. If you can get physical access to a USB port for just a few seconds you can enter the keystrokes to open up a port (or reverse SSH) to the outside world. With only three different procedures (one for Windows, Mac, and Linux) you can own 99% of the computers in the world.
Well, it's Elsevier. The fact that it only potentially exploited your system and didn't attempt to grab your banking password might actually be taken as a legitimate sign of improvement.
Western Digital includes one of these in their Black2 drive kits. Instead of shipping with a driver CD, it ships with a USB key that opens up your browser to the webpage that hosts the driver download.
And yes, you totally can detect operating system, bypass HID protections, and deliver custom weaponized payloads in the form of scripts catted into the command prompt.
... except I don't have access to sensitive information (because we have a decent separation between programmers and ops related to PII), and I do have full access to the entire internet, which is a great alternate insecure transfer medium.
A friend of mine works at an univeristy in Germany and one of his last projects was exactly this.
They were to build a device using a teensy that starts up a webpage once plugged in. It needed to work on major OSes and *nix systems. Win7/8/10, OSX, Ubuntu.
This was for some conference as well where they were to be used...
There's an off-the-shelf USB that you can buy called a Teensy[1] that is programmable and automatically registers itself as a USB HID. Very similar to what is described here.
And that's a feature, not a bug. I have a YubiKey and it does a similar thing, but for good not evil. It would be tricky for an OS to not register keyboards (after all, how would you vouch for an input device without using an input device?).
tl;dr don't plug unknown things into your computer.
Tough problem for sure, especially getting users to understand. For keyboards you could use the Bluetooth pairing trust trick. Display a short random number code on the screen, and only accept the keyboard if the numbers are typed, which could be interpreted as the user vouching for the keyboard. The need for this in Bluetooth land is more obvious due to the wireless nature of it, but USB is also an untrusted network.
> after all, how would you vouch for an input device without using an input device?
Separate built-in device, or specific signal sequence inputtable on the IME the device registered itself as e.g. if you plug in something which advertises itself as a keyboard, the system sandboxes it and asks that you input a specific password which it displays; for a pointing device it might ask you to move the pointer to specific places and click on them.
> (after all, how would you vouch for an input device without using an input device?).
Allowing the first keyboard after boot by default seems not unreasonable. It would still make it possible for evil maids to plug in something and wait for you to boot up again, but they are difficult to protect against anyhow. This would also avoid the hassle of vouching for your keyboard every time you reboot.
Have a set of whitelisted USB sockets on the computer in a different color that are meant to be used for your primary input devices.
Then for any USB input device that's plugged in another physical socket (e.g. where you'd plug things that you believe are just mass storage) the OS can require acknowledgement from the user before it is connected and allowed to send input data.
BFD in 5 years everything will have a touch screen and camera, anyway. We'll use animated QR code videos playing on our digital watch faces and some law-enforcement/TLA/convnet goon will be required to approve every UAC request remotely.
I don't worry much about inserting wacky storage devices, as I run Linux, and I don't have any kind of auto-run enabled.
But this would still work on my machine, right? (I mean that the key combo would be entered; it might not actually bring up the web page, depending on my setup.)
Pretend to be a FAT-formatted mass storage device and see what files are accessed on automount. Possibly also pretend to be ext2 and see if e.g. the mount time in the filesystem superblock is updated.
You can probably also learn a bit from the timings of specific actions by the host, but as long as there is any sort of automounting, I suppose that’s the best way to find out your host OS.
I wonder if it is possible to fingerprint USB keyboards of same make (with same dummy serial number) to tell them apart. For example one could try to exploit frequency deviations of the crystal oscillator in the keyboard.
Hyundai did this years ago in 2011 when I bought my car. They sent me a USB key that emulated a keyboard. It opened up the Hyundai registration page, and may have typed my VIN in for me. This isn't new at all.
A few years back a colleague (at the time) went to a MongoDB event where they pulled this same stunt, handing out usb drives that would act like a keyboard and hijack the machine.
It's not an attack unless you write to the hard-drive. This is more of a nuisance, and a bad move, and troubling for what it could be, but the thing itself looks harmless.
[1] https://srlabs.de/badusb
[2] https://media.blackhat.com/bh-dc-11/Larimer/BlackHat_DC_2011...