In a similar manner to a usb rubber ducky, can one use an SD card to emulate an HID device (such as a mouse or keyboard)? If so, how could this be implemented, and how can it be protected against?
2 Answers
No. An SD card does not interact over a bus that can support HID devices.
SD cards operate with two interfaces: a low speed Serial Peripheral Interface (SPI), and a high speed SD interface.
The low speed SPI interface is a general-purpose protocol for talking to electronic devices, but in the context of an SD card the only thing it can talk to is an SD card interface IC - the SPI bus doesn't go directly to the CPU or PCH. SPI is used for talking to things like temperature sensors and power management ICs on circuit boards. It's general purpose in that it's a simple physical and logical specification for talking to devices, but it's not general purpose in the same way that something like USB is. You have to specifically know what device you're talking to in order to make it work, so you can't really just put something unexpected on the bus and turn it into a HID device.
The high speed SD interface is a specific protocol for SD cards. It is specifically designed to talk to SD cards and access data on them. It isn't general purpose and it cannot support HID devices.
An SD card reader that plugged in via USB could operate as a HID device, but the reader itself would have to be malicious rather than the card.
answered Nov 19, 2021 at 1:43
-
1Interestingly, choosing a USB to SD chip at random, the USB2228 ww1.microchip.com/downloads/en/DeviceDoc/00002256A.pdf actually has a programmable microcontroller and memory built-in. One could imagine a (admittedly far-fetched) vulnerability in the controller chip that would allow a nefarious SD card to reprogram it. ww1.microchip.com/downloads/en/Appnotes/en562801.pdf– 0xDBFB7Nov 19, 2021 at 16:29
-
3Indeed, it may technically be possible for a maliciously crafted SD card (custom hardware) to target a vulnerability in the firmware of the SD controller and gain code execution on it, and then re-register itself as a USB HID or other device. In the case of the IC you linked, though, it looks like it'd be quite a complex task to pull off. The 8051 does have access to the XDATA & SFR, which appears to be mapped into USB endpoint TX/RX registers, so the MCU can send arbitrary descriptors. But the device would have to have an external program EEPROM attached and
ROMENasserted. Nov 19, 2021 at 17:37 -
3The largest exploitation barrier would be that the 8051 is a Harvard architecture processor, meaning that instruction and data buses are separate and you cannot execute data. That means you're pretty much stuck with ROP chains. On top of that, the SD hardware goes through a hardware FMC and the only window into the 8051's execution state you have from there is through EPnTX/EPnRX buffers mapped in the SFR - the bus latch phases make it physically impossible for the FMC to talk to the 8051 directly. Doable, but a lot of work for a very specific targeted attack. Nov 19, 2021 at 17:49
-
neat, looks like you have a lot of experience with this! Sorry for the uninformed comment :P– 0xDBFB7Nov 19, 2021 at 20:02
-
1Not uninformed at all - you were indeed correct that it's a possible attack vector, and that is a relevant point! Nov 19, 2021 at 20:13
In a similar manner to a usb rubber ducky, can one use an SD card to emulate an HID device (such as a mouse or keyboard)?
tl;dr: Yes, but it is highly unlikely. (But there is a different possible attack vector as well.)
There are a confusing number of standards around SD cards, but most of them are not interesting in the context of this question: miniSD and microSD refer to the physical form factor, SDSC, SDHC, SDXC, and SDUC refer to the capacity (and also specify the usage of FAT32, as well as exFAT for capacity >= 32 Gio), High Speed, Ultra High Speed (UHS-I, UHS-II, UHS-III), SD Express, microSD Express refer to the bus protocol, C2, C4, C6, C10, U1, U3, V6, V10, V30, V60, V90 refer to the Speed Class.
All of these specify only storage features. An SD, miniSD, or microSD host or card using any of these can only be used for storage, not for I/O.
However, there is one standard that is relevant to this question: SDIO. SDIO specifies I/O capabilities for hosts and cards. This can be used for GPS receivers, sensors, cameras, audio, and yes, also for keyboards and/or mice.
The danger is very small, though, for two reasons:
The host must explicitly implement the SDIO specification. And most of them don't. (The use cases that SDIO was created for have now all been taken over by USB and Bluetooth, so if a device has USB, there is no point in also supporting SDIO.) Unless you have a 10–15 year old handheld device which has only an SD slot and no USB or Bluetooth, it is practically guaranteed that you do not have an SDIO capable host.
SDIO does not have an equivalent to USB Device Classes. USB Device Classes are a standardized way for certain devices to interact with drivers, e.g. there are standard Device Classes for audio interfaces, cameras, and yes, there is the HID (Human Interface Device) class. Any class-compliant device can be used with a standardized class driver shipped with most modern OSs without needing a device-specific driver. This is how plugging any random mouse in your computer works, and it is also how a Rubber Ducky can pretend to be a keyboard without needing to install any drivers. SDIO devices, however, always need a device-specific driver, there are no standardized device classes.
If so, how could this be implemented, and how can it be protected against?
If the target of an attack has a computer with an SDIO slot (which is unlikely) and has a driver for an SDIO keyboard installed (I haven't checked whether e.g. Windows comes with such a driver, but I sincerely doubt it), then the attack would be more or less identical to the USB one.
It can be protected against by not having an SDIO slot, which is likely already the case. While "don't use USB" is practically impossible in this day and age, "don't use SDIO" is the norm anyway, which makes it more or less trivial to eliminate SDIO as an attack vector.
However, as I mentioned in the beginning, there is a different attack vector, which however has nothing to do with emulating an input device. In the list of bus protocols I mentioned above, you might have spotted the SD Express and microSD Express specifications, and the word "Express" might have piqued your curiosity. And indeed, this is exactly what you would expect: the latest generation of SD bus protocols which use PCIe lanes and NVMe protocols … including a perennial "favorite" of security professionals: Direct Memory Access (DMA) to the host memory from untrusted plug-in devices, starting with version 7.0 of the SD specification.
