A lot of devices use USB, even in the automotive world. Often it is possible to do more things on the USB port than it should be. Imagine a scenario where you are driving your car. Maybe you want to connect your smartphone to get it charged and to listen to your music. But you would not want or expect your smartphone (or an app) to send commands to your car by behaving like a keyboard. I mean who hooks up a keyboard to the car?

What is USB?

You’re probably familiar with USB as the connector you always plug in the wrong way around into your computer – but it is so much more than that.

A USB connection always needs a client and a host. The host (usually your computer) is managing the connection and tells the client (Mass Storage, Headset etc.)  if and when it has to send data. Therefore, the host needs to know which device it is talking to. It asks the client which kind of device class it belongs and how it wants to be treated. Due to the fact that USB is packet-based, the host also has to ask the client which maximal packet size it can handle.

There are a lot of different USB classes for a client:

• Audio
• Human Interface Device
• Mass Storage
• Printer
• Image
• Hub

But that’s not enough. USB does not only have different device classes – a USB device also has different interfaces and endpoints. An interface represents a functional unit belonging to a particular class. An endpoint is a source or sink of data at the device. The endpoint 0 is always the control endpoint, where the configuration between the host and the client is done. And there is a lot to be configured for each device, like the class of the device, the number of interfaces, the maximal packet size, the Vendor ID and Product ID, the power consumption and so on.

USB also uses a number of different transfer types. A transfer type determines the frequency and length of the transaction used to communicate with the endpoint.

• Interrupt Transfers: short packets with checksum, fixed periodic intervals. (Mice, Keyboards, …)
• Isochronous Transfer: packets without checksum, fixed periods. (Audio/Video Streaming, Serial Port Emulation, …)
• Bulk Transfer: large packets with checksum, non-periodic. (Mass Storage, Printers, …)
• Control Transfer:  packets with checksum, non-periodic. (Control commands)

Okay, I get it, there are a lot of different combinations and possibilities to handle a USB client device.

What ESCRYPT is doing

We are doing several tests for you to improve the security of your USB connection.

Boot from USB

We can verify if boot from USB is supported at the target.

CD-Autorun

We test if the autorun on the device is enabled and if code is executed automatically.

Class Scan

We scan the supported classes with our internal script by emulation of different USB devices with different classes and verifying the output from the host.

Ethernet over USB

We can sniff the communication over USB.

Firmware Update

We check if it is possible to manipulate the firmware while the update process happens.

Fuzzing

We fuzz the USB host by emulating different USB classes and changing some parameters in the configuration phase.

ID Scan

Due to the fact that some ID’s could be blocked at the target, we emulate different USB clients with different VID’s and PID’s.

Keyboard Test

We try to insert several keystrokes and commands such as kernel commands. We utilize these keystrokes to confirm whether or not we can reboot the target.

Man-in-the-middle

We can change data on the fly between host and client by using a pre-programmed filter or by validating every outgoing message manually.

OS Identification

We can identify the OS which is running at the target by using USB fingerprints.

Sniffing

We can sniff the communication between Host and Client.

If you are interested in USB testing or security testing in general, feel free to contact us or comment below.

All the best,

Jessica Zimpel