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

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

Paul Wise 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

If the attacker has root (which they need to use either firmware update mechanism anyway) on the base system, they've already won: they can simply uninstall usbguard or similar tools.

If the attacker is in a VM/container, writing to firmware is a possible escape route, but I'm not sure whether usbguard or the VM software is a better place to address it.

I think of usbguard as mostly for blocking the device-to-host (not host-to-device) direction of infection, specifically devices that pretend to be keyboards and "type" malicious commands.

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.

It makes sense for the firmware to have a fixed bootloader part: USB is a complex enough protocol that accepting firmware updates over it is likely to itself require firmware, and the (different) brand that has publicly been attacked does have one:


On 14/08/2019 16:31, Elmar Stellnberger wrote:

Central intelligence usually does not target Debian software directly. If a malware was distributed via the official release or update service then someone would get to know it and proper antivirus/malware detection software could be written. They will never do so. They only target specific individuals like you

That would suggest it's not them, as the obvious reason to target me is to trick me into uploading malware.

  Have you written something like debcheckroot? If yes I would be interested in it.


The check script is config/includes.chroot/usr/local/bin/integrity_check.py

debcheckroot is GPL so it could be an option to continue developing it though I did not have the time to do so in the last years. However it currently still uses unsafe md5sum. However I

Another potential home for this script is tiger, which also currently has an MD5-only checker:


It may be more probable that they simply infect a hidden file in your home directory[...]   I would presume that you have booted from DVD when checking your installation since it does not make sense to check from within an infected system. That would be going to fail in almost 100% of the cases.

This check was done from within the system (it was never intended to be a perfect test - as you note, it can be evaded by infecting a non-package-owned file), but my script can also do checking from a DVD boot.

  There is hardly any way to get a computer safe except when you remove all networking hardware putting the computer offline and then always carry the M.2 drive to boot from with you. It would be a question why

My GPG keys are offline in that I only insert them after booting from a DVD with a no-networking kernel, but as this is on the same physical computer (which doesn't have a hardware-level way to disable networking), a firmware attack could bypass this.

I have only seen intelligence visiting my home when I left an offline computer around with HDD.

If you feel safe answering: what country was this in? Your name and time zone suggest Germany/Austria/Switzerland, which I wouldn't have thought of as the kind of places that do this.

Though I also wouldn't have thought of Britain as the first place to have "help us spy and don't tell anyone, or we'll imprison you" legal orders until we were...


...which is one reason I prefer to stay away from maintaining security tools or other highly sensitive packages.

Reply to: