Probably a false alarm Re: Have I caught a firmware attack in the act? Or am I just paranoid?
On 15/08/2019 21:57, Rebecca N. Palmer wrote: Paul Wise wrote: 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: I disassembled another Alcor stick (also 058f:6387 in its normal state, but several years older) and tried to trigger this deliberately by shorting pins (using pinout [0] and assuming pin 1 is marked by the corner spot, _not_ the orientation of the writing): Flash always "busy" [1] (shorting pins 47+48 to connector shell ground) just makes it not connect (presumably waiting indefinitely for the flash to become ready)... ...but shorting flash data pins to each other to turn reads to garbage (roughly 39-44 as that was the width of my screwdriver point - the full set is 37-44 + 27-34) *does* trigger the 058f:1234 state. This state persists after removing the short if the stick is left plugged in, but the normal 058f:6387 returns after unplugging and replugging it. Hence, I now consider the first stick to be broken, not malicious. Paul Wise wrote: IMO proprietary software is worrisome in any context For Phison sticks, [2] is an at least partially open source firmware, including an option to deliberately break the update mechanism (preventing future changes, malicious or otherwise, without physically disassembling the stick), but it uses non-free tools to install. (I haven't tried it.) (non-trust warning: found via search and/or Wikipedia) [0] https://www.alldatasheet.com/view.jsp?Searchword=AU6983 [1] http://www.onfi.org/specifications [2] https://github.com/brandonlw/Psychson#running-no-boot-mode-patch
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
The key question about it is how the archive keys are handled. I believe that keeping such a key offline would be a whole lot of work. It would perhaps also help to have it on a gpg-Smartcard. Am 23.08.19 um 09:10 schrieb Rebecca N. Palmer: On 17/08/2019 12:18, Elmar Stellnberger wrote: to be safe the key handling policy needs to be offline enforced There have been various attempts to encourage / simplify the use of offline keys, but it isn't currently required in Debian, and some of them only suggest keeping the master key (not the signing subkey, which is enough to upload packages) offline. (non-trust warning: these are anyone-can-post areas) https://wiki.debian.org/GnuPG https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment https://lists.debian.org/debian-project/2017/08/threads.html#00011 Also, firmware attacks can reach offline keys. However: Intelligence can not spoof all downloads - there is always a certain percentage of downloads which get the original data; i.e. they only spoof the download if they know who is downloading. Individual developers' keys are used to protect uploads (from that developer to the Debian archive), but downloads (from that archive to a user, i.e. apt upgrade/install) are protected by a tree of hashes signed by the archive's own key (see /var/lib/apt/lists). Hence, stealing an individual developer's key doesn't let an attacker target specific people; it does let them upload as that developer, but if they do, *everyone* sees their version of that package. As you note, this makes them more likely to be caught. To get a malware package to only a specific person, they would need either a stolen *archive* key, or a bug/backdoor in apt that makes it accept signatures it shouldn't. Proposal to keep a log of the official hashes, which would allow the target of such an attack to prove it was an attack: https://debconf19.debconf.org/talks/66-software-transparency-improving-package-manager-security/
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
On 17/08/2019 12:18, Elmar Stellnberger wrote: to be safe the key handling policy needs to be offline enforced There have been various attempts to encourage / simplify the use of offline keys, but it isn't currently required in Debian, and some of them only suggest keeping the master key (not the signing subkey, which is enough to upload packages) offline. (non-trust warning: these are anyone-can-post areas) https://wiki.debian.org/GnuPG https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment https://lists.debian.org/debian-project/2017/08/threads.html#00011 Also, firmware attacks can reach offline keys. However: Intelligence can not spoof all downloads - there is always a certain percentage of downloads which get the original data; i.e. they only spoof the download if they know who is downloading. Individual developers' keys are used to protect uploads (from that developer to the Debian archive), but downloads (from that archive to a user, i.e. apt upgrade/install) are protected by a tree of hashes signed by the archive's own key (see /var/lib/apt/lists). Hence, stealing an individual developer's key doesn't let an attacker target specific people; it does let them upload as that developer, but if they do, *everyone* sees their version of that package. As you note, this makes them more likely to be caught. To get a malware package to only a specific person, they would need either a stolen *archive* key, or a bug/backdoor in apt that makes it accept signatures it shouldn't. Proposal to keep a log of the official hashes, which would allow the target of such an attack to prove it was an attack: https://debconf19.debconf.org/talks/66-software-transparency-improving-package-manager-security/
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
Read only switches are a security feature because you can read the content without the fear that it may be altered.[...] The read-only switch makes it as safe as a read only burnt dvd. The physical read-only switch on SD cards isn't: it's enforced at software level, not hardware level. That is only half of the truth. If you have an SDcard - USB adapter the adapter is responsible for doing the check and the adapter is hardware. If you mean that the SDCard itself enforces the check then this is of course not the case. https://en.wikipedia.org/wiki/SD_card#Card_security Downloads can and often are impersonated if you do not use tor so that you will be shipped the malwared-packages for comparence instead of the original ones. apt (by default) won't install packages with a bad signature: are you claiming to have seen fake packages _with a valid signature_, or are you referring to downloads of something other than Debian packages? (I haven't read your links: as I don't have proof of who you are, doing so would itself be a security risk.) gpg signatures of packages are least trustworthy since the NSA has a private key stealing programme. Never trust a signature as long as you do not know about the key handling policy - and to be safe the key handling policy needs to be offline enforced like described here (I would suggest that you trust my web page too if you trust in what I am saying): https://www.elstel.org/software/GnuPG-usage.html.en Most people do not enforce secure offline storage of secret keys - they encrypt on unsafe online computers and they do not secure the data carrier where the secret key is stored. If you have read my previous posts you know that both conditions need to be met in order to avoid the secret key to be stolen. You need to check the sha-s at least via tor (if you do not have all the original packages available on blue ray media). Intelligence can not spoof all downloads - there is always a certain percentage of downloads which get the original data; i.e. they only spoof the download if they know who is downloading.
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
I have now done the check from a boot DVD: clean, but as already noted, there are places it doesn't check. On 16/08/2019 20:14, Elmar Stellnberger wrote: Concerning your program I have seen that it uses /var/lib/dpkg/info/$2.md5sums. This is inherently unsafe because an attacker can simply alter this file alongside with all the other altered file. Only as a better-than-nothing method if the .deb isn't cached - if it is (which it is on my system), it checks the whole hash tree (which uses sha256) up to the Release signature (using the debian-archive-keyring from the checker DVD if you're using one). Manual hash lists are also supported. Read only switches are a security feature because you can read the content without the fear that it may be altered.[...] The read-only switch makes it as safe as a read only burnt dvd. The physical read-only switch on SD cards isn't: it's enforced at software level, not hardware level. https://en.wikipedia.org/wiki/SD_card#Card_security Downloads can and often are impersonated if you do not use tor so that you will be shipped the malwared-packages for comparence instead of the original ones. apt (by default) won't install packages with a bad signature: are you claiming to have seen fake packages _with a valid signature_, or are you referring to downloads of something other than Debian packages? (I haven't read your links: as I don't have proof of who you are, doing so would itself be a security risk.)
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
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. An infected system will also alter the md5sum utility so that it will return the md5 of the pristine file instead of the altered one which is actually on disk (I have already seen that). Concerning your program I have seen that it uses /var/lib/dpkg/info/$2.md5sums. This is inherently unsafe because an attacker can simply alter this file alongside with all the other altered file. Anyone knows about this file and if I logged in via ssh an did some manual cracking then I also replaced the md5-s in that file with sed -i. Nonetheless manual sha512-lists are generally more secure than tools just checking files in the packages like debcheckroot because they also record files that are not in the installation database as well as files auto-generated/altered on installation by installation scripts. You can create such an sha512-list after securely offline-installing and put it on an sdcard which you take always with you. I like sdcards because they have a read only switch and are very small and flat so that you can easily take them with you. Read only switches are a security feature because you can read the content without the fear that it may be altered. Of course you can not easily install new packages then. That requires you checking all the sha512s via a clean boot medium. After that you can boot into the system, install new packages and update the sha512s. I also take the boot media with me where the dvd images reside on sdcards bootable via USB-sdcard adapter. The read-only switch makes it as safe as a read only burnt dvd. Concerning debcheckroot I had planned to make it support mounting different install-dvds/bds. At the moment it only works with a singleton install blue ray. Installing from blue ray or dvd is an additional security measure you can take to spot malware. I would not have been able to spot the rootkit I had talked about in my last mail in Brasileia, Brazil (Cobija, Bolivia) if I had decided to install online updates because then fetching the updated packages for the tool (debcheckroot supports this) would have been much more complicated. Downloads can and often are impersonated if you do not use tor so that you will be shipped the malwared-packages for comparence instead of the original ones. So always use tor with debcheckroot if you do not have all the packages available offline. To come back to the rootkit spotted in South America I had the fortune to spot it only because I could compare all files 1:1 which was only possible because I did not need online repositories to install the clean image of the distro. Here is again the reference for debcheckroot: https://www.elstel.org/debcheckroot/| |
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
Am 15.08.19 um 22:57 schrieb Rebecca N. Palmer: That would suggest it's not them, as the obvious reason to target me is to trick me into uploading malware. If that is the case you would have to take hellish care. I have read articles of the compiler as attack vector, i.e. an altered compiler can produce infected programs even if the source code is clean. You may need to compile either offline or at least on a computer where you do not open a web browser or email program to get maximum security. AFAIK System76 is doing something similar for their firmware updates. It is a small company selling computers with deactivated Intel ME. That is just another huge backdoor in any contemporary online computer so the computer for compiling would likely need to have a disabled ME.
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
unsubscribe > On 16 Aug 2019, at 19:16, Elmar Stellnberger wrote: > > >> 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. >> >> With the amendment of the StPO 2017, the German Bundestag created a legal >> basis for the widespread use of these so-called Statetrojans[¹] >> >> More states have laws that let they spy citizen with trojans. This cause our >> device/software to be less secure and the same backdoor can be used also by >> others. Also when data is collected is also accessible by people who work >> directly/indirectly and some of these can use that data (sell/send to >> others/read for himself/...) >> > Yes, I´d believe it to be a problem when the state buys zero days exploits > which are then kept secret so that they can continue to be exploited. In the > worst case people are paid for moving malicious bugs in and by selling them > later on. The state should act responsible and contend to improve the > security of our systems instead of undermining them. If it is true what I > have heard then intelligence services in Germany are still using typewriters. >
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
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. With the amendment of the StPO 2017, the German Bundestag created a legal basis for the widespread use of these so-called Statetrojans[¹] More states have laws that let they spy citizen with trojans. This cause our device/software to be less secure and the same backdoor can be used also by others. Also when data is collected is also accessible by people who work directly/indirectly and some of these can use that data (sell/send to others/read for himself/...) Yes, I´d believe it to be a problem when the state buys zero days exploits which are then kept secret so that they can continue to be exploited. In the worst case people are paid for moving malicious bugs in and by selling them later on. The state should act responsible and contend to improve the security of our systems instead of undermining them. If it is true what I have heard then intelligence services in Germany are still using typewriters.
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
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. Well, I am from Austria and most of what has happened and what you can read about took place in Austria: https://www.elstel.org/CyberAttack-elstel.html.en ... with one exception: The cracked system, where they had replaced glibc and some system library files, was cracked in Puno, Peru while I had discovered the crack later on in Brazil. Some years ago I have sent out blue ray images with the cracked installed system as well as the RedHat SELinux packages used to install a clean system 1:1 where you can compare both systems, cracked and clean file by file. The sha512-sums of these blue ray images are still online at: https://www.elstel.org/software/
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
*Benjamin Franklin* once said: "Those who would *give up* essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." I suspect statesman of many nations have made similar declarators. Why is privacy almost complete gone (IMHO) ... 1. The strange need to post the most intimate details of ones life on Social Media. 2. No one is afraid of anything, but there is a complete lack of bravery. 3. The detestable need for 'me' to know any and all information about 'you', and the self-rationalization that it is OK.. 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. With the amendment of the StPO 2017, the German Bundestag created a legal basis for the widespread use of these so-called Statetrojans[¹] More states have laws that let they spy citizen with trojans. This cause our device/software to be less secure and the same backdoor can be used also by others. Also when data is collected is also accessible by people who work directly/indirectly and some of these can use that data (sell/send to others/read for himself/...) Ciao Davide [¹] https://www.spiegel.de/international/germany/state-spyware-german-court-permits-restricted-online-surveillance-a-538094.html -- Systems Since 1948 Craig M. Houck ><> Tech Hub/Computer Center 3rd Floor 332 607 777 6827 We are only as good as the problems we solve!
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
On 15/08/19 22:57, Rebecca N. Palmer wrote: 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. With the amendment of the StPO 2017, the German Bundestag created a legal basis for the widespread use of these so-called Statetrojans[¹] More states have laws that let they spy citizen with trojans. This cause our device/software to be less secure and the same backdoor can be used also by others. Also when data is collected is also accessible by people who work directly/indirectly and some of these can use that data (sell/send to others/read for himself/...) Ciao Davide [¹] https://www.spiegel.de/international/germany/state-spyware-german-court-permits-restricted-online-surveillance-a-538094.html -- Dizionari: http://linguistico.sourceforge.net/wiki Esci dall'illegalità: utilizza LibreOffice/OpenOffice: http://linguistico.sf.net/wiki/doku.php?id=usaooo Non autorizzo la memorizzazione del mio indirizzo su outlook
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 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.
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
Dear Rebecca Am 13.08.19 um 09:14 schrieb Rebecca N. Palmer: (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. Just think of central intelligence. They know when you are outside of your home by locating your mobile phone and they can easily unlock your door because they have access to the lock and key service. 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 - and many people do not know in a first hand why they are targeted. What they also do is steeling secret gpg keys from computers that are online. 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. Have you written something like debcheckroot? If yes I would be interested in it. 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 have not seen the checksum algorithm being targeted directly up to now yet. It may be more probable that they simply infect a hidden file in your home directory or some binary file like the syslog which then loads the malware on every boot. Comparing or checksuming files can not detect such kind of malware. https://www.elstel.org/debcheckroot/ 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. 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. 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 they would target your USB drive and not your computer or why they do not simply break in via your email or web browsing program. I have only seen intelligence visiting my home when I left an offline computer around with HDD. In case your are interested here is some more security related material on my web page: https://www.elstel.org/software/GnuPG-usage.html.en https://www.elstel.org/CyberAttack-elstel.html.en Regards, Elmar
Re: Have I caught a firmware attack in the act? Or am I just paranoid?
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?
(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
