Fear and Loathing on your Desk: BadUSB, and what you should do about it
Presented at Kiwicon 9, 10-11 December 2015, Wellington New Zealand.
For over 15 years USB has been the universal computing peripheral interface. In simpler times the host computer and the USB device trusted each other, and so USB implementations historically placed little emphasis on security issues. But what if malicious firmware were loaded into a USB device? How can you protect yourself from BadUSB?
This talk will review public implementations of BadUSB, and (the distinct lack of) available defensive techniques. A hardware gadget will then be presented to make most of your problems...disappear.
Top Rated Pune Call Girls Katraj ⟟ 6297143586 ⟟ Call Me For Genuine Sex Serv...
BadUSB, and what you should do about it
1. Fear & Loathing on your Desk
BadUSB, and what you should do about it
Robert Fisk
2. Outline
1. Why USB = Universal Serial Badness
2. Current defenses
3. Hardware defense gadget
– Demo, Preemptive FAQs
3. So who is this guy?
● Electronic engineer in Auckland, NZ
● PhD in IC design – analog, mixed-signal, low power
● Informal tech support for group of targeted users
● Bored last year, BadUSB looked like an interesting project
5. USB descriptors
Bus 007 Device 003: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse
Device Descriptor:
blength 18
bdescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
...blah blah...
Untrusted length!!
[you@yourbox ~]$ lsusb -v
6. Universal Serial Badness #1
Type 1: Stack Attacks
● Untrusted input to host stack
● Host driver or device driver of attacker's choice
● 200 device drivers in Linux 3.13 kernel source
Host PC User space
USB host driver
USB class
driver
USB device
driver
USB device
driver
POW!POW!
7. Universal Serial Badness #1
Stack Attack example:
● Inadvertent Win7 attack from crappy mouse
● Bluescreen in HIDCLASS.SYS
8. Universal Serial Badness #1
News Flash:
Cisco Nexus 5000 Series USB Driver Denial of Service Vulnerability
A vulnerability in the USB driver for Cisco Nexus 5000 Series Switches
could allow an unauthenticated, local attacker to cause a denial of
service (DoS) condition due to a kernel crash.
The vulnerability is due to insufficient handling of USB input parameters.
Cisco has not released software updates that address this vulnerability.
There are no workarounds that mitigate this vulnerability.
“
9. Universal Serial Badness #2
Type 2: Hidden Functionality Attacks
● No exploit required
● USB-compliant commands
User space
USB host driver
USB class
driver
USB device
driver
USB device
driver
POW!POW!Host PC
10. Universal Serial Badness #2
Hidden Functionality example:
Netragard's Hacker Interface Device
Usage: Plug mouse into computer, get pwned.
Mouse
Hub
+
HID USB Keystroke Dongle (Teensy)
USB flash drive
+
+
11. Universal Serial Badness #3
Type 3: Intended Functionality Attacks
● No exploit required
● The thing you want is bad!
User space
USB host driver
USB class
driver
USB device
driver
USB device
driver
POW!POW!
Host PC
12. Universal Serial Badness #3
Intended Functionality example:
SR Labs 'hidden
rootkit' flash drive
● Host profiling
● Activate payload only
when enumerated by
BIOS
13. Universal Serial Badness
● Type 1: Stack attacks
● Type 2: Hidden functionality
● Type 3: Intended functionality
100%
standards
compliant
Problem?
14. How easily can a device turn Bad?
● Most USB chips use 8051 8-bit embedded CPU (from 1980!!!)
● Firmware updates with proprietary tools
srlabs.de
“Up to half of USB chips are BadUSB-vulnerable”
(but you can't tell which half!)
You have no idea what code you are running on your system!
15. Current defense #1
● For mice on desktop PCs only
● Not all USB mice support PS/2 protocol :(
Reduce your attack surface with advanced PS/2 technology!
NOT VERY USEFUL
NOT VERY USEFUL
16. Current defense #2
● Only protects against type 2 keyboard attacks
● Windows only
G Data Keyboard GuardNOT VERY USEFUL
NOT VERY USEFUL
17. Current defense #3
Reduce your attack surface with virtualisation
(the wrong way)
● Software passthrough of USB devices
● Type 2 hypervisors: Virtualbox, etc
● Software passthrough increases your
attack surface!
USB device
USB host
Host OS
Hypervisor
Guest OS
BAM!BAM!
BAM!BAM!
BAM!BAM!
NOT VERY USEFUL
NOT VERY USEFUL
18. Current defense #3
Reduce your attack surface with virtualisation
(the right way)
● Hardware passthrough of USB host
controller
● Type 1 hypervisors: Qubes/Xen, etc
● Requires VT-d (Intel) or IOMMU (AMD)
● All USB devices attched to a host
controller move together
USB device
USB host
Host OS
Hypervisor
Guest OS
USB host
BAM!BAM!
USEFUL?
USEFUL?
19. Virtualisation scorecard
● Type 1: Stack attacks – Isolated
● Type 2: Hidden functionality – Isolated
● Type 3: Intended functionality – Isolated
How does hardware virtualisation help us?
Sanitise data leaving the USB VM!
● No protection at boot time
● Host OS inputs are unprotected:
USB kbd/mouse & other devices on the same host controller
20. For everything else, there's...
● Concept: reduce attack surface through isolation
● Terminate the USB bus outside vulnerable PC
Windows, Mac, Linux: Uhhh...........
USB host
driver
USB device
driver
USB device
USB device
emulator
USB device
driver
BAM!BAM!
Simplest imaginable protocol
BAM!BAM!
Sanity
checks
Host PC
21. Hardware defense – concept
● Many device drivers
● Slow bootup
● More expensive
Start the project with off-the-shelf hardware
● Limited drivers
● Instant bootup
● Cheap(er)
Embedded Linux: Embedded bare-metal:
Thing 1 Thing 2
USB
device
Simple interface Host
port
Device
port
Upstream
(device)
Downstream
(host)
Host PC
23. Introducing the USG v0.9
Turning BadUSB good since 2015
Device
port
Host
portSPI data
interface
24. Let's talk firmware!
main.c
Dev board
Peripheral library
(hardware drivers)
USB host library &
device drivers
Linker script.ld Processor family
headers.h
OpenOCD Olimex JTAG
☼
Board.cfg
GNU
ARM Eclipse
Eclipse CDT
☼ ☼
Startup file.SMath/DSP
libraries
newlib-nano
gdb
☼
☼
gcc-
arm-none-eabi
25. Firmware current status
● Mass Storage support only
– SCSI transparent command set
– 512B blocks
– 2TB max capacity
– Single LUN
● ~700kB/s transfer speed
● 2x 30kB binary images
26. Hardware isolation scorecard #1
● Type 1: Stack attacks – Isolated
● Type 2: Hidden functionality
● Type 3: Intended functionality
How does this dongle help us?
27. Hidden functionality defense
● Disable hubs
– Embedded host stack supports single device only :)
● Disable multi-interface devices
– Limit host to one active class driver
● Lock in requested device class on first enumeration
– Device class change requires firmware reset
Stop Type 2 attacks with firmware features:
28. Intended functionality defense
● Mass Storage
– Hardware AES keyed from device serial number
– Bad firmware cannot maliciously alter blocks
– Only partial protection
● HID
– Rate-limit input actions
– Only partial protection
– Bonus points: buffer keystrokes > user profiling
Type 3 attacks difficult to block!
None of this is currently implemented!
29. Hardware isolation scorecard #2
● Type 1: Stack attacks – Isolated
● Type 2: Hidden functionality – Firmware blocked
● Type 3: Intended functionality – Partial protection (eventually!)
Firmware features give more protection
● Some type 3 attacks cannot be hardware sanitised.
Proceed with caution!
32. Preemptive FAQ #1
Q: Can I use my USB hub with the USG?
A: No!
– No embedded host support (downstream)
– Upstream cannot emulate a network of devices
– Also, necessary to block type 2 attacks
33. Preemptive FAQ #1b
Q: Wait, that means I need a USG for every one of my USB
devices??!!!!!
A: Yeah, sorry about that ;)
Also, this implies hubs cannot be sanitised.
Hubs are untrusted devices too!
34. Preemptive FAQ #2
Q: Can the USG protect the firmware on my device from
malicious hosts?
A: Yes. The isolation barrier is symmetric.
35. Preemptive FAQ #3
Q: Will the USG support [my obscure device]?
A: Probably not.
– Requires device driver and device emulator
– Requires some assurance that the data is safe (type 3 attacks)
– Requires sufficient interest (or pull requests!)
Planned:
– HID keyboard, mouse
– CDC, serial
– For everything else, there's Qubes ( )Or other type 1 hypervisor with hardware-
assisted virtualisation of USB host controllers
36. Preemptive FAQ #4
Q: Does it have a red flashing light to tell me when a USB is Bad?
A: No
– False negatives from host profiling
– False positives from crap devices or internal bugs
– Fault LEDs are deliberately orange
– Always use your USG!
37. Preemptive FAQ #5
Q: This thing works at USB1 speed? What is this, 1998 or something?
A:
39. 480Mbps
● Limited embedded hardware support
● 4 layer PCB, controlled impedance routing
● Soldering level: mortals need not apply (0.5mm pitch QFN)
● Prototype cost: $300
40. 5Gbps
● No embedded hardware support
● 8 layer PCB, RF grade layout where every mm counts
● Soldering level: impossible (BGA)
● Prototype cost: $1000
41. Preemptive FAQ #6
Q: So do I need a USG?
A: Windows, Mac, Linux:
Yes, but you are probably still vulnerable! (type 3 attacks)
Type 1 hypervisor with hardware-assisted virtualisation of
USB host controllers:
Yes, for your HIDs and anything connected at boot-time
Embedded devices, eg Cisco switches :)
Yes! (and pray the firmware image is signed)
42. Preemptive FAQ #7
Q: When can I buy one?
A: Sometime in 2016
– Firmware: add HID class support
– Hardware: 1+ board revisions
DFM is boring and expensive
– Build your own USG v0.9 anytime you want!