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 t
