Hacking USB Firmware 97
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.)
back in my day... (Score:5, Funny)
we used black tape over the write protect notch on our floppy disks and we LIKED IT THAT WAY
Re:back in my day... (Score:5, Informative)
Back in my day we used to cut another write enable notch on the opposite side of floppy disks so we could write data on both sides.
Re: (Score:2)
Ah the days of double sided floppy disks where you could get another 140K on Apple ][. :-)
140K = 35 tracks * 16 sectors * 256 bytes/sector
Of course the coolest hack was to add a "write-protect" switch to the drive :-)
http://apple2online.com/web_do... [apple2online.com]
---
Grumpy gamer: Get off my LAN
Re: (Score:2)
Indeed. :-)
Re: (Score:3)
As if no other folks thought of this..... except every geek with a TRS-80, Atari 400/800/XL/XE, Apple II and Osborne I.....
Re: (Score:3, Funny)
How would that work? Unless you removed the metal cover that protects the disk.
It's the September thing again, lol. (Score:2)
lol.
Re:back in my day... (Score:5, Funny)
Re: (Score:1)
older tech [lmgtfy.com]
Re: (Score:1)
back in my day, we used to hole-punch the disk and then rotate it a little in the shell so you wouldn't see the hole, and then wait for the next person to try to use it.
Re: (Score:1)
Back in my day we cut or own notches on the disk to make them double sided. Still today buying the 5v version of the USB to serial converter simply requires popping open the shell (no glue - that's another expense), and soldering the lead to the 3v strip. I used to be able to do about a dozen per hour once I got rolling. I'm pretty sure a switch would be harder. Of course I could mount the file sytem read only. But for maximum protection, you should make it WRITE only. Go ahead and dump whateVEr virus you
Re: (Score:2, Interesting)
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.
When they first came out, they had them. I think manufacturers started leaving them off because they could save a tenth of a cent on their cost. I still have a couple of old ones laying around with a switch, though they are small (like 128mb).
Re: (Score:1)
yaay! (Score:1)
Finally I can run a beowulf cluster of usb sticks!
wait... C#. Does that run on linux? Has mono added .Net UI yet?
Re: yaay! (Score:2)
Locking USB... (Score:1)
Re:Locking USB... (Score:5, Informative)
Re: (Score:3)
Lock Switch? Then you don't understand the problem.
Right back at you.
The lock switch would be a high-level function that returns an error on a generic block device write command. Hacking the USB device isn't hacking the flash memory, it's hacking the firmware on the 8051.
I downloaded the first flash datasheet I could google, by way of proving that you have not the first clue what you are on about. It was for the Hynix HY27UF084G2M (512Mx8bit) NAND Flash chip. On page 6 I find out that the write enable signal is called WE, like always. And on page 7 I find out that it's on pin 18. What do you suppose happens if I switch open pin 18?
Re: (Score:2)
You are forgetting that controller chips have their own flash too, on the same chip as the controller itself. This often can be modified from the program running on the controller. Fuses may be able to disable this.
Sure, I'm aware of that. But if they don't have a WE pin for their firmware flash, that's because someone involved in their design and production is a massive asshole.
Re: (Score:3)
You can lock the flash memory as much as you like. The PRAM on the Phison chip is unaffected.
What is being reprogrammed is the Phison control chip. There is no write enable pin on the Phison chip. It has a pin to control the write lock of the flash memory, but that has no effect on the Phison PRAM where the firmware resides.
Re:Locking USB... (Score:5, Informative)
On page 6 I find out that the write enable signal is called WE, like always. And on page 7 I find out that it's on pin 18. What do you suppose happens if I switch open pin 18?
Most likely the whole device would stop working completely. You probably wanted the WP (write protect) line. The WE line is used for other functionality, as explained on page 9.
Even then, you are looking at the wrong flash memory. You are looking at the bulk memory used for storing user data. The microcontroller that handles the USB interface has its own internal flash memory, typically quite small at less than 1M words. That is where it's program code is stored, and microcontrollers rarely have an external write protect pin. Sometimes there is memory protection built in, but typically it only prevents you reading the program code and doesn't stop you erasing and replacing it with your own. Besides which, many deliberately include a handy bootloader so that the manufacturer can easily write their firmware over the USB interface without special tools.
Even if you somehow did secure the microcontroller it wouldn't be hard to replace with a hot air gun. Basically, no matter what you do, USB devices can't be trusted.
Re: (Score:2)
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.
Signed Firmware (Score:5, Insightful)
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.
Re: (Score:2)
How about mounting the filesytem read-only?
Re:Signed Firmware (Score:4, Informative)
Re: (Score:1)
Re: (Score:3)
I feel like I died and woke up on a movie set.
No, I'm sure that didn't happen. Here there a low ratio of women and not a lot of good looking people period.
Congress maybe...
Re: (Score:2)
The nerds are all off typing two-at-a-time on their keyboards. :)
Re:Signed Firmware (Score:5, Informative)
You're completely misunderstanding the problem. It has nothing to do with flash drives, it has to do with USB devices, some of which happen to appear as block devices. Every USB device that you plug in has a controller chip, which runs a small program (the firmware) that implements the client part of the USB specification. Some of these are quite complex. There was an attack a few years ago on USB keyboards: some models come with 128KB of flash but only use 65KB for the firmware. You can replace the firmware with something malicious and have 31KB to cache keylog data for emptying when you plug in a specific device.
The firmware on the controller chips is not public, not audited, and generally written by people who have no idea about security. If there's a bug in it that allows a compromise, then you can use the controller to attack the host system. Lots of USB drivers behave poorly in the presence of malformed USB protocol messages, so all you need is to find one buffer overflow and you've got a kernel-mode exploit. Worse, some of the vulnerabilities are not in the drivers, but in the firmware of the USB host controller chip on the motherboard. If you can compromise that, then you can sniff a load of messages going across the bus in a way that's completely undetectable from the OS.
Re: (Score:2)
Most operating systems moved the USB stack out of the kernel long ago.
Also, compromised USB firmware won't let you sniff the entire bus, only messages sent to and from the compromised device. USB doesn't use a shared bus for all devices, each device instead only gets messages directed to itself. I suppose if you compromised a hub's firmware you could see all traffic to devices connected to the hub, but hubs usually don't have flashable firmware as the ICs are dedicated single purpose devices.
Re: (Score:2)
Re:Signed Firmware (Score:4, Insightful)
Firmware signing will help that vector but that's only one type of threat.
Your average USB/SD/whaterver flash storage device contains an interface/flash controller SoC that has 100(ish)mhz 32bit arm/mips core, some ram, and it's own embeded flash.
These things are made by the millions every day, as cheaply as possible. They then go in to devices users jam in to every available port on their computers without a second thought.
Anyone who's remotely aware of what computing security is all about knows what this means. You can't trust USB devices. Your hardware and OS /must/ treat them as hostile. You are effectively interfacing unknown/untrusted/un-auditable computer systems with trusted ones.
Any flash device could carry hidden code you can't audit, and it's being given physical access to user's computers as a matter of of course. A few changed lines of code could turn a factory programming process in to a mass exploit vector.
How secure do you think your OS's USB stack is? How will it behave if, say, that flash drive re-initializes itself as a composite device with an HID keyboard/mouse and starts spitting out commands? How do your tell your computer to only obey input from authorized keyboards and mice? A USB device can present itself as just about anything. Input, network interface, storage device...
Re: (Score:1)
So reinstalling a system after a breach is not enough anymore...
Re: (Score:2)
Realistically the damage that a USB device can do is fairly limited. If it set itself up as a keyboard and tried to execute commands you would very quickly notice what was happening on the screen in front of you. If you are really worried it isn't hard to lock most operating systems down to prevent new USB devices being auto-configured. Here's a guide for Windows: http://msdn.microsoft.com/en-u... [microsoft.com]
Of more concern are Thunderbolt, Firewire and PC Card, because they both allow devices DMA access to your comput
Re:Signed Firmware (Score:4, Funny)
Well, back in my day, you used to have to expose the IC to a UV light to get it to clear the registers so you could even install a new firmware. These young kids with their newfangled firmware flash images! (get off my lawn)
Those little windows... (Score:5, Informative)
...were made of fused quartz, because UV wont go thru normal glass.
That's why the erasable ones were so expensive.
Re: (Score:2)
The UV light damages the silicon over time, degrading the oxide layer.
It will fail to some other structure, and stick high or low eventually.
A good cosmic ray strike while you're programming at 21V can make one popcorn open, lol.
Write-protect the microcontroller firmware, silly. (Score:2)
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".
Re: (Score:1)
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.
Re: (Score:2)
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... [wikipedia.org] ?
Re: (Score:2)
Re: (Score:2)
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."
Re: (Score:3)
Re: (Score:1)
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 keyboa
Re: (Score:2)
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.
Re: (Score:1)
Keyboard not found, press enter to continue.
Re: (Score:2)
Dangerously close to "Keyboard error. Press any key to continue."
Re: (Score:2)
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.
Re: (Score:1)
Re: (Score:1)
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.
Re: (Score:1)
Even then, that's of limited help. A lot of microcontroller security features can be bypassed, that's not always so easy. And having the bootloader only accept signed images is also exploitable. Just look at the gaming consoles developped with budgets of hundreds of millions (xbox360, PS3, wii...), even if they all have those security "features", *all* of them still got hacked. Now we're taking about a for a low-price item with razor thin profit margins, with a nearly non-existent development budget. This w
Re: (Score:1)
Re: (Score:2)
[quote]short of someone stealing their private key.[/quote]
And there you go. Hence why this is ultimately unfixable.
Re: (Score:2)
A write-protect switch won't help you here, Timothy.
Why not?
They're going and reflashing the microcontroller, which means
...that if the WP switch is physically connected to the WE line on the flash modules, that it will still work just fine.
Write protect switch. (Score:1)
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...
Re: (Score:1)
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.
Re: (Score:3, Insightful)
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
physical write protect for the firmware (Score:2)
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.
Re: (Score:3)
Punch cards! (Score:1)
I'm going back to punch cards!!!
Re: (Score:1)
I'm going back to punch cards!!!
http://ask.metafilter.com/1430... [metafilter.com]
Re: (Score:2)
In use since 1890!
Wired shouldn't write tech articles (Score:3, Interesting)
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.
Re: (Score:2)
The others tend to be less common, more expensive, and/or much less often externally exposed. None are innocent; but USB certainly looks like the most dangerous culprit.
portability and HID (Score:2)
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 ke
Re: (Score:1)
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.
Why not just make the confirmation dialog require a different (or different type of) input device to confirm a newly-connected one? E.g., a 'new keyboard' connection would have to be verified via mouse gesture and vice versa, or keyboard2 would need input from keyboard1 (if no other type of device was present), etc. After all, it's probably slightly less likely that ALL of a user's connected USB devices are malicious...
keyboard breaks = computer trashed, ANY compromise (Score:3)
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 dow
Easy solution (Score:1)
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!
Re: (Score:2)
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 [opendevices.ru].
Severity not understood by media or most people (Score:3, Insightful)
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
I have always disliked USB drives (Score:1)