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-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
