skip to content

AutoRun is disabled fleet-wide — how does a dropped USB device still run commands?

level: middleimportance: must knowfreq 62%

answer

  1. the host asks the device what it is
  2. class 0x03, not class 0x08
  3. AutoRun is a mass-storage behaviour
  4. it types as the logged-in user
  5. one device, two interfaces

basics

~10 s

AutoRun only governs how the OS handles removable storage. A device can declare itself a keyboard instead; the OS binds a keyboard driver automatically and accepts its keystrokes. No media, no setting, no prompt.

solid answer

~40 s

When a USB device is plugged in, the host asks it what it is, and the device answers with descriptors. An interface declaring class `0x03` is a human interface device; subclass `0x01` with protocol `0x01` is a boot keyboard. Windows and Linux bind an in-box keyboard driver for that automatically and without prompting, because a machine with no working keyboard has to be fixable. From then on the device emits key reports indistinguishable from typing, executing as whoever is logged in with that account's rights. AutoRun and AutoPlay govern mass storage, class `0x08`, so disabling them changes nothing here. A device can also be composite, presenting storage and a keyboard at once. The control class is device-installation policy permitting only approved classes or specific vendor and product identifiers.

code

text · 10 lines
text
Configuration Descriptor:
  bNumInterfaces      2
  Interface 0:
    bInterfaceClass     0x08   (Mass Storage)      <- the flash drive the finder expected
    ...
  Interface 1:
    bInterfaceClass     0x03   (Human Interface Device)
    bInterfaceSubClass  0x01   (Boot Interface)
    bInterfaceProtocol  0x01   (Keyboard)          <- in-box driver bound, no prompt
    ...

go deeper

for a junior

Know that plugging in an unknown USB device is dangerous even with AutoRun off, and that a device can present itself as a keyboard. Be able to say the two preconditions out loud: an open port and a person who plugs it in.

for a middle

Explain enumeration: the host reads descriptors, an interface class of 0x03 with keyboard subclass and protocol gets an in-box driver bound with no prompt, and mass storage is a separate class that AutoRun governs.

for a senior

Demonstrate that you can reason about what the device inherits — the logged-in session's rights, nothing more — and pick device-installation policy over media scanning or awareness training as the class that removes the precondition.

for a principal

Own the estate-wide call: class allow-listing breaks legitimate peripherals and generates exception traffic, so decide where it applies, who approves exceptions, and which machine populations get ports physically closed instead.

## The precondition this technique cannot substitute A dropped device needs two things: a port and a person willing to plug it in. Neither is a configuration item, and that is why the technique survives estates that believe they closed it. ## What actually happens on insertion USB is a self-describing bus. On insertion the host performs *enumeration*: it powers the device, assigns it an address, and reads its descriptors. The device descriptor identifies the vendor and product; the configuration descriptor lists one or more **interfaces**, and each interface carries a class code that tells the host what kind of thing it is talking to. Two class codes matter for this question: - `0x08` — **Mass Storage**. The host mounts a filesystem, and *this* is the path that AutoRun and AutoPlay govern. Turning them off means the OS will not act on an autorun instruction file or offer to open the media. - `0x03` — **Human Interface Device**. With `bInterfaceSubClass 0x01` (boot interface) and `bInterfaceProtocol 0x01` (keyboard), the host binds its in-box keyboard driver. The crucial property is that the host **takes the device's word for it**. A device declaring itself a keyboard is a keyboard, because there is no other way to be one. No signed driver has to be located, no prompt appears, and no policy is consulted by default — the boot keyboard class exists precisely so that a machine sitting at a firmware screen with nothing attached can be recovered by plugging something in. ## What the device can then do It types. Key reports arrive through the same path as a physical keyboard, so at the OS level there is no distinction to make. Three consequences follow, and they are the ones interviewers probe: - **It inherits the session's rights, and has none of its own.** Against a locked screen it can do nothing but guess a password. Against an unlocked session it can do everything that user can do, including opening a prompt for elevation that the user may well approve, since they are standing there and something is clearly happening. - **Speed is the only tell.** It can type faster than a human, in a fixed rhythm, and it does not correct mistakes. Operators throttle it and add delays for exactly this reason. - **No vulnerability is being exploited.** There is nothing to patch. Every part of the chain is behaving as specified — which is why the answer to *we are fully patched, are we safe from this* is no. ## The composite trick A single device can expose several interfaces. A composite device declaring both `0x08` and `0x03` looks and behaves like the plain flash drive somebody found in a car park, files visible and openable, while its second interface types. This also disposes of the common half-measure: blocking removable **storage** leaves the keyboard interface untouched, and since the payload is keystrokes rather than a file, nothing needs to be read from the device at all. ## The other class worth knowing The same self-description trick generalises. A device can declare itself a network interface, at which point the host may accept configuration from it in preference to the network it is already on, because a freshly attached wired interface tends to win. The lesson is not the specific class but the invariant: **the class a device declares is a claim, and the host has no way to check it.** ## What removes it Only one control class touches the precondition: **device-installation policy at the OS**, allow-listing device classes, or specific vendor and product identifiers, and refusing everything else. Applied properly it means an unexpected keyboard interface never gets a driver bound. Below that sit the physical measures — filling or disabling ports on machines that never need them, which is realistic for kiosks, shop-floor terminals and shared reception machines, and unrealistic for laptops. Everything else on the usual list is a distraction here. Disabling AutoRun addresses class `0x08`. Antivirus scanning of removable media addresses files. A policy telling staff not to plug in found devices reduces the rate and never reaches zero, because the device is often found somewhere it plausibly belongs — a meeting room, a printer tray, a desk drawer — rather than in a car park. ## Answering it well Say the mechanism, not the mythology: the host asks the device what it is, the device says keyboard, and that answer is unverifiable. Then place AutoRun where it belongs — a mass-storage behaviour — and name device-installation policy as the class that actually removes the path.

  • Does a keystroke-injecting device need administrative rights?
    It has no rights of its own. It types into whatever session is unlocked and inherits that account's privileges, so against a standard user it is limited to what that user can do — though a person watching something happen on their own screen will often approve an elevation prompt. Against a locked machine it can only guess a password. The interesting preconditions are a port and an unlocked session, not a patch level.
  • Why does blocking removable storage not close this?
    Because the payload is keystrokes, not a file. Blocking mass storage stops the filesystem being mounted and leaves the keyboard interface bound and typing. Anything the operator needs can be typed rather than read off the device, so the storage interface is a disguise rather than a dependency.
  • Which control class actually removes it?
    Device-installation policy at the operating system that allows only approved device classes or specific vendor and product identifiers and refuses the rest, so an unexpected keyboard interface never gets a driver bound. Physically closing ports helps on fixed-function machines. Both attack the precondition; awareness reduces the rate but never to zero.

The port never asks what is on the drive; it asks the device what kind of thing it is and believes the answer. Declaring yourself a keyboard is a claim nothing on the bus can check.

saying these in an interview costs you the question

  • Says a disabled AutoRun setting means dropped USB devices fail
  • Thinks the device must be mounted before it can do anything
  • Assumes the OS prompts the user before binding a keyboard driver
  • Believes patching removes it, when no vulnerability is exploited
  • Claims blocking removable storage closes the path

context

resolving links…