Slashdot Mirror
Hacking USB Firmware
An anonymous reader writes Now the NSA isn't the only one who can hack your USB firmware: "In a talk at the Derbycon hacker conference in Louisville, Kentucky last week, researchers Adam Caudill and Brandon Wilson showed that they've reverse engineered the same USB firmware as Nohl's SR Labs, reproducing some of Nohl's BadUSB tricks. And unlike Nohl, the hacker pair has also published the code for those attacks on Github, raising the stakes for USB makers to either fix the problem or leave hundreds of millions of users vulnerable." Personally, I always thought it was insane that USB drives don't come with physical write-protect switches to keep them from being infected by malware.
(More on BadUSB here.)
we used black tape over the write protect notch on our floppy disks and we LIKED IT THAT WAY
Finally I can run a beowulf cluster of usb sticks!
wait... C#. Does that run on linux? Has mono added .Net UI yet?
And either the Government would break it, or make it illegal. Never mind the other malevolent people.
A write-protect switch won't help you here, Timothy. They're going and reflashing the microcontroller, which means vendors will probably just burn a public key into the microcontroller and refuse to boot if the image signature doesn't match. They'll still have the firmware update capability they'll never use, but won't have to worry about attacks like this - short of someone stealing their private key.
Do I care?
Don't know.
Would I care?
Don't know.
Should I care?
Sounds like you should if you care about security/privacy. But since, I don't know what is going through your head, I don't know.
Could I care less?
Once again, don't know.
I have a 8GB USB flash drive that does have a write protect switch, and I use it for transferring files to known-infected machines. Love that thing...
Nobodies Prefect
Tidbits for Techs Technology Blog
I'm going back to punch cards!!!
USB first came out in the mid 90s, and was for cheap peripherals. Then, you wanted to keep the design simple, and transistor count low. Now that it is 20 years later, and transistors are much cheaper, some transistor consuming fix will be adopted.
TFA's author lazily uses the term "USB" to mean "USB storage device" as in USB flash sticks, hard disks and optical drives. But in reality this firmware issue affects all USB devices including mice, keyboard, printers. This is not a security flaw in the USB protocol, per-se, it's the retarded approach taken by the device hardware manufacturers to secure their firmware (read: no security at all). The same lack-of security issues affect devices on any kind of bus like SCSI, SATA, Firewire and Thunderbolt/Lightning.
What we need is a physical switch that write-protects the microcontroller firmware. Most people would never want to update the firmware on their USB controller so it can default to "off".
What we need is a physical write-protect switch for the firmware itself, as well as for the contents of the drive.
It wouldn't be hard to have a single pin control whether or not the microcontroller firmware can be written to.
lol.
Truth isn't Truth - Guliani
...were made of fused quartz, because UV wont go thru normal glass.
That's why the erasable ones were so expensive.
Truth isn't Truth - Guliani
No, what we need is an OS that doesn't just assume that any commands given by any random thing that claims to be a keyboard have come from the user of the computer.
Scsi and sata devices aren't typically carried around being connected to different computers, so there's a much lower risk of them spreading an infection. The other interconnects also aren't used for keyboards, so any action by the device can be confirmed or denied by the user, if they have the ability to take those actions at all. For example , there's no sata command an esata drive can issue for "erase the boot drive" or "log the user's keystrokes ". Since a USB device can represent itself as the keyboard, it effectively IS thw user, as far as the rest of the system is concerned. Pop-up a confirmation dialog? The usb "keyboard" can press enter to confirm it's own actions.
That's the problem. We certainly want to just be able to plug in a HID and have it work. How do you propose that a keyboard be distinguished from an evil_keyboard?
http://en.wikipedia.org/wiki/E... ?
Well obviously we just ignore anything that has the evil bit set!
@Random_Adam
Sometimes a sig doesn't have to be funny!!
Just make the "firmware" on the usb devices non-re-writable/non-upgradeable. These USB devices don't need firmware upgrades at all, and they are so inexpensive these days that they are easily replaceable. Problem solved!
Cypress EZ-USB microcontrollers allow firmware to be loaded via a host device driver. This saves the BOM cost of having an I2C EPROM on your USB device. If you don't want malicious firmware running on these devices you need to run an OS that won't run unsigned device drivers. Does this suck for you folks in FOSS land? YUP.
We certainly want to just be able to plug in a HID and have it work.
Do we? It sounds a bit like auto-play. Just put in a CD and it works!
Maybe, just like with CD-ROMs, the OS should ignore the new keyboard until it is explicitly told what to do with it. Sure, it'd be a pain in the ass, but it's also a pain in the ass that my Linux system wants my password for every trivial thing I decide to do. Just add "plug in a new keyboard" to that list.
The same way a smartphone doesn't allow you to expose its internals to a connected computer without requiring user authorisation. From the OS: you've connected a new keyboard. Do you want to accept this device?
Sneak teach kids Algebra using a game
Did you think that through?
How can you accept if you don't have a keyboard or mouse?
Pop up a small window: You have connected a new keyboard. Type "random string" on that keyboard to enable it.
Similarly with a mouse: You have connected a new pointing device. Enter "random number" on this on-screen keypad to enable the pointing device.
Limit the inputs from new devices to that popup window until the user has confirmed that it's a valid keyboard / mouse by entering the given code.
> Personally, I always thought it was insane that USB drives don't come with physical write-protect switches to keep them from being infected by malware.
I have an old but working 256MB USB pendrive, which does have a physical write protect slider microswitch on its side. Neither Win, Linux or AIO printer can write to it when the slider is under the closed padlock symbol, so I think the protection is electric airgap based, not just software magic. This kind of device was reportedly used by malware analysts to transfer infections within a controlled lab environment, that's why the device features the blue triangle logo of F-Secure Oy, a finnish anti-virus vendor. The only grievance is, the slider hides deep in the recess and can only be manipulated by a straightened paperclip and the open/close padlock symbols molded above it are positively tiny.
I propose all devices which are not evil sets a good bit, since we can not trust the evil devices to set the evil bit. then it is a simple matter of blindly trusting the good bit, i dont see what could go wrong.
Keyboard not found, press enter to continue.
Do not forget that on each reboot of the device you will have to re-authorize each device again, on your regular desktop pc that is a keyboard, mouse and probably a user password before you get to do anything...
You can not store this information for reboots (or returning from sleep/hibernation for that matter) since the device could be unplugged and replaced with a fake one that spoofs the old device and adds a little extra fun.
There is also nothing that prevents a keyboard from working like a normal keyboard for a while, then if it detects inactivity for a period it will try to send an evil command. You authorized it when you plugged it in, then went for coffee...
An obvious problem with requiring the old hid to validate the new one is that a broken keyboard can't be replaced . Many times, there is no mouse (servers, ada, atm, etc) or the keyboard and mouse are one usb plug (wireless keyboard and mouse) . So you have one hid device and when it breaks you have no known hid device.
> as long as at least one isn't compromised
A compromised hid can trivially infect the computer. Wait until 3AM when nobody is looking, then echo the keyboard shortcut to open IE and download badusb.exe. Badusb.exe then infects any new USB devices connected. Therefore, this is the opposite of diverse double- if ANY are infected, they'll all get infected.
This is slashdot and even here many people do not understand what this is all about.
People tend to think it's only a virus that is written to a flashdrive and it's not really that new or big of a threat, or that someone will create a usb-"firewall".
The fact that this vulnerability can be exploited in so many different ways, and even be persistent on a computer after infection (internal usb devices like webcam can be infected) makes it almost impossible to mitigate
Dangerously close to "Keyboard error. Press any key to continue."
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
The problem is not that the USB does not have a lock on it. It is that the stick has a chip on it that is a computer, and has its own writable area. Once compromised you wont see any additional files on it.
Maybe, just like with CD-ROMs, the OS should ignore the new keyboard until it is explicitly told what to do with it. Sure, it'd be a pain in the ass, but it's also a pain in the ass that my Linux system wants my password for every trivial thing I decide to do. Just add "plug in a new keyboard" to that list.
That's particularly tricky with keyboards. I still remember booting a computer with no keyboard, and a BIOS error message telling me "Keyboard not detected. Press F1 to continue."
John
Or even just "You have attached a keyboard," and delay 3 seconds before the keyboard is active. If you see that message when you plug in a USB drive or printer or something, you say "Oh crap!" and unplug it quick.
That still doesn't stop evil_keyboard.
evil_keyboard looks like a normal keyboard but waits until there's no activity for 2 hours and then sends a series of keystrokes.
I usually only see stars from bumping my head on the bottom of my desk after inserting a usb device. Takes a bit more than 3 seconds to have the eyes back on the screen.
An obvious problem with requiring the old hid to validate the new one is that a broken keyboard can't be replaced . Many times, there is no mouse (servers, ada, atm, etc) or the keyboard and mouse are one usb plug (wireless keyboard and mouse) . So you have one hid device and when it breaks you have no known hid device.
That's a good point. My dumb idea wouldn't work for systems that can't have two or more input devices each connected on discrete plugs, so a broken keyboard on a system with no other input devices would have to be replaced by at least two input devices that would then have to be used to verify each other. I can't offhand think of a good enough way to reliably distinguish between a fake HID impersonating a real one on the same connection, though, so something else would need to be done for wireless/shared connections.
A compromised hid can trivially infect the computer. Wait until 3AM when nobody is looking, then echo the keyboard shortcut to open IE and download badusb.exe. Badusb.exe then infects any new USB devices connected. Therefore, this is the opposite of diverse double- if ANY are infected, they'll all get infected.
While true, that only really applies if the compromised device is actually an input device like an infected keyboard that the user has already agreed to trust. The scope of the problem I was attempting to solve was limited more to preventing non-HIDs (like the random USB sticks people love to pick up in parking lots and plug into everything) from impersonating actual ones without user intervention. Those other issues would still need to be mitigated by other means (e.g., make HIDs incapable of receiving data, use only signed firmware, etc.).
Yeah, you're right. I keep forgetting the skill level of the programmers who will implement this. We'll totally end up with "click OK to allow this new mouse to provide input to your desktop" rather than something a tad more sane like blindly trusting the first device which, while not perfect, still makes us much better off than we are now.
Or, hell, what they totally won't think of is allowing users to configure different USB ports for different purposes, like maybe configuring only the two on the back of their computer, where the old PS/2 keyboard and mouse connectors used to be, to be allowed to connect to keyboards and mice. They also won't think of anything like maybe allowing the ports on the front of the computer to be configured as mass storage ports, and displaying a big scary warning if a keyboard is ever attached to one, to the effect of "keyboard attached to unauthorized port, do you wish to accept this new keyboard?"
No, there's no way they could ever find a sane way to resolve this problem. Best just to forget about it entirely and continue on as if no security problem has been noticed, because if there's one thing we can't count on Linux programmers doing, it's finding a sane and workable solution to a security issue.
Since NYBV I have mistrusted any media that can be be shared like a floppy disk. I have one USB drive with a live version of SuSE for non networked devices. Other than that, boot from network, and using the network to move files has always been my favorite way. I wonder if this could affect eSATA devices??
(1) Purchase the Phantom Keystroker from ThinkGeek
(2) Modify so it 'does' send the key code
(3) Claim you have invented new & novel malware technique
(4) Profit with free vacation at next security conference !!!