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
commands.
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:
https://srlabs.de/wp-content/uploads/2014/11/SRLabs-BadUSB-Pacsec-v2.pdf
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.
https://lists.debian.org/debian-security/2018/02/msg00012.html
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:
https://sources.debian.org/src/tiger/1:3.2.4%7Erc1-1/systems/Linux/2/deb_checkmd5sums/
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...
https://www.eff.org/deeplinks/2016/02/investigatory-powers-bill-and-apple
...which is one reason I prefer to stay away from maintaining security
tools or other highly sensitive packages.
