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'm going back to punch cards!!!
With these tools in the wild, that switch better protect against firmware updates as well, or the first firmware reflashing botnet will get your system too.
placebos are great aren't they
that write protect switch is likely something enforced by the firmware, and likely not something that can enforce writing to the firmware
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.
I have a 32 Meg USB flash drive that has a switch also. The problem I had was the switch was the first thing that died on it, and it was in Write Protect mode.
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!
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
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...
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.
It probably controls the write protect pin of the USB flash controller. For example pin 7 in UT163.
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
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.
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??