-1

This is sort of like working in a lab with toxic chemicals. There is a way to work and wear certain special clothes so you don't get contaminated. Likewise, I wonder if when dealing with malware you can still use the source/infected machines for their functionality, even though they are infected, and still not get infected on the target device when connecting via USB.

I'm wondering because I don't yet know how to think about the directional flow of code in terms of what device can install something on what other devices it can connect to. I'm not sure what pieces there are to take into account. So it seems that if you knew that A would infect anything it's plugged into, but that B wouldn't let any traffic out except a specific acceptable kind, then you could plug A into B, B would get infected but still allow connection to C without C getting infected. That sort of thing.

Lance
  • 622
  • 7
  • 16

1 Answers1

-2

USB is inherently insecure, as generally speaking devices automatically trust a USB device that is physically plugged in to them. Add to this the fact that many USB devices have the ability to automatically install code from a hidden partition, something originally intended to make the installation of dirvers for the USB device simple and automatic. Because of these two factors, anywhere that has a large number of random USB devices in frequent use is often rife with USB-borne viruses (think University Libraries and similar).

The only 100% safe way to use a USB device is with one of those "USB condoms", a small dongle that prevents any data transfer, allowing only charging. Of course this makes them into charging ports rather than data transfer ports.

Emily G
  • 1
  • 3
  • USBs do not have the ability to automatically install unauthorized code. – forest Jan 03 '19 at 02:22
  • Sadly you're not entirely correct. There were over 40 unpatched USB security flaws in Linux alone last year: https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs_usb.md and several involve running unauthorized code. Don't worry, you need the USB device to be physically attached for them to work....oh wait!

    https://www.theregister.co.uk/2017/11/07/linux_usb_security_bugs/

     – Emily G Jan 03 '19 at 02:33
  • 1
    Those are driver bugs and are unrelated to the USB protocol or USB devices (with the exception of one, which is a slab-out-of-bounds). Those bugs would exist even if a different interface were used (e.g. if the driver was ported to RS-232 or something). Regardless, citing kernel bugs as an "ability that USB devices have to install code" is incorrect. It would be better to say that USB drivers and class drives may have bugs that could be exploited by malicious USB devices. As such, you cannot call USB "inherently insecure". – forest Jan 03 '19 at 02:40
  • So what you're saying is that no-one can break the windows of my house with a brick because they could also brick the skylight?

    TBH it sounds more like the OP just needs to learn how to sandbox properly and set up VMs. Set this up and use it correctly, and USB malware isn't any more likely to escape than any other malware.

    I'm still sticking with my original statement though - USB is inherently insecure: https://kumarde.com/papers/plug_and_pray.pdf

     – Emily G Jan 03 '19 at 03:22
  • 1
    Inherently insecure implies that the specifications, not the implication, allows for malicious functionality. The reality is that implementations may be insecure, but the specification most certainly is not. – forest Jan 03 '19 at 03:28
  • Did you even read the link in my last comment? https://kumarde.com/papers/plug_and_pray.pdf in case you misssed it. The specification is very much part of the problem, unless you include things like "plugging things in" and "turning things on" under the "implimnetation" umbrella... – Emily G Jan 03 '19 at 03:36
  • 2
    Yes I have. While the specification absolutely makes it easier to perform malicious actions, it does not have the ability to automatically install code. Yes, it can be abused (on systems with PnP) to act as a HID device automatically. Yes, the confidentiality is poor as it is half-duplex broadcast bus (for 2.0 and older). Yes, it is easy to social engineer people. But that does not mean that it is capable of executing arbitrary code, short of exploiting an implementation (and not specification) weakness. And in terms of the hub and hardware itself, the protocol is actually really secure. – forest Jan 03 '19 at 03:44
  • 2
    I actually wrote about this in another answer, where I describe the four primary types of attacks that a malicious USB device can perform. None of them allow for arbitrary code execution without exploiting an insecure driver or other implementation problem. – forest Jan 03 '19 at 03:48
  • 1
    @EmilyGray-Fow "USB is inherently insecure" -- you haven't provided any support for this statement. Can you connect some dots? Or explain your logic? – schroeder Jan 03 '19 at 08:20
  • The HID exploit is more of a vendor specific vulnerability, Phison 2251-03 (2303) to be exact. https://github.com/brandonlw/Psychson

    USB's with that specific chip are nearly impossible to find now aside from buying one through here: https://shop.hak5.org/products/usb-rubber-ducky-deluxe

     – they Jan 03 '19 at 13:51