17 ms·

Unpatchable Malware That Infects USBs

198 points by joosters 12y ago

mark-r 12y ago
Is there something in the USB spec that requires the internal processor to be updatable? Couldn't they just lock the firmware down at the factory?
- mrsteveman1 12y ago
  Haven't read the spec, but yes they can. 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/ http://www.yubico.com/faq/upgrade-yubikey-firmware/).
- joosters 12y ago
  The firmware could be locked down, but doing so is inconvenient for the manufacturers. 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.
  - Karunamon 12y ago
    It could still be locked out before being sent to market as a final step, something like an internal fuse in an EPROM being blown in such a way that the only way to re-access the "manufacturer" bits would be to get a new chip.
    - linuxlizard 12y ago
      Tricky part is finding a bug in the firmware after release. If locked out, then can't update the stuff in the warehouses. Would need to scrap all parts in inventory, potentially costing hundreds if not thousands of dollars.
      - Thimothy 12y ago
        The logical thing to do, then, is making the firmware unaccesible once it's been used by the final user. Adding a fuse that breaks once the 5V from the user computer are sensed for the first time, for example.
        linuxlizard 12y ago
        How do you define "user computer"? We run a bazillion tests on our stuff during manufacturing. Stuff is plugged in/out of Windows boxes over and over on the manufacturing line. 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.
- johnsmith83756 12y ago
  No, there's nothing in the USB spec that requires the internal processor to be updatable. The headline is clickbait. 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.
  - joosters 12y ago
    I think you're wrong: as I understand it, many of the consumer USB sticks can be flashed over USB. No soldering required.
    - johnsmith83756 12y ago
      Yes, you're right - I've done some more research on the github site, and figured out how they do it. The burner image can be sent to RAM over USB, to cause the microcontroller to boot from it. Then, that burner is used to flash the malicous firmware image.
  - Zarathust 12y ago
    I can spot Wired articles just by the title now
- ajross 12y ago
  There's nothing in the USB spec that requires an internal processor at all. USB is a wire protocol only. Obviously it happens that complicated wire protocols are most sanely implemented in software, so most devices have CPUs and firmware. But that's a fact of engineering expedience and not spec compliance.
  - retroencabulato 12y ago
    I guess it depends on your definition of processor, but a finite state machine is certainly necessary to use USB.
jorgem 12y ago
Can't some of this be patched at the USB driver level in the OS? A storage device shouldn't be acting like a keyboard, etc.
- Guvante 12y ago
  I don't know if the current drivers would allow that normally. However they would allow it if you created a fake hub to route through. No way to know if there is a real hub or a fake one between the USB drive/keyboard and the computer.
- Someone1234 12y ago
  That's not how this works. 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.
  - jdmichal 12y ago
    Banning USB hubs isn't really workable either. Any keyboard which has USB slots would be blocked, for instance.
mmastrac 12y ago
This might protect against malware infecting your device unexpectedly, but I think there's a need for OS manufacturers to consider this as part of the holistic security. Why not pop up a dialog when a new USB device with HID profiles shows up that the OS hasn't seen?
- Guvante 12y ago
  Security researchers have been saying since USB became popular that hot plugging should require confirmation from the user. The only downside being that many users add a new HID as their only interface to the machine.
  - jedunnigan 12y ago
    Perhaps some kind of time lapse would solve that problem. The USB won't execute anything for x minutes while you inspect what it is really doing (if it's your keyboard or mouse, do nothing). If nothing is done, allow the USB to load its drivers, etc...
    - Someone1234 12y ago
      I just have to add Sleep(60 minutes) to my fake HID device and it will bypass this. You cannot blackhole HID input for an hour.
      - Nacraile 12y ago
        I'm not sure what that accomplishes. In order to provide input, the HID device must register itself with the OS, in order for the driver to be set up, etc. Sending HID messages without actually enumerating a HID device isn't going to work. Waiting 60 seconds to provide input doesn't change the fact that it has to tell the OS it can provide input in the first place. Yeah, it could wait 60 seconds to say "hey, a HID device just got plugged in", but that doesn't actually bypass the safety mechanism...
        deleted 12y ago
pmontra 12y ago
The rule in the '80s and early '90s was never ever exchange floppy disks with anybody and never insert other people's floppy disks in your PC. Enter the LAN and the USB sticks, problem solved. Not. 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.
- xeroxmalf 12y ago
  > I'm afraid we have to go back to exchanging files over the LAN. 1 horribly infected computer on a LAN can be a nightmare for everyone else connected.
  - freehunter 12y ago
    That's the definition of a worm.
kalleboo 12y ago
Am I the only one cringing at the use of the lone term "USB" to describe "USB flash drives" in this article? I would have expected more from Wired.
- fragsworth 12y ago
  I think you're in the minority. It's fairly common to hear someone say "USB" in place of "USB flash drive". Especially when it's used in plural, "USBs", it's hard to be confused about what they're referring to.
  - mnw21cam 12y ago
    USB refers to the bus, that is the wires and signals linking a device to the computer. People probably mean "USB device".
    - pyre 12y ago
      It's like arguing against people calling it an "ATM Machine" (i.e. an Automated Teller Machine Machine).
  - lukifer 12y ago
    I have never heard that before, it definitely sounds weird to my ears.
  - JustSomeNobody 12y ago
    I dunno. I hear "USB Drive" mostly. Never "USB flash drive" or just "USB". Sometimes "USB thingy".
    - lucaspiller 12y ago
      I was looking at laptops in my local supermarket and they had a special offer of a free "8GB FDD" with some laptops...
- nobodysfool 12y ago
parktheredcar 12y ago
Why so many Wired Magazine articles lately?
- JustSomeNobody 12y ago
  Somebody catching up on their reading, maybe?
S_A_P 12y ago
So from my possibly naive understanding of this article the new researchers want to publish the exploit on GitHub to ensure it gets fixed. But even they hold off on some of the worst exploit vectors because of an ethical dilemma. It would seem to me that any of this being published is probably as good as all of it for bad actors to reverse engineer the exploit and then study the usb spec and create new attacks. Just the mention of this sort of exploit is probably enough to make someone try and find it. So they seem to be contradicting themselves here. If it needs to be fixed and releasing will spur the industry into fixing it, it should be published. Is there something I am missing here? Serious question.
mariusz79 12y ago
Have usb device supply some kind of a checksum/key of its firmware when connecting to the computer.. the driver would then compare that checksum/key to the list of trusted checksums. But of course, hackers could extract the checksum from the driver, and hack the firmware to always return it :/
trarman 12y ago
Since this is like the old floppy disk days, where any disk could be infected, would a version of the same solution apply? I'm thinking of the old boot-sector protectors that would announce your disk is clean, thereby occupying the space a virus would otherwise claim. Of course there would have to be something in place to verify this wasn't just malware calling itself a protector.
- angry_octet 12y ago
  What this requires is called remote attestation. People have been working on this for smart cards and embedded systems, though PCs and VMs/cloud get more attention. It is very complex though. http://web.cs.wpi.edu/~guttman/pubs/remote_attest.pdf http://web.cs.wpi.edu/~guttman/pubs/remote_attest.pdf
anemic 12y ago
My dad collected some usb memory sticks from a trade show and he tried to empty them for his own use. One of the sticks he could't use: when plugged in, it sent keystrokes <windows key> + r + http://whatevermarketingsite.com http://whatevermarketingsite.com + enter. 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-webkeys.html http://blog.opensecurityresearch.com/2012/10/hacking-usb-web...
- chiph 12y ago
  A common social engineering trick is to drop some USB sticks that have keyloggers, etc. loaded on them in the employee parking area of the target firm. Sooner rather than later, someone will plug one into a corporate machine...
  - eli 12y ago
    Sure, but my recollection is that depended on either Windows Autorun (which hasn't been the default for quite a while) or people being curious/foolish enough to execute a file they find on the drive. This is a lot more insidious.
    - shabble 12y ago
      IIRC a talk by Travis Goodspeed mentioned that it was only internally disabled for USB and writeable media. If a USB device presents itself as a CDROM, it can still autorun things unless globally disabled by the user. 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.
      - TazeTSchnitzel 12y ago
        This is how U3 drives, when they existed, were able to work. They emulated a tiny CD drive with an autorun bootstrap.
spullara 12y ago
There needs to be a built-in pairing button on the computer that you have to press to allow a new device to be activated. Sadly, it probably won't stop this attack because when they plug it in they will just press the button.
Animats 12y ago
This attack vector could also be used by USB charging devices. That's been done before using Windows vulnerabilities, but this is more general.
rblatz 12y ago
When I bought my last car, they sent what appeared to be a USB flash drive. It had some warranty documents on it, and also emulated a keyboard. I think it popped up a browser went to a webpage and prefilled my VIN and some other details so I could register my car. This was several years ago. How is this different?
- drivingmenuts 12y ago
  That was probably done as an application that ran from the USB stick, similar to the way AUTOEXEC.BAT works on Windows (it sees it on mount, it runs it). I think the exploit version occurs at a lower level down in the bios of the stick, where it's far more insidious.
  - rblatz 12y ago
    I thought I remembered windows saying it detected a new keyboard device, or my brain may have invented that part. I'll see if I can't find it laying around and see how it actually worked.
chrisBob 12y ago
I have been thinking about creating an active "USB Condom" for a while, and this might be the right time to work on it. It would be pretty straight forward to make a device that sits between a PC and a USB device and monitors the traffic. It could allow only certain device classes, or it could ask you to press a button for each file moved. My original thought was to stop the spread of viruses that are designed to move between computers over USB drives (my last job had a lot of trouble with these), but preventing it from showing up as a HID would also be useful in this case. 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.
- chrisBob 12y ago
  Perhaps its time for me to create a KickStarter account.
  - daveloyall 12y ago
    Bonus points for a "keyboard macro" mode.
- drivingmenuts 12y ago
  You mean like this? http://syncstop.com/ http://syncstop.com/
  - chrisBob 12y ago
    I knew someone would mention that, and I almost put a note about it in my post. I think all that does is disconnect the data pins, so it wouldn't be too useful when you are attaching a flash drive to your computer.
    - drivingmenuts 12y ago
      Good point. 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.
kazinator 12y ago
> To prevent USB devices’ firmware from being rewritten, their security architecture would need to be fundamentally redesigned, he argued, so that no code could be changed on the device without the unforgeable signature of the manufacturer. 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).
- angry_octet 12y ago
  But how do you know the write protect switch actually works? Maybe the manufacturer implemented it as a flag to the microcontroller. Maybe your 'trusted' USB stick was replaced by one that looks exactly the same but that has a different chip inside that mimics the vendor/device ID. So you are back to requiring trusted hardware and trusted handling, which is impractical except for strictly controlled systems.
  - kazinator 12y ago
    The trusted USB stick being replaced by a lookalike is a breach of physical security somewhere in the delivery chain between manufacturer and you. In that case, the programmability issue is moot; neither the original USB stick nor the rogue one have to have field-programmable firmware. The rogue one is hard-coded at manufacture time to do harm. 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".
aus_ 12y ago
Not to understate the severity of this issue, but how is this any different than if I built a custom device that contained a USB hub + emulated HID keyboard to fire off a malicious macro + flash storage housed inside a plastic shell that looked like a normal flash drive? I guess that would require developing and manufacturing custom hardware. 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.
- InclinedPlane 12y ago
  It's very different because your device is just one device. "BadUSB" type malware can spread like a virus/worm by infecting other devices. In your scenario the specially crafted device is the only infection point. With BadUSB an infected device is just patient zero. It infects computers, which in turn infect other devices plugged into it, which infect other computers, and so on and so forth.
  - aus_ 12y ago
    Ah! Got it now. Thanks. Ok. Now I'm concerned.
greedo 12y ago
USB is just so vulnerable... Kali Nethunter is now exploiting some of its idiocy. http://www.kali.org/kali-linux-nethunter/ http://www.kali.org/kali-linux-nethunter/
- verbatim 12y ago
  Is USB vulnerable or are many USB implementations vulnerable?
EvanAnderson 12y ago
Here's the talk from DerbyCon that the article is talking about: http://www.youtube.com/watch?v=xcsxeJz3blI http://www.youtube.com/watch?v=xcsxeJz3blI
ambrop7 12y ago
> showing that it’s possible to corrupt any USB device with insidious, undetectable malware 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).
sauere 12y ago
Do we really need to repost this every 2 months? The first proof of concept for this kind of attack has been demonstrated 7+ years ago at the CCC. It pops up every year and every time people act like this is news.
- fyrabanks 12y ago
  Source?
angry_octet 12y ago
The only way to mitigate against these attacks is to treat the USB bus the same way we treat the network: - Communication with devices should only occur once they have been identified & authenticated - Authenticated devices can only send type specific messages and can't change type without re-authentication. - Data should be written as encrypted volumes to storage devices. (You should be doing this anyway.) 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.
methodology 12y ago
USB devices need to be regulated to ensure this kind of thing can't happen. Perhaps the FCC's arm reaches far enough that they could tackle this issue, otherwise maybe a separate task force should be created for this.
userbinator 12y ago
It's been nearly 2 decades since USB was invented and I'm still of the opinion that USB keyboards provide no significant benefits over PS/2 in the majority of applications today - a keyboard that is always plugged into the same port. All the extra driver complexity and security holes like this could be avoided if people realised this simple fact. 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.)
- rbobby 12y ago
  > significant benefits over PS/2 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).
  - userbinator 12y ago
    > 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. 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.

198 points by joosters 12y ago

Is there something in the USB spec that requires the internal processor to be updatable? Couldn't they just lock the firmware down at the factory?

mrsteveman1 12y ago
Haven't read the spec, but yes they can. 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/ http://www.yubico.com/faq/upgrade-yubikey-firmware/).
joosters 12y ago
The firmware could be locked down, but doing so is inconvenient for the manufacturers. 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.
- Karunamon 12y ago
  It could still be locked out before being sent to market as a final step, something like an internal fuse in an EPROM being blown in such a way that the only way to re-access the "manufacturer" bits would be to get a new chip.
  - linuxlizard 12y ago
    Tricky part is finding a bug in the firmware after release. If locked out, then can't update the stuff in the warehouses. Would need to scrap all parts in inventory, potentially costing hundreds if not thousands of dollars.
    - Thimothy 12y ago
      The logical thing to do, then, is making the firmware unaccesible once it's been used by the final user. Adding a fuse that breaks once the 5V from the user computer are sensed for the first time, for example.
      - linuxlizard 12y ago
        How do you define "user computer"? We run a bazillion tests on our stuff during manufacturing. Stuff is plugged in/out of Windows boxes over and over on the manufacturing line. 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.
johnsmith83756 12y ago
No, there's nothing in the USB spec that requires the internal processor to be updatable. The headline is clickbait. 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.
- joosters 12y ago
  I think you're wrong: as I understand it, many of the consumer USB sticks can be flashed over USB. No soldering required.
  - johnsmith83756 12y ago
    Yes, you're right - I've done some more research on the github site, and figured out how they do it. The burner image can be sent to RAM over USB, to cause the microcontroller to boot from it. Then, that burner is used to flash the malicous firmware image.
- Zarathust 12y ago
  I can spot Wired articles just by the title now
ajross 12y ago
There's nothing in the USB spec that requires an internal processor at all. USB is a wire protocol only. Obviously it happens that complicated wire protocols are most sanely implemented in software, so most devices have CPUs and firmware. But that's a fact of engineering expedience and not spec compliance.
- retroencabulato 12y ago
  I guess it depends on your definition of processor, but a finite state machine is certainly necessary to use USB.

jorgem 12y ago

Can't some of this be patched at the USB driver level in the OS? A storage device shouldn't be acting like a keyboard, etc.

Guvante 12y ago
I don't know if the current drivers would allow that normally. However they would allow it if you created a fake hub to route through. No way to know if there is a real hub or a fake one between the USB drive/keyboard and the computer.
Someone1234 12y ago
That's not how this works. 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.
- jdmichal 12y ago
  Banning USB hubs isn't really workable either. Any keyboard which has USB slots would be blocked, for instance.

mmastrac 12y ago

This might protect against malware infecting your device unexpectedly, but I think there's a need for OS manufacturers to consider this as part of the holistic security. Why not pop up a dialog when a new USB device with HID profiles shows up that the OS hasn't seen?

Guvante 12y ago
Security researchers have been saying since USB became popular that hot plugging should require confirmation from the user. The only downside being that many users add a new HID as their only interface to the machine.
- jedunnigan 12y ago
  Perhaps some kind of time lapse would solve that problem. The USB won't execute anything for x minutes while you inspect what it is really doing (if it's your keyboard or mouse, do nothing). If nothing is done, allow the USB to load its drivers, etc...
  - Someone1234 12y ago
    I just have to add Sleep(60 minutes) to my fake HID device and it will bypass this. You cannot blackhole HID input for an hour.
    - Nacraile 12y ago
      I'm not sure what that accomplishes. In order to provide input, the HID device must register itself with the OS, in order for the driver to be set up, etc. Sending HID messages without actually enumerating a HID device isn't going to work. Waiting 60 seconds to provide input doesn't change the fact that it has to tell the OS it can provide input in the first place. Yeah, it could wait 60 seconds to say "hey, a HID device just got plugged in", but that doesn't actually bypass the safety mechanism...
      - deleted 12y ago

pmontra 12y ago

The rule in the '80s and early '90s was never ever exchange floppy disks with anybody and never insert other people's floppy disks in your PC. Enter the LAN and the USB sticks, problem solved. Not. 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.

xeroxmalf 12y ago
> I'm afraid we have to go back to exchanging files over the LAN. 1 horribly infected computer on a LAN can be a nightmare for everyone else connected.
- freehunter 12y ago
  That's the definition of a worm.

kalleboo 12y ago

Am I the only one cringing at the use of the lone term "USB" to describe "USB flash drives" in this article? I would have expected more from Wired.

fragsworth 12y ago
I think you're in the minority. It's fairly common to hear someone say "USB" in place of "USB flash drive". Especially when it's used in plural, "USBs", it's hard to be confused about what they're referring to.
- mnw21cam 12y ago
  USB refers to the bus, that is the wires and signals linking a device to the computer. People probably mean "USB device".
  - pyre 12y ago
    It's like arguing against people calling it an "ATM Machine" (i.e. an Automated Teller Machine Machine).
- lukifer 12y ago
  I have never heard that before, it definitely sounds weird to my ears.
- JustSomeNobody 12y ago
  I dunno. I hear "USB Drive" mostly. Never "USB flash drive" or just "USB". Sometimes "USB thingy".
  - lucaspiller 12y ago
    I was looking at laptops in my local supermarket and they had a special offer of a free "8GB FDD" with some laptops...
nobodysfool 12y ago

parktheredcar 12y ago

Why so many Wired Magazine articles lately?

JustSomeNobody 12y ago
Somebody catching up on their reading, maybe?

S_A_P 12y ago

So from my possibly naive understanding of this article the new researchers want to publish the exploit on GitHub to ensure it gets fixed. But even they hold off on some of the worst exploit vectors because of an ethical dilemma. It would seem to me that any of this being published is probably as good as all of it for bad actors to reverse engineer the exploit and then study the usb spec and create new attacks. Just the mention of this sort of exploit is probably enough to make someone try and find it. So they seem to be contradicting themselves here. If it needs to be fixed and releasing will spur the industry into fixing it, it should be published. Is there something I am missing here? Serious question.

mariusz79 12y ago

Have usb device supply some kind of a checksum/key of its firmware when connecting to the computer.. the driver would then compare that checksum/key to the list of trusted checksums. But of course, hackers could extract the checksum from the driver, and hack the firmware to always return it :/

trarman 12y ago

Since this is like the old floppy disk days, where any disk could be infected, would a version of the same solution apply? I'm thinking of the old boot-sector protectors that would announce your disk is clean, thereby occupying the space a virus would otherwise claim. Of course there would have to be something in place to verify this wasn't just malware calling itself a protector.

angry_octet 12y ago
What this requires is called remote attestation. People have been working on this for smart cards and embedded systems, though PCs and VMs/cloud get more attention. It is very complex though. http://web.cs.wpi.edu/~guttman/pubs/remote_attest.pdf http://web.cs.wpi.edu/~guttman/pubs/remote_attest.pdf

anemic 12y ago

My dad collected some usb memory sticks from a trade show and he tried to empty them for his own use. One of the sticks he could't use: when plugged in, it sent keystrokes <windows key> + r + http://whatevermarketingsite.com http://whatevermarketingsite.com + enter. 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-webkeys.html http://blog.opensecurityresearch.com/2012/10/hacking-usb-web...

chiph 12y ago
A common social engineering trick is to drop some USB sticks that have keyloggers, etc. loaded on them in the employee parking area of the target firm. Sooner rather than later, someone will plug one into a corporate machine...
- eli 12y ago
  Sure, but my recollection is that depended on either Windows Autorun (which hasn't been the default for quite a while) or people being curious/foolish enough to execute a file they find on the drive. This is a lot more insidious.
  - shabble 12y ago
    IIRC a talk by Travis Goodspeed mentioned that it was only internally disabled for USB and writeable media. If a USB device presents itself as a CDROM, it can still autorun things unless globally disabled by the user. 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.
    - TazeTSchnitzel 12y ago
      This is how U3 drives, when they existed, were able to work. They emulated a tiny CD drive with an autorun bootstrap.

spullara 12y ago

There needs to be a built-in pairing button on the computer that you have to press to allow a new device to be activated. Sadly, it probably won't stop this attack because when they plug it in they will just press the button.

Animats 12y ago

This attack vector could also be used by USB charging devices. That's been done before using Windows vulnerabilities, but this is more general.

rblatz 12y ago

When I bought my last car, they sent what appeared to be a USB flash drive. It had some warranty documents on it, and also emulated a keyboard. I think it popped up a browser went to a webpage and prefilled my VIN and some other details so I could register my car. This was several years ago. How is this different?

drivingmenuts 12y ago
That was probably done as an application that ran from the USB stick, similar to the way AUTOEXEC.BAT works on Windows (it sees it on mount, it runs it). I think the exploit version occurs at a lower level down in the bios of the stick, where it's far more insidious.
- rblatz 12y ago
  I thought I remembered windows saying it detected a new keyboard device, or my brain may have invented that part. I'll see if I can't find it laying around and see how it actually worked.

chrisBob 12y ago

I have been thinking about creating an active "USB Condom" for a while, and this might be the right time to work on it. It would be pretty straight forward to make a device that sits between a PC and a USB device and monitors the traffic. It could allow only certain device classes, or it could ask you to press a button for each file moved. My original thought was to stop the spread of viruses that are designed to move between computers over USB drives (my last job had a lot of trouble with these), but preventing it from showing up as a HID would also be useful in this case. 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.

chrisBob 12y ago
Perhaps its time for me to create a KickStarter account.
- daveloyall 12y ago
  Bonus points for a "keyboard macro" mode.
drivingmenuts 12y ago
You mean like this? http://syncstop.com/ http://syncstop.com/
- chrisBob 12y ago
  I knew someone would mention that, and I almost put a note about it in my post. I think all that does is disconnect the data pins, so it wouldn't be too useful when you are attaching a flash drive to your computer.
  - drivingmenuts 12y ago
    Good point. 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.

kazinator 12y ago

> To prevent USB devices’ firmware from being rewritten, their security architecture would need to be fundamentally redesigned, he argued, so that no code could be changed on the device without the unforgeable signature of the manufacturer. 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).

angry_octet 12y ago
But how do you know the write protect switch actually works? Maybe the manufacturer implemented it as a flag to the microcontroller. Maybe your 'trusted' USB stick was replaced by one that looks exactly the same but that has a different chip inside that mimics the vendor/device ID. So you are back to requiring trusted hardware and trusted handling, which is impractical except for strictly controlled systems.
- kazinator 12y ago
  The trusted USB stick being replaced by a lookalike is a breach of physical security somewhere in the delivery chain between manufacturer and you. In that case, the programmability issue is moot; neither the original USB stick nor the rogue one have to have field-programmable firmware. The rogue one is hard-coded at manufacture time to do harm. 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".

aus_ 12y ago

Not to understate the severity of this issue, but how is this any different than if I built a custom device that contained a USB hub + emulated HID keyboard to fire off a malicious macro + flash storage housed inside a plastic shell that looked like a normal flash drive? I guess that would require developing and manufacturing custom hardware. 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.

InclinedPlane 12y ago
It's very different because your device is just one device. "BadUSB" type malware can spread like a virus/worm by infecting other devices. In your scenario the specially crafted device is the only infection point. With BadUSB an infected device is just patient zero. It infects computers, which in turn infect other devices plugged into it, which infect other computers, and so on and so forth.
- aus_ 12y ago
  Ah! Got it now. Thanks. Ok. Now I'm concerned.

greedo 12y ago

USB is just so vulnerable... Kali Nethunter is now exploiting some of its idiocy. http://www.kali.org/kali-linux-nethunter/ http://www.kali.org/kali-linux-nethunter/

verbatim 12y ago
Is USB vulnerable or are many USB implementations vulnerable?

EvanAnderson 12y ago

Here's the talk from DerbyCon that the article is talking about: http://www.youtube.com/watch?v=xcsxeJz3blI http://www.youtube.com/watch?v=xcsxeJz3blI

ambrop7 12y ago

> showing that it’s possible to corrupt any USB device with insidious, undetectable malware 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).

sauere 12y ago

Do we really need to repost this every 2 months? The first proof of concept for this kind of attack has been demonstrated 7+ years ago at the CCC. It pops up every year and every time people act like this is news.

fyrabanks 12y ago
Source?

angry_octet 12y ago

The only way to mitigate against these attacks is to treat the USB bus the same way we treat the network: - Communication with devices should only occur once they have been identified & authenticated - Authenticated devices can only send type specific messages and can't change type without re-authentication. - Data should be written as encrypted volumes to storage devices. (You should be doing this anyway.) 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.

methodology 12y ago

USB devices need to be regulated to ensure this kind of thing can't happen. Perhaps the FCC's arm reaches far enough that they could tackle this issue, otherwise maybe a separate task force should be created for this.

userbinator 12y ago

It's been nearly 2 decades since USB was invented and I'm still of the opinion that USB keyboards provide no significant benefits over PS/2 in the majority of applications today - a keyboard that is always plugged into the same port. All the extra driver complexity and security holes like this could be avoided if people realised this simple fact. 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.)

rbobby 12y ago
> significant benefits over PS/2 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).
- userbinator 12y ago
  > 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. 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.