Unpatchable Malware That Infects USBs
wired.com
wired.com
So it was just a dummy usb hid device that emulates a keyboard. No exploit or anything but a simple marketing gimmick that people take because of 'hey, a free usb stick!'.
Here's some more info: http://blog.opensecurityresearch.com/2012/10/hacking-usb-web...
Or it could emulate a disk + HID keyboard, and enter the win+r filename.exe <RET> keystrokes necessary to launch it, or one of several other tricks.
It could also intercept mass storage requests, wait til you're copying an exe onto there (even if you've reformatted the drive since), and inject a payload into it.
This one does actual work as a legit USB stick too once you get past the annoying link part.
They are not doing this secretly, consumed by fear and guilt, manufacturing these devices in the backroom of some disreputable bar in the nasty part of town and then furtively selling them from a van in a back alley, living in constant dread of exposure. They do this quite openly. They manufacture these things in many of the same boring factories that make the reputable brands. If you ask them, they'll cheerfully mail you some free glossy promotional material detailing fake USB drives and many other nefarious electronic things that they'll sell to anyone with a credit card, and your order will be delivered to your doorstep quite openly via FedEx or DHL.
They don't care (at all, on any level) what we or anyone else think about the moral propriety of their operation, surprising though that fact may be. Indeed, a public shaming campaign would benefit them greatly as free advertising, by bringing their very existence to the attention of many new customers.
I didn't mean to shame manufacturers. They have plausible deniability anyway - "it's a keyboard emulator that looks like a pendrive!". I think that companies that buy these devices and use them for marketing on trade shows should be shamed and blamed.
Of course there should be a room for caution and thought. Maybe this exec and his company really weren't aware of the implications of what they were doing. Nevertheless, there needs to be back pressure. In this case giving feedback may be enough - I'm in favour of being as nice to people by default - but in others such methods should be denounced.
No worries - didn't come across wrong. Personally I was a little miffed about scoring a snazzy SD USB adapter...that turned out to be "crippled"...but hey...gift.
>Nevertheless, there needs to be back pressure.
Thats tricky - firstly I can't jeopardize a big contract by complaining about a trivial gift (!). Secondly the company in question is "truly" innocent / oblivious here. They get a marketing catalog and pick 100 of item X. Not sure how one would reach such a marketing company - but they are the culprits here.
I understand. It would be awesome if the word reached that company that the item they picked from catalog is both evil and moderately annoying to users. They actually might take it into account (people often do care if they know; I've personally made a SEO spammer lose business like that). But it's completely understandable you might not be in position to deliver such a message. On the other hand yes, that marketing company should be one to get the blame.
One option would be to build this into the chassis of a PC so that you know anything plugged into the green USB port will only work as a drive.
However, if the exploit is in the bios of the usb device, you can't trust anything coming off of it. All you've got left is recharging it.
It'd probably be more simple to just make one type for each class of device: http://en.wikipedia.org/wiki/USB#Device_classes
It should be easy enough to train my users to only put their thumb drives into the one specific port. The rest are gonna get sealed off with hot glue at this rate...
So you tell the device to store workReport.pdf, and it stores workReport.pdf, but also injects a malicious payload into the PDF so that when you open it again it infects you.
Basically you plug in USB at one end, at the other end you can script the USB protocol with python, emulating any USB device you want to (or that you can write the code for).
We can discount VID/PID based black/whitelisting since they're trivial to spoof, but it might be possible to use them to identify (from an external database) what features that V/P device is supposed to be capable of, and block/alert if it tries to do things it shouldn't.
So if you initially enumerate as 0x0403/0x6001 (FTDI usb-serial) then if you try to start serving up descriptors about how you totally do mass-storage or something, that's probably kinda naughty. You'd potentially need quite a bit of code to parse and decode the various protocols it might be observing, giving a really big code surface for an attacker to identify or compromise your 'condom' itself.
So, with a lot of work, and a really big and annoying to update database, it might be possible to protect against imposter/multi-personality devices.
The bigger overall threat though is probably masquerading as valid mass-storage, but then doing various things to the data you're asked to store/fetch. (See the Active anti-forensics iPod and similar)
As I see it, there's basically nothing you can do here against an actively hostile device that isn't a cat & mouse game of exploit->patch->repeat. Conceivably the OS could sign every file going in, and maintain a local cache of signatures to check when reading, but that falls over in the hugely predominant use-case of using a USB drive to transfer files between things; you have no easy side-channel to also transfer sigs. So then the machines need to trust each other (without the malicious drive compromising one and being able to fake sigs)
The only downside being that many users add a new HID as their only interface to the machine.
1. Connect innocently as a plain storage device 2. Wait a period of time or even monitor voltage fluctuations to guess when the user is not at the computer. 3. Disconnect and reconnect (or a new side-connection?) as a HID device
Users often won't mentally associate the long-delayed attack with the USB stick, and if it attacks when they are AFK the timer might hit 0 in total secrecy.
Black/white list vid/pid (which are easily faked, yes). Closes the door a small amount.
But can also blacklist all HID.
It just needs to be wrapped in a convenient tool.
Might be worth it to at least extend the time span that an attacker would need if he had physical access to your laptop/smartphone.
Unfortunately without going back to Windows 95-esk "please restart to install this keyboard" world, I cannot see how you fix this. Even blackholing some input from the HID is only at best a temp' solution (as they'd just add longer and longer sleeps before fake HID input was generated).
I guess you could redirect all HID input to a certain context (like a Virtual Desktop e.g. UAC prompt) until the user accepts it. However realistically most users would ignore this warning and just click "install" without reading it or understanding the implications.
You just have a timed dialog with allow/block options that defaults to allow the new HID after the timeout.
1. Supposing all the more-convenient ways have broken down (no keyboard, no mouse, etc.)
2. The OS displays a random 15-60 second countdown telling the user when to unplug the device if they trust it
3. The OS displays a second (random) countdown telling the user when to reconnect the device if they trust it.
4. If both steps succeed to a reasonable level of accuracy (some fudge-factor for humans and for slow-powering-up devices) the OS will begin trusting the HID device and installing drivers etc.
This requires no additional hardware except for a monitor, and evil devices cannot reliably brute-force it without taking a lot of time and being very obvious and obnoxious about it.
"The following USB device has requested direct control over your mouse and keyboard inputs. Do you want to grant it access?"
"Note: If you are unable to interact with your computer, please wait X seconds for emergency instructions on how to enable this device."
You can't make anything totally idiot-proof, but a lot of people will be surprised/scared when a very unusual and seldom-seen dialog pops up when they plug in a particular misbehaving memory stick.
It would require that all these devices have at least some basic functionality with only some standard drivers. I don't know how true that is right now.
Not great, but certainly a lot better than a 100% certainty of fooling the PC.
Plus, 99% of the time the user is not plugging in a HID device, so the "unrecognized input device" dialog can be made ominous enough that users will realize something is very strange about that one USB stick.
"I see you plugged in a keyboard USB device, but you already have a keyboard installed. This may be a malicious attempt to take control of your computer by emulating a keyboard and sending keyboard presses to your computer from a USB device. Do you want to allow this? (recommended action is no)."
No more security headaches and marketers will stop their stupid tricks when they get pissy emails from clients about "sending us viruses."
You might think you could identify it by manufacturer/model (VID/PID) or even serial number, but all those are easily modifiable by a serious attacker for a given target.
It might make shotgun/blind attacks harder, but ultimately it wouldnt' be much more secure than MAC filtering on your network router.
There are also plenty of non-keyboard HID types that could potentially generate unwanted input of this sort, although not quite as easily.
The computer can't detect if I have a working and available input device connected - the fact that some devices claim to be connected doesn't imply that, as it may be damaged, a virtual device, or not wirelessly connected but simply listening for a possible connection that may appear at any time.
For example, right now I have a mouse and a keyboard connected, but Windows device manager somehow shows 5 keyboard devices and 4 mouse devices due to various connection drivers listening to devices that might be connected but currently are not. If I came home after a long vacation and found out that the batteries in them are dry, then there would still be multiple devices of the same type "available" when I'd try to connect a wired USB keyboard.
If I want to connect an input device, it is quite possible that the only way that I could allow or disallow anything is through that device itself.
So if you plug a keyboard or mouse into a computer carrying this malware, they could be infected. Then if you plug them into another computer, they could infect that computer.
Or more likely, you could find out your computer is infected, and decide to wipe or replace it. Then you plug the same mouse back in, authorize it as the expected HID...and now your computer is infected again.
Or consider a laptop keyboard that connects over the USB bus...
The only reliable solution to this vulnerability is to protect USB firmware via code signatures. That's going to take a long time.
In the mean time, I'm going to completely avoid USB thumb drives, and stick to Bluetooth HIDs.
This is more like how bluetooth works. However that still leaves significant problems for HIDs. The only solution I see is remote attestation and securing the comms channel with encryption.
Even if USB is patched like this it doesn't solve the problem of having un-trusted peripherals or appliances. For example, would you trust that the signed firmware for a USB scanner is actually secure? It is quite easy for a scanner driver to be subject to a buffer overflow caused by data from the scanner. Scanner embedded malware could be triggered by scanning a specific form, or anywhere it sees interesting text, like 'SECRET' headers on a page. Networked scanner/photocopier/printers are even worse because they return PDF documents and are serviced by outsiders, and anything on the network can often send them a PDF to execute. I've managed to crash my printer many times by sending large/complex PDF/postscript/PCL5.
USB tries to make peripherals "universal" - and I don't think one of the primary input devices of the computer should be mixed in with the others in this way. (Trying to troubleshoot problems with USB controller drivers when the keyboard itself is USB can be... frustrating. The BIOS has its own USB keyboard driver but hands control to the OS after booting, meaning that any flaw in the rather complex USB stack can cause a loss of an important input device. On the other hand, I've never had any problems with PS/2 keyboard or mouse drivers.)
Being able to unplug a keyboard and plug it back in again while the PC/server is on without the PC/server freezing is a pretty significant benefit.
Also... though not a tech limitation... the only access point for a PS/2 plug being at the far back of the PC case can be really annoying (though I wonder what would happen if you had 2 PS/2 ports on a board and you actually plugged in 2 keyboards... probably a small explosion).
What are you doing where being able to hotplug keyboards frequently is a "pretty significant benefit"? If you are working with multiple servers a KVM switch is a better solution.
(The problem with hotplugging PS/2 was that it originally wasn't designed for that so the interface lacked the necessary protection components, but more recently manufacturers have been realising that it's far cheaper to add the protection components than deal with returns from those who either accidentally or purposefully hotplug PS/2. There's still considerable variance between when manufacturers did this, so it's still officially "not supported" but recent motherboards and keyboards/mouses should be robust enough to handle the occasional hotplug.)
The PC spec also only allows for 2 PS/2 ports and no more: one for a keyboard and one for a mouse. They use the same physical protocol so no catastrophic effects from putting in two keyboards/mouses or switching them around, but they just won't work since the commands are slightly different; some newer motherboards with a single PS/2 port can detect whether a mouse or keyboard has been plugged into it, and configure accordingly.
People trip over cables, and PS/2 plugs liked to disconnect much more easily than USB; you could unplug your keyboard by accident while doing something that moves cables (e.g. using a mouse).
A kvm would be a solution... but for the rare visit to the colo it just wasn't worth it. One of those 1u rack mount with integrated monitor would have been nice (though the 1/4 cabinet was the top one so I don't think it would have worked very well).
Also with KVMs... wires and wires and wires. Blah!
So maybe it's not different. And this just significantly lowers the barriers to entry to an extremely easy process using only off the shelf hardware. And now the malicious device can be anything from flash drives to keyboards to USB Missile Launchers.
That seems like a problem the manufacturers need to resolve, however inconvenient it is to have read-only firmware.
Ok. Now I'm concerned.
Complete rubbish. No thrusted computing is required to protect a device from surreptitious programming by malware.
All you need is a write protect switch ("fuse") that is burned when the device is programmed for the first time, so that for subsequent in-field updates, it requires a physical override to enter into a programming state (the user has to flip some switch, or hold some pin-operated button or whatever).
So you are back to requiring trusted hardware and trusted handling, which is impractical except for strictly controlled systems.
This is a different issue from white hat USB devices that turn black due to a remote exploit, and it is addressable by some form of trusted computing, like authenticating that USB devices are genuine. With this authentication in place, it's possible that there could be remote exploits that somehow retain the device's ability to authenticate while changing its behavior.
As far as trusting the manufacturer to implement the switch: it is hard to get away from trusting the manufacturer. You're plugging in their hardware into your device. Under the assumption that the manufacturer is working in good faith to prevent rogue reprogramming, it is in their interest to implement the switch properly, so it cannot be overridden in software.
Basically, the situation is that if someone wants to sell you, say, a rogue keyboard that steals your keystrokes, they can do that without even involving the USB protocol. A keyboard can have its own storage for keystrokes and its own channel for transmitting the information, not involving the USB interface. For instance, it could have on-board Wi-Fi, and a rogue firmware that finds a free hot-spot, makes a connection and sends its logged data to its "mother ship".
Is there something I am missing here? Serious question.
I'm afraid we have to go back to exchanging files over the LAN. Or turn on our WiFi cards in hotspot mode and create a LAN ourselves. There are going to be good opportunities for desktop and mobile apps. Obviously Evernote and Dropbox are already here but they are not exactly the same thing.
1 horribly infected computer on a LAN can be a nightmare for everyone else connected.
I know several common USB devices that actively prevent field upgrades of their firmware for security reasons, an example would be the Yubikey (http://www.yubico.com/faq/upgrade-yubikey-firmware/).
For example, I believe that the firmware flashing allows for easy configuration of the USB storage size, so there's no need to hard-code values in the hardware. As a result, you can easily re-use components and repurpose them as needed.
It might also be used for mapping out bad sectors during device testing? That way you can stuff low quality flash storage into a USB stick and then blank out the bad parts during testing. This could be more difficult to do if the firmware isn't easily updateable.
It's hard to tell where that "last step" might be. Boxing? Shrink wrapping? Delivery to Amazon's warehouses?
Our ASICs have efuses to disable insecure firmware changes. (Need insecure fw updates during fw development.) During dev we wind up having to scrap parts because we blew the fuse prematurely.
It's a tough logistical problem.
To get this to work, you need to solder wires onto the USB flash drive's PCB, and then program a "burner" firmware image into the microcontroller. Only then you can remove the wires, and further program its firmware over USB. The stock firmware for nearly any USB device would never allow itself to be upgraded over USB.
This strategy allows you to give someone a malicious flash drive that enters keyboard commands into the computer (this has been done before), or infects the computer by pretending to be a device whose driver has a security flaw. It would not allow you to infect the other USB devices connected to that computer, because they don't have burner firmware.
I think the exploit version occurs at a lower level down in the bios of the stick, where it's far more insidious.
That is surely false. It depends on the type of microcontroller used and its configuration. And indeed the github link in the article is only for certain types of USB flash drives (Phison 2251).
The device acts like a USB hub which happens to mount both a keyboard and a USB drive.
So unless you ban all USB hubs then this isn't workable.
Sometimes "USB thingy".
As for the actual flaw, yes that's true. But that's not what this article is talking about.
> You should read the article.
I did. It says:
> “People look at these things and see them as nothing more than storage devices,” says Caudill. “They don’t realize there’s a reprogrammable computer in their hands.”
It's clearly talking about the storage devices. If they were talking about the bus protocol they'd say "USB is nearly impossible to secure in its current form" instead of "USBs are nearly impossible to secure in their current form"
Possibly. I wouldn't care if it was speech. I wouldn't comment if it was a regular newspaper. But WIRED writing like this?
If we can pretend to be a mass storage, we could pretend to be a keyboard/mouse, too. It's a small matter of firwmare.
"... USBs are nearly impossible to secure in their current form."
"... silently disable a USB’s security feature that password-protects a certain portion of its memory."
Just substitute the name of any other interface - PS/2, HDMI, Thunderbolt, etc - to get a sense for how weird it sounds, e.g., "HDMIs are nearly impossible to secure".