USB Attack Surface on Embedded Devices
A USB port looks like a charger and behaves like a network interface. The moment something is plugged in, the firmware parses descriptors and exposes interfaces, all before any authentication. On embedded devices that often includes a debug gadget someone forgot to disable. Here is how to map the USB attack surface.
Why USB Is Pre-Auth Surface
USB enumeration happens before anything else. The host and device exchange descriptors, load drivers, and bring up interfaces with no opportunity for authentication in between. That makes every line of descriptor-parsing and gadget code reachable by anyone who can plug in, the same threat profile as an open network port.
Step 1: Enumerate the Interfaces
See what the device exposes over USB. The descriptors list every interface, and a debug or storage gadget is an immediate lead:
lsusb lsusb -v -d 1d6b:0104 | grep -E 'bInterfaceClass|iInterface'
Bus 001 Device 005: ID 18d1:4ee7 Device ADB Interface bInterfaceClass 8 Mass Storage bInterfaceClass255 Vendor Specific (ADB)
A mass-storage interface and a vendor ADB debug interface exposed over USB are both footholds. ADB in particular is often a direct shell.
Step 2: Fuzz the Parser
Beyond exposed gadgets, the descriptor parser itself is a target. Malformed descriptors and unexpected interface combinations are classic fuzzing input, and a crash here is a memory bug reachable by anyone with physical access to the port.
Three USB Risks
The exposures a USB port introduces:
Hardening the Port
Disable debug gadgets such as ADB in production, expose only the interfaces the product actually needs, validate descriptors and host requests defensively, and where the use case allows, restrict the port to charging only. Treat USB input with the same suspicion as network input, because it arrives with the same lack of authentication.
Where This Fits
Mapping the USB attack surface and testing the gadget and parser is part of a hardware penetration test. That work is the kind of work we do at Berkner Tech.