[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Have I caught a firmware attack in the act? Or am I just paranoid?



(Warning: this is being sent from the affected computer, so don't trust "me". BCCd recipients: anyone can post to the debian-security list, but be aware that its public archive does not spam-protect email addresses)

I use usbguard [0], set to allow only the specific USB devices I have.

One of my flash drives apparently stopped working, and investigation found that it had changed Product ID, causing usbguard to block it as an unrecognized device.

Possible explanations - all seem unlikely but it has to be something:
(a) Innocent device malfunction
(b) Malware infection [1-2] via physical access to the drive
(c) Malware infection that began in the computer then infected the drive

(a), innocent malfunction, has the problem that the new Product ID number is not just a bit flip away and the strings changed as well. (Unless the firmware has two descriptors and a switch bit? or a built-in default + a rewritable configuration, and the flash block containing the latter has died?)

(b), physical access attack, would require an attacker breaking into my home. (It has been several years since I last took the affected flash drive anywhere else or plugged it into any other computer.) If they're willing to do that, I seem a strange choice of target: a Debian Maintainer is high-value compared to a random user (because their uploads can infect others) but probably not the highest-value target in a tech-heavy city.

(c), malware on my computer, requires getting around the fact that I haven't recently installed anything from outside Debian except my own package. Maybe a Firefox/Thunderbird sandbox escape?

My integrity_check.py script (checking that system files match the Debian packages they come from) and clamav don't find such malware, but that's not proof. usbguard probably blocks the DFU method of writing to firmware (since I don't have any 0xFE interfaces in my allowed list), but at least some USB flash drives instead use an SCSI command [1], which usbguard won't catch.

Both the old and new Product IDs are listed in /lib/udev/hwdb.d/20-usb-vendor-model.hwdb as flash drives, and it continued to have only a mass storage (class 08: subclass 06: protocol 0x50) interface, i.e. if it is malware it's not using the obvious "pretend to be a keyboard" route.

I'm also not sure whether firmware-based malware is common enough to be something the average developer should worry about. I have seen many reports of the possibility, but the news tends to emphasize rare events, and the reports I've seen of actual in-the-wild examples are ones that target Windows not Linux.

I have unplugged the affected flash drive, but either (b) or (c) would imply that it may not be the only device infected - and also that even if I do replace my whole computer, they may be able to repeat the attack.

[0] https://usbguard.github.io/
[1] (non-trust warning: found via Wikipedia) https://srlabs.de/wp-content/uploads/2014/07/SRLabs-BadUSB-BlackHat-v1.pdf
[2] https://opensource.srlabs.de/projects/badusb/wiki/USB_storage

syslog - before:

Aug 5 07:21:51 rnpalmer-laptop kernel: [34901.758073] usb 3-2.1: New USB device found, idVendor=058f, idProduct=6387 Aug 5 07:21:51 rnpalmer-laptop kernel: [34901.758077] usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Aug 5 07:21:51 rnpalmer-laptop kernel: [34901.758080] usb 3-2.1: Product: Mass Storage Aug 5 07:21:51 rnpalmer-laptop kernel: [34901.758082] usb 3-2.1: Manufacturer: Generic Aug 5 07:21:51 rnpalmer-laptop kernel: [34901.758084] usb 3-2.1: SerialNumber: F32402A6 Aug 5 07:21:51 rnpalmer-laptop kernel: [34901.758274] usb 3-2.1: Device is not authorized for usage
[...]
Aug 5 07:21:51 rnpalmer-laptop kernel: [34901.953787] usb 3-2.1: authorized to connect

syslog - after:

[these are messages that are saved after hibernation, but the first ones may actually have been generated before it; it is not normal to get "new USB device" at this time] Aug 6 21:52:26 rnpalmer-laptop kernel: [50368.297466] usb 3-2.1: reset high-speed USB device number 21 using xhci_hcd Aug 6 21:52:26 rnpalmer-laptop kernel: [50368.605593] usb 3-2.1: device firmware changed [ from the source code this actually means "descriptor changed", https://sources.debian.org/src/linux/4.9.168-1/drivers/usb/core/hub.c/#L5520 ]
[...]
Aug 6 21:52:26 rnpalmer-laptop kernel: [50370.579113] usb 3-2.1: New USB device found, idVendor=058f, idProduct=1234 Aug 6 21:52:26 rnpalmer-laptop kernel: [50370.579117] usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Aug 6 21:52:26 rnpalmer-laptop kernel: [50370.579119] usb 3-2.1: Product: Mass Storage Device Aug 6 21:52:26 rnpalmer-laptop kernel: [50370.579121] usb 3-2.1: Manufacturer: Alcor Micro Aug 6 21:52:26 rnpalmer-laptop kernel: [50370.579255] usb 3-2.1: Device is not authorized for usage


Reply to: