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

2019-08-13 Thread Paul Wise
On Tue, Aug 13, 2019 at 3:30 PM Rebecca N. Palmer wrote:

> but at least some USB flash drives instead use an SCSI command [1],
> which usbguard won't catch.

This seems like a significant missing feature, but I guess it would
require a fair bit of Linux kernel work to support filtering such
commands.

> I'm also not sure whether firmware-based malware is common enough to be
> something the average developer should worry about.

IMO proprietary software is worrisome in any context and the Linux
kernel definitely needs hardening against malicious devices. There has
been some recent work on exploiting radio firmware and then exploiting
Linux from there, here are two examples that come to mind:

https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html
https://blade.tencent.com/en/advisories/qualpwn/

> Aug  5 07:21:51 rnpalmer-laptop kernel: [34901.758084] usb 3-2.1:
> SerialNumber: F32402A6

This got deleted.

> Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579113] usb 3-2.1: New
> USB device found, idVendor=058f, idProduct=1234

This vendor/product combo is known to usb.ids:

/usr/share/misc/usb.ids:058f  Alcor Micro Corp.
/usr/share/misc/usb.ids:1234  Flash Drive
...
/usr/share/misc/usb.ids:6387  Flash Drive
...
/usr/share/misc/usb.ids:9380  Flash Drive
/usr/share/misc/usb.ids:9381  Flash Drive
/usr/share/misc/usb.ids:9382  Acer/Sweex Flash drive

> Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579117] usb 3-2.1: New
> USB device strings: Mfr=1, Product=2, SerialNumber=0

The serial number went to zero.

> Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579121] usb 3-2.1:
> Manufacturer: Alcor Micro

This changed from "Generic" and idVendor=058f is Alcor Micro.

Based on the serial number deletion, I'd speculate that some internal
part of the flash holding details about the device identity
malfunctioned, so the firmware reverted back to the default hardcoded
product id for Alcor flash drives. No idea if this is a reasonable
theory or what caused the malfunction, malware or otherwise.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

2019-08-13 Thread Rebecca N. Palmer
(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