Re.: BadUSB - On Accessories that Turn Evil, by Karsten Nohl + Jakob Lell

[WhiteWinterWolf (Simon)]

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
>