Tweet
Issues and claims like these have caused some people to be cautious with choosing which USB devices they should allow to have connected to their machines: So-called BadUSB
* http://www.pcworld.com/article/24605...computers.html
* https://srlabs.de/badusb/
This is in addition to the older:
* http://www.wired.com/2011/06/the-dropped-drive-hack/ (leaving USB devices laying about)
* http://thenextweb.com/insider/2011/0...take-the-bait/
And the even older, but somewhat related:
* https://www.schneier.com/blog/archiv...aid_attac.html
On the topic of a "howto make an example 'bad usb' device" for certain types of USB devices: emulated keyboard, or comment on bootable device
* http://null-byte.wonderhowto.com/how...d-usb-0165419/ (The two attacks mentioned here are not the limit of attacks possible with USB and other firmware in devices like USB that register with the OS. Pretending to be a keyboard and transmitting keystrokes is likely to be able to hit more diverse OS, than one that breaks driver loading in OS.)
And also peripherally related to this is "juice jacking" -- also over USB, and risk for data theft: (avoid with use of "USB condom" or similar functioning cable, but USB Condoms are not a "fix" for "Bad USB" as it prevents expected USB device function, so is a non-fix for bad-usb):
* http://www.wallofsheep.com/pages/juice
* http://krebsonsecurity.com/2011/08/b...juice-jacking/
MS Attempts to patch one example of exploit using badusb in one way: https://threatpost.com/microsoft-pat...ttacks/114240/ (.LNK vulnerability and multiple attempts to fix. https://technet.microsoft.com/library/security/ms15-085 https://technet.microsoft.com/library/security/ms10-046 )
One suggestion is a policy change on use of USB device: (Policies are hard to enforce and police. Consider rogue access points in office environments, and smartphones becoming hotspots. Additionally, executives often assume the rules dictated do not apply to them, and employees learn from example. If setting policies were effective, laws to make murder illegal would have stopped murders.)
* http://www.scmagazine.com/badusb-wha...rticle/388700/
The driver/firmware issues is not just limited to USB. It is also an issue with PCMCIA, PC cards, PC Express cards, CardBus cards, PCI cards, PICe, firewire, and maybe eSATA and more -- many of these high-speed data channels allow foreign devices to pass code for how to talk with it to the device's bus controller and running OS, and these end up running with privileged access, often system or kernel level. This problem is similar to trusting websites with their Java and/or JavaScript, running code on your own machine at a "user" level, but instead driver/firmware usually happens at the system/kernel level.
What have you done to mitigate these risks?
* Super-glue all your USB/eSATA,PC-card/* ports so devices can't be inserted/connected into them?
* Open the motherboard and disconnect all of these data channel connector cables from the motherboard?
* Disable from BIOS? Add Setup and Boot password to BIOS?
* Remove support for these pieces of hardware from your custom-built kernel?
* Nothing? It's nothing isn't it? I'm betting this is what most people have done.
Many modern computers no longer ship with exclusive keyboard/mouse ports like PS/2 interface, but rely on USB, so at least 2 USB ports will likely be open on most modern desktops.
Few people would make their own kernel these days, but even if they did, and their hardware requires USB for keyboard and/or mouse, there is still a problem unless it is meant to be run headless and without keyboard.
I have been thinking about this. in my day-to-day, I sometimes have need to copy things over "air gap" aka "sneaker net" to machines that are not on any network, and do not have support for wireless networks of any kind. However, they do have USB ports. But the question? Do I trust all of the people and all of the devices they inserted into this computer? Do I trust all the people they trust that have had physical access to this computer? It is like that old "sex ed" framing of sexual promiscuity and risk for STD as "when you have sex with a person, it is like having sex with all the people they had sex with, and the people they had sex with, on and on."
If it is possible to "pwn" (take over) a computer system's kernel/system with USB (or other) devices, and have your malicious code run with the privileges of the kernel, and then once the system is owned, overwrite firmware on other USB devices that are inserted, then it may be possible to spread an infection from one machine to multiple USB devices to multiple machines.
It is not as easy as this, however. Updating firmware of a device in such a way that the device continues to function without observable degraded performance is not easy, and with the large number of vendors, models, and variations of USB hardware, and target OS to infect plus their versions and variations including architecture, crafting malware that would recognize each model of USB device and device ID and only package and install altered firmware for the target device (assuming it has enough space for the malware and the functional code to keep the device working) could easily make the malware very large and not fit. Certainly, it is possible an infection could install a basic root-kit that then downloads from the Internet much more data, that creates problems with non-network machines being fully infected, and risk for detection with network monitoring and local file scanning.
Even with all of these complications, it is likely someone will find a way to simplify attacks, or select subsets of supported devices, and OS to make an attack spread quickly, and not be easily detected.
With all of the above in mind, what have you done to mitigate these risks?
One idea I've had is to use a simple USB thumb-drive that supports a single "Micro SD" card, and then allow that USB device to be inserted into any computers that are not mine, and then when I need the data stored on the Micro SD, I can remove the Micro SD from the USB device, and insert just the Micro SD into a full-sized SD adapter and then into my computer's SD slot -- treating it like an old-fashioned Floppy/Stiffie disk. If the little USB device becomes infected, I may spread an infection to other devices that use USB when connected, but so long as I don't connect it to my machine, my machine should be free from attack with that device. (If machine that is not mine has a SD port, then i can use that instead of a USB device that has been connected to many computers.) This does not prevent "badusb" and if it ever becomes wide-spread, the USB device with SD support may be used to spread a 'badusb" infection. All it does it try to protect my own computer(s).
This does not help against cases where "bad people" have physical access to my computer (Evil maid attack, or others), but it might help me with getting data to/from my computer with connecting non-trusted USB devices to it.
I suspect someone has done this for Linux:
Add support in the linux kernel to run your own custom USB (and other device) code, and intercept the device and vendor ID for each device, and then compare this plus other data to those devices that you trust, and if any non-trusted USB device is inserted, immediately halt the OS without caching anything to disk. This is dangerous even with FS that support true journaling filesystems. If this defense is known by an attacker, they can also probably buy the same vendor/device ID as one that you have and use that, but this would be a targetted attack, and most attacks are non-targetted, but instead are automated.
What are your thoughts to this problem of "BAD USB" and other devices? What actions have you taken? What thoughts do you have on defenses that could be created to mitigate attacks that might use this to deliver payloads?
* http://www.pcworld.com/article/24605...computers.html
* https://srlabs.de/badusb/
This is in addition to the older:
* http://www.wired.com/2011/06/the-dropped-drive-hack/ (leaving USB devices laying about)
* http://thenextweb.com/insider/2011/0...take-the-bait/
And the even older, but somewhat related:
* https://www.schneier.com/blog/archiv...aid_attac.html
On the topic of a "howto make an example 'bad usb' device" for certain types of USB devices: emulated keyboard, or comment on bootable device
* http://null-byte.wonderhowto.com/how...d-usb-0165419/ (The two attacks mentioned here are not the limit of attacks possible with USB and other firmware in devices like USB that register with the OS. Pretending to be a keyboard and transmitting keystrokes is likely to be able to hit more diverse OS, than one that breaks driver loading in OS.)
And also peripherally related to this is "juice jacking" -- also over USB, and risk for data theft: (avoid with use of "USB condom" or similar functioning cable, but USB Condoms are not a "fix" for "Bad USB" as it prevents expected USB device function, so is a non-fix for bad-usb):
* http://www.wallofsheep.com/pages/juice
* http://krebsonsecurity.com/2011/08/b...juice-jacking/
MS Attempts to patch one example of exploit using badusb in one way: https://threatpost.com/microsoft-pat...ttacks/114240/ (.LNK vulnerability and multiple attempts to fix. https://technet.microsoft.com/library/security/ms15-085 https://technet.microsoft.com/library/security/ms10-046 )
One suggestion is a policy change on use of USB device: (Policies are hard to enforce and police. Consider rogue access points in office environments, and smartphones becoming hotspots. Additionally, executives often assume the rules dictated do not apply to them, and employees learn from example. If setting policies were effective, laws to make murder illegal would have stopped murders.)
* http://www.scmagazine.com/badusb-wha...rticle/388700/
The driver/firmware issues is not just limited to USB. It is also an issue with PCMCIA, PC cards, PC Express cards, CardBus cards, PCI cards, PICe, firewire, and maybe eSATA and more -- many of these high-speed data channels allow foreign devices to pass code for how to talk with it to the device's bus controller and running OS, and these end up running with privileged access, often system or kernel level. This problem is similar to trusting websites with their Java and/or JavaScript, running code on your own machine at a "user" level, but instead driver/firmware usually happens at the system/kernel level.
What have you done to mitigate these risks?
* Super-glue all your USB/eSATA,PC-card/* ports so devices can't be inserted/connected into them?
* Open the motherboard and disconnect all of these data channel connector cables from the motherboard?
* Disable from BIOS? Add Setup and Boot password to BIOS?
* Remove support for these pieces of hardware from your custom-built kernel?
* Nothing? It's nothing isn't it? I'm betting this is what most people have done.
Many modern computers no longer ship with exclusive keyboard/mouse ports like PS/2 interface, but rely on USB, so at least 2 USB ports will likely be open on most modern desktops.
Few people would make their own kernel these days, but even if they did, and their hardware requires USB for keyboard and/or mouse, there is still a problem unless it is meant to be run headless and without keyboard.
I have been thinking about this. in my day-to-day, I sometimes have need to copy things over "air gap" aka "sneaker net" to machines that are not on any network, and do not have support for wireless networks of any kind. However, they do have USB ports. But the question? Do I trust all of the people and all of the devices they inserted into this computer? Do I trust all the people they trust that have had physical access to this computer? It is like that old "sex ed" framing of sexual promiscuity and risk for STD as "when you have sex with a person, it is like having sex with all the people they had sex with, and the people they had sex with, on and on."
If it is possible to "pwn" (take over) a computer system's kernel/system with USB (or other) devices, and have your malicious code run with the privileges of the kernel, and then once the system is owned, overwrite firmware on other USB devices that are inserted, then it may be possible to spread an infection from one machine to multiple USB devices to multiple machines.
It is not as easy as this, however. Updating firmware of a device in such a way that the device continues to function without observable degraded performance is not easy, and with the large number of vendors, models, and variations of USB hardware, and target OS to infect plus their versions and variations including architecture, crafting malware that would recognize each model of USB device and device ID and only package and install altered firmware for the target device (assuming it has enough space for the malware and the functional code to keep the device working) could easily make the malware very large and not fit. Certainly, it is possible an infection could install a basic root-kit that then downloads from the Internet much more data, that creates problems with non-network machines being fully infected, and risk for detection with network monitoring and local file scanning.
Even with all of these complications, it is likely someone will find a way to simplify attacks, or select subsets of supported devices, and OS to make an attack spread quickly, and not be easily detected.
With all of the above in mind, what have you done to mitigate these risks?
One idea I've had is to use a simple USB thumb-drive that supports a single "Micro SD" card, and then allow that USB device to be inserted into any computers that are not mine, and then when I need the data stored on the Micro SD, I can remove the Micro SD from the USB device, and insert just the Micro SD into a full-sized SD adapter and then into my computer's SD slot -- treating it like an old-fashioned Floppy/Stiffie disk. If the little USB device becomes infected, I may spread an infection to other devices that use USB when connected, but so long as I don't connect it to my machine, my machine should be free from attack with that device. (If machine that is not mine has a SD port, then i can use that instead of a USB device that has been connected to many computers.) This does not prevent "badusb" and if it ever becomes wide-spread, the USB device with SD support may be used to spread a 'badusb" infection. All it does it try to protect my own computer(s).
This does not help against cases where "bad people" have physical access to my computer (Evil maid attack, or others), but it might help me with getting data to/from my computer with connecting non-trusted USB devices to it.
I suspect someone has done this for Linux:
Add support in the linux kernel to run your own custom USB (and other device) code, and intercept the device and vendor ID for each device, and then compare this plus other data to those devices that you trust, and if any non-trusted USB device is inserted, immediately halt the OS without caching anything to disk. This is dangerous even with FS that support true journaling filesystems. If this defense is known by an attacker, they can also probably buy the same vendor/device ID as one that you have and use that, but this would be a targetted attack, and most attacks are non-targetted, but instead are automated.
What are your thoughts to this problem of "BAD USB" and other devices? What actions have you taken? What thoughts do you have on defenses that could be created to mitigate attacks that might use this to deliver payloads?
Comment