Hello!
Just stumbled over that little USB Canary project - https://github.com/probablynotablog/usb-canary - i think its a nice idea - specially if the workstation is locked.
anyone know a way to actually stop a linux workstation from talking to new USB devices when it is locked?
dont think there is a good way to stop the kernel from talking to devices besides just removing usb support though @Eden or @Zoltan might know something that i dont
also bonus points for having a great readme.md. seen some really bad ones with nothing more than a basic description of what of the program
On the better hardware or open source BIOS you can disable the entire USB interface from being activated by the UEFI. That is a more pressing problem than when the PC is running but locked, because that's where the system would be more vulnerable.
For instance: if you would want to read something from the PC over the USB bus, and a linux system is running even though locked, you would have to know an exploit that would allow you to do that, and the RBAC/MAC would have to be set to permissive at least. In practice, you would have to already have malware on that PC, malware that is exempt from the RBAC of the system, so for instance the proprietary nVidia driver or something along those lines.
But, if you would shut off the system and fire it up again, the UEFI or BIOS would initialize a pretty functional USB interface for you, without asking questions. If it were a system with secure boot, chances are that secure boot is either switched off, which is something a lot of linux users do and all BSD and Mac users do, or it's a system that had windows on it or was prepared to have windows on it by the OEM, so it has the well documented Windows keys marked as trusted in it. So if USB booting is not disabled, the whole PC is pwned at that time, because rootkits can be installed, etc... on systems with a non-discrete TPM, this is even more of a problem.
However, even if USB booting is disabled, and if it's a PC that once had Windows on it or that has an Intel ME supporting chip or that comes from a particular OEM (cough Lenovo cough), merely the initialisation is already enough to probably get to the rootkits that are on the system (e.g. FlexNet for PC's that had Windows on them before or still have it in dual boot, Intel ME, Lenovo Care, ...). The portion of the boot disk that would be read to find the boot manager, something that the UEFI selects, would be read while the system was still not initiated by the operating system, but rather by the UEFI, so there would be no protection by the operating system. On Linux, the first thing to load would be Yama, then Systemd, and that would effectively block further attempt, because the kernel provides functionality to prevent such data access, but in order to read just that tiny single block 32 FlexNet rootkit that Microsoft and Adobe and Autodesk and nVidia and many others use for their DRM marking, it would be enough. It's definitely enough to see the identity of the owner of the PC and to have a basic profile of him/her based upon the DRM registrations.
Edit: and it gets worse sometimes lol. On linux and BSD, the support for OPAL is refused up until now because it would trust the UEFI with the keys to the encryption of the hard drive. On other systems, it could be enabled. So for instance that sexy Samsung SSD (which has had OPAL functionality since forever, because Samsung does primarily mobile, and there it makes sense), unless you're on an open source operating system, the UEFI will actually load the decryption key for your hard drive to get to your operating system, so while on basic full hardware initialisation through the UEFI. That is just about the ultimate backdoor to any full drive encryption. In linux and BSD, you normally make two boot partitions, one is the boot-efi, which loads grub from UEFI, and there GRUB takes over as boot manager from the UEFI. Then GRUB loads the init.rc or initramfs initialising system of linux, which loads the decryption over user input and starts to decrypt the drive to get to the operating system. It's not perfect because those two boot partitions are unencrypted, and again, if there was windows installed before on that PC, or still is in dual boot, the FlexNet rootkit will be in the first boot partition, unencrypted, loadable by the UEFI, but at least it won't load a decryption key. Some users but the actual initramfs boot partition in the /boot directory under root, so that Grub has to load the decryption key (from user input), then initramfs (which has no way of getting it from grub) asks for that key again to decrypt the OS partition. Most users put it in the extra unencrypted /boot partition, so that grub doesn't load any key, but only initramfs does. No solution is perfect, but the second is probably a tiny bit better, because the UEFI basically loads GRUB, but has nothing to do with initramfs, so there is an extra hurdle there for a UEFI functionality based intrusion.
I see the post was marked with solution but I didn't give a solution yet lol. The solution would be to set your UEFI to ask for a password before initialising ("set password at boot"). This prevents the USB ports from initialising on UEFI start, unless a password is given.
Oh wow - first of all - thanks for that amazing excerpt on how fkd USB and UEFI is ^^
Ok this RBAC/MAC (which I will google in a moment) is part of a default linux installation (kernel?) so its not depending on the particular distribution?
Bummer - I have secure boot disabled and boot in bios mode as that way I was able to setup manjaro with full disk luks.
Windows was never running on my Lenovo (sigh) T450s - but I most likely can be sure it has the keys baked in nonetheless.
By default on my machine boot from anything but the internal SSD is disabled, UEFI master password set, boot order disabled and locked to the internal SSD, and that SSD is full encrypted despite a little grub in the MBR.
both yes :.(
Never registered or enabled it though
O c'mon - I am classified as paranoid by my souroundings but that is new to me O.o
this solution thing is cool
dont want to derail this thread but is there a good method to see if this works on lenovo machines?
my lenovo laptop has none of that crap on it and im wondering if it is possible
Google "absolute persistence", and cry lol...
Coreboot is just about the only option to make sure, but there are a few things that give you an extra layer of security. The most important one is to not buy a system with an Intel CPU that has IntelME on the chip. On many Intel systems, IntelME doesn't sit in the chip, but rather in the Windows driver for the Intel hardware. The machine I take everywhere for instance is a Travelmate linux edition with the Intel Pentium, Atom-based chip. It's a low power quad core that performs about the same as a late Intel Core 2 Duo, but has a faster bus and peripherals, and only consumes about 3.5 Watts, so it doesn't need active cooling. Those Atom-based SKU's have two very big advantages: 1. there is no IntelME functionality in the hardware, and 2. there is a discrete TPM. So Acer will of course have lo-jacked the UEFI, just because lol, but they would need physical access to the device to be able to take advantage of it, because the thing needs an operating system to go online (because no LAN port etc...), and probably ties in with IntelME to get anything worth while across. It also has a disk sanitation feature in the UEFI, which does a multiple overwrite wipe without awareness of filesystems or the likes, so that should be as effective as a dedicated hardware wiper. First thing I always do before turning any device on for the first time, is take it apart and check the innards of course, swap out the Wi-Fi module and the drive, then turn it on and wipe the keys stored in the secure boot and the TPM, then install Linux on it, let it shim the Microsoft key in the secure boot and make and register it's own, then I go into the UEFI and disable the Microsoft keys. This causes the UEFI to not know what to boot, so you have to set the UEFI manually to the trusted boot manager of your choice. You set it to the efi of your linux distro instead of the shim. Then that whole liability is pretty much out of the way and secure boot actually works to your benefit instead of to your detriment lol.
I would presume exactly the same on Lenovo machines, and would do exactly the same there. Lenovo has been caught with its pants down, but every single OEM does the same. Every single PC is lo-jacked, they just mostly use the UEFI these days instead of an actual rootkit on a storage medium. The only factor you can limit, is the "phone home" part of the equation.
The part about that isn't new to me ^^ I have accepted it somewhat - as I love my thinkpad(s) way to much - and there isn't any core- or libreboot bios yet for the T450s that I know of...
Tried to disable as much as I can - and so far never noticed any traffic thats not "user generated" coming or going (mirroring the port on the switch so should get lowlevel stuff too)
will look into it when i get home. thanks for the info as always