Hi Julian,

You don't need microscopic chips or highly engineered devices to implement a working BadUSB attack.

Nothing looks more as a Dell mouse than another Dell mouse, and a malicious mouse offers plenty of space to store all the chips you may want. USB sticks are also still widely found (they have all required processing and memory by default) either as promotional devices, to share documents or "lost" somewhere.

Moreover, a lot of legitimate USB devices can be reprogrammed through USB. That's why, for instance, if you use a air-gapped computer you should use SD-Card instead of USB sticks to transfer data as a malware on your networked computer may "enhance" your USB stick with BadUSB features which would contaminate the air-gapped computer and establish a covert channel, exfiltrating data (in particular encryption keys and passwords).

> Keyboard is the long identified danger, but maybe there are other dev types to protect against too

This is not a "maybe". There was a practical demonstration for instance in a DefCon conference dedicated to BadUSB of a USB stick reprogrammed to act as a fake network device. The malicious device would very quickly:
- Declare itself as a networking device.
- Simulate a DHCP server on the fake network providing the address of a malicious DNS server.
- Drop networking device features.
- The new DNS server configuration remains kept by the host.
As a result, this USB stick allows to change the DNS server of a host, opening the gate notably to man-in-the-middle attacks (and the whole process was quite unnoticeable, no black console window popping-up, AFAIR there was just a change in the network icon shape in the notification bar for a fraction of second...).

*

Regarding the solution you propose, I don't know how it would cope in the following situations:

- Legitimate devices which dynamically change their USB configuration (their device type). Such change is not a malicious trick but is an integral part on how USB is designed and work.

Example of devices legitimately changing their USB configuration on-the-fly include mobile devices which by default only use USB as a power-source and switch into something else when the user interactively selects an option in a device's menu.

Another example is devices which upon connection first act as a mass storage device storing drivers installation files, and when the drivers are already installed on the system the driver "pings" the device which as a result drops mass storage capabilities and turns itself into its actual type. Some consumer-grade modems for instance were known to offer such feature to allow an easy installation of the driver.

- I don't know how this suggestion handles USB hubs, either legitimate USB hubs or faked ones simulated by malicious BadUSB devices to get around USB configuration change restrictions (actually, my guess is that simulating a USB hub may effectively bypass the suggested security feature).

*

USB devices are identified by a class code (=the kind of device) and a manufacturer ID.

The most promising counter-measure I've encountered so far against the BadUSB attack is a firewall-like system allowing to set the class codes expected on each physical USB port.

This allows for instance to set the ports where you expect human interface devices (keyboard, mouse, etc.) to be connected, the ports where mass storage devices (and nothing else) are expected, and optionally a port where no device is accepted (you would use this port only as power source).

I don't know how USB is implemented in FreeBSD, but such functionality might be implementable by intercepting the notifications of new USB devices configuration and rejecting configurations where the device class and USB port information do not match the rules.

Regards,
Simon.


Le 20/09/2017 à 20:06, Julian H. Stacey a écrit :
Hi usb@ & security@ freebsd.org,
hps@ (cc'd) introduced a FreeBSD Sysctl Oct 2014:
        hw.usb.disable_enumeration: 0
        dev.uhub.4.disable_enumeration: 0
        dev.uhub.3.disable_enumeration: 0
        dev.uhub.2.disable_enumeration: 0
        dev.uhub.1.disable_enumeration: 0
        dev.uhub.0.disable_enumeration: 0
which added some protection against USB devices that turn evil.
   https://lists.freebsd.org/pipermail/freebsd-usb/2014-October/013304.html
   https://lists.freebsd.org/pipermail/freebsd-security/2014-October/007976.html

A tiny diff to make it easier to grep sysctl descriptions:
        
http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/sys/dev/usb/usb_hub.c.REL=12.0-CURRENT.diff

Chips shrink, imagine one hidden in a small arm band Micro-USB
adapter cable, as sold in one Euro/Pound shops.  A picture of similar
https://www.twist4-silikonarmbaender.de/
Probably some are made in China, perhaps in PLA owned factories.

Short cables, so to save losing it, it might be left plugged in.
At power on, a chip might do nothing but set a timer, & stay
in low power for 130 minutes, out waiting checkers before it starts
"Hi, I'm a keyboard + C:\n uname -a\n probes & commands"

(Combi scanner / printers & PS2 keyboard + mouse converters both
share 2 devices on 1 cable, so a 2nd dev on a physical interface
isn't intrinsicaly suspicious.)

To detect a Trojan cable, could one measure very low  power consumption of a
supposedly passive cable not yet connected the other end to a device ?
My laptop + FreeBSD-current suggest low current detection is not possible ?

        usbconfig shows all currents in multiples of 100mA (0mA)
        (0mA) (0mA) (0mA) (100mA) (100mA) (100mA) (200mA) (500mA)

        So probably not measurements made by the PC, but nominal ratings ?
        & if it's merely the external device reporting its desired
        rating, then useless to detect if a cable has a hidden device.

        I'm not familiar with USB chip functionalities available,
        but I looked at the code:

        /usr/src/usr.sbin/usbconfig/dump.c
        dump_device_info{
        usage = libusb20_dev_get_power_usage(pdev);
        printf("%s, cfg=%u md=%s spd=%s pwr=%s (%umA)\n", ... usage);

        man libusb20_dev_get_power_usage
        libusb20_dev_get_power_usage() returns the reported power usage in
        milliamps for the given USB device.  A power usage of zero typically
        means that the device is self powered.

        /usr/src/lib/libusb/libusb20.c
        pdev->methods->get_power_usage(pdev, &power_usage);

        ugen20_get_power_usage

        ioctl(pdev->file_ctrl, IOUSB(USB_GET_POWER_USAGE)

        /sys/dev/usb/usb_generic.c: case USB_GET_POWER_USAGE:
        ugen_get_power_usage(f);

        /sys/dev/usb/usb_generic.c
        return (udev->power)

I suppose in desperation a dentist's X-Ray machine would give a view.

It'd be worse if an organisation buried evil chips in Power Banks
(batteries to recharge smart phones etc).  It would be impossible
to detect low power consumed by a sleeping chip, that continues to
sleep long after a phone is plugged in to charge.
Smaller battery packs are around company promotional gift prices.

I recall the current FreeBSD sysctl provides switching per port,
but not per device type.  I guess one could bodge a bit more security
by a script, approx:

        cp /etc/devd.conf.no_kbd /etc/devd.conf
        kill -9 `cat /var/run.devd.pid`
        /sbin/devd
        sysctl hw.usb.disable_enumeration=0     # Defences open.
        .... more specific port settings ?
        echo "Now Insert within 10 sec." ; sleep 10
        sysctl hw.usb.disable_enumeration=1     
        cp /etc/devd.conf.with_kbd /etc/devd.conf
        kill -9 `cat /var/run.devd.pid`
        /sbin/devd

Keyboard is the long identified danger, but maybe there are
other dev types to protect against too, (ls /usr/share/man/man4),
Some devices such as 'da' I don't see as a problem, as for /dev/da
one can select on /etc/devd/*.conf "sernum" mount -o nosuid .. etc.

Ideally the USB system might offer more fine tuned defence, to have
some better defence than above, but as that's minority interest,
security companies might need to contribute to development of that.

Cheers,
Julian

_______________________________________________
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to