(we took a break from our "standard fair" this weekend and didn't publish any standards related diaries. 20/21 will be skipped as a result)

Over the years, I collected quite a number of "standard" connectors/cables and interfaces. This is certainly an area where standards seem to be proliferating quickly. To stick with our theme of security and security awareness, I would like to focus on a couple of popular standards and particular outline security aspects of the standard.

First of all, pretty much all peripherals connected to a system require drivers to interact with the device. These device drivers frequently are part of the kernel and a vulnerability in the device driver will lead to a system compromise. I don't think the full potential of this class of vulnerabilities has been realized yet, but there have certainly been some notable exploits that were based on these vulnerabilities. Even simple devices like VGA monitors do send some data to the system, and could potentially be used to exploit vulnerabilities (I am not aware of a VGA vulnerability).

USB

 The "Universal Serial Bus" is by now pretty old and you can't buy a laptop or desktop without a USB port. In the past, the main risk of USB has been the ability to automatically launch software as the USB memory stick is plugged into the system. This vulnerability has been mostly eliminated in modern operating system configurations. However, there are still plenty of possibly issues with USB:

• USB is not just "USB Memory stick". A memory stick like device may also emulate a key board. For example the YubiKey is an interesting security application of a simulated keyboard. But this can also be abused. A USB keyboard may issue commands, just like a user sitting in front of the system. "Teensy" is a very capable USB development board that can be configured to emulate a keyboard [1]. A device based on Teensy could be added to any existing USB device via a simple USB hub. USB devices do not use any meaningful authentication to the host, so there is little that can be done to limit access to "good" USB devices.
• Some recent work points to possible file system driver vulnerabilities that can be exploited by mounting a specific file system. This would happen even if auto-execute is enabled. The system first needs to mount the file system to provide access to the user
• There have been plenty of social engineering based exploits showing that people will click on files on USB sticks just about as likely as they open attachments in e-mail.

Firewire (IEEE 1394)

  A lot of attention has been spent on USB. Firewire on the other hand provides for an entire different level of access to the system. Firewire extends the PCI bus, and allows access to the system in ways similar to PCI plugin boards. An attacker with access to the Firewire bus can read and manipulate memory and access devices (like hard drives) connected to the bus.

• Reading memory: This has been used in forensics to retrieve system memory without having to install additional tools. Of course, an attacker would be able to retrieve encryption keys and the like that are stored in memory.
• Manipulating memory: Tools exist to "patch" system processes in memory . For example, a proof of concept tool allows bypassing the Windows XP login dialog by patching the password comparison function in memory.
• Low level system access: Even low level elements, like BIOS passwords, have been read via firewire.

(sorry for the lack of links/URLs for this section. but the main source of these tools, http://www.storm.net.nz/projects/16 , hasn't been up in a while)

Thunderbolt (Light Peak)

  This is a relatively new technology, initially introduced by Apple and Intel. Currently, first non-Apple laptops start to appear with Thunderbold port. Thunderbolt is pretty much a further development of the firewire concept. It does allow direct access to the newer PCIe bus, and includes a video bus via display port.  At this point, not a lot of work has been done exploiting Thunderbolt. But more or less all exploits that worked against Firewire should in principle work with Thunderbolt. The bus is not authenticated and a device like a monitor may disguise an internal second devices that will then read and manipulate data on the system via the thunderbolt interface. There is very little visibility into the data exchanged via thunderbolt (we need something like tcpdump for these ports). 

[1] http://www.pjrc.com/teensy/

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter