It’s not really practical to defend against for most end users.
Keeping a whitelist of known keyboards and mice is really the only defence even on Linux, and unless you work in a data centre that’s probably way overkill.
With a home PC that doesn’t really work though, because in order to authenticate your mouse without some kind of central mouse log on a server you probably need to click a button, which you can’t do without authenticating your mouse.
As an attacker I just have the bootloaders of my malicious devices advertize the USB IDs of whitelisted devices like Apple Keyboards.
The computer has no way of knowing it is not authentic. There is no signing or certification for USB devices.
The only solution is a kernel that can place all newly attached USB devices in a queue for manual approval.
This is what USBGuard and QubesOS both do. The Linux kernel and udev have native support to hook USB devices early making this easy.
It means no one can drive by plug something in when your computer is locked. You will get a popup asking if you want to give some device other than the keyboard you booted with access to behave as a keyboard .
Also the majority of attacks I have seen in the wild attacking production systems were via endpoint compromises.
If your laptop has remote access to said high value datacenter, then your laptop is a high value target.
Note though that laptops have a nice advantage for this threat model as most have built in PS/2 trackpad and mouse which can let you approve external keyboards/mice etc.
> It means no one can drive by plug something in when your computer is locked. You will get a popup asking if you want to give some device other than the keyboard you booted with access to behave as a keyboard .
Makes me think, what would happen if I plugged this cable, unplugged the keyboard, and power-cycled the computer? Or do a hard power down, then the switcheroo, and then power up? Would USBGuard/QubesOS block the new device, even though it's the one it just booted with?
(I think finding your computer rebooted would fly under the radar of most of the users - they'd blame it on automatic updates or intermittent power failure.)
On that note, I wonder how small you could go with a MITM device to attach between victim's peripheral and their computer. Could you pack enough useful features in a dongle that would not be immediately noticeable by most users?
If you rebooted my computer you would be greeted with a full disk decryption prompt which requires a smartcard and a pin to unlock.
It won't go unnoticed.
If your computer can reboot itself for updates that should be a cause for concern as it means your FDE is being cached somewhere that can use it unattended. I don't allow such things personally.
You do have to check for any untrusted USB devices at boot on a desktop. No getting around that one as you need to be able to use input devices at boot. Best bet is a PS/2 keyboard but those are getting harder to find.
For a laptop you have a better story as you can trust the internal PS/2 keyboard/mouse then use that to approve USB things fresh as needed and dictate what applications they get access to.
I connect my USB webcam to the one VM that needs it on demand, for instance.
Assuming you're using LUKS with device mapper, this reboot did be able to be a plain kexec, and the raw disk key can be placed in a pre-defined location in RAM, like how the dmesg buffer is something set up to be persistent, for recovering information from right before a crash, even if only via an automated log push daemon.
Of course the reboot itself will be noticed when the user gets back - whether it's the login prompt, or boot prompt, or just all applications being closed. I meant it might not be noticed as something unusual, warranting further investigation. Typical user, even tech-savvy one, will just think, "must have been a power glitch", or "damn, those updates forced a reboot again".
The latter is something Windows users are conditioned for. Coming back from the toilet to be faced by a fresh login prompt is common enough even in the age of Windows 10 - and especially when the laptop is controlled by your employer, as IT tends to force a stricter schedule on updates[0]. In my case, this happens 1-2 times a week. While I'm working from home this doesn't matter, but if I were back in the office and came back from lunch to a rebooted computer, I would've assumed it was updates again.
> You do have to check for any untrusted USB devices at boot on a desktop. No getting around that one as you need to be able to use input devices at boot.
Makes sense, thanks for clarifying. I was assuming at least some of these solutions are trying to eliminate this requirement, but ultimately it may not be possible.
(Or perhaps it would be, if USB had something like HDCP so that you couldn't construct a dongle that could be transparently inserted between the computer and the peripheral.)
> For a laptop you have a better story
Right. Also, in case of attacker forcing reboot, they can't rely on users assuming it was a power glitch because laptops have batteries.
> I connect my USB webcam to the one VM that needs it on demand, for instance.
I need to read more about such setups, where you compartmentalize your system with VMs. Is there any good primer you could recommend?
--
[0] - I'm increasingly convinced Windows 10 update system is evil, and does this on purpose. It just so happens that it always forces an update and reboot on my work machine whenever I step away from it for more than 10 minutes. It's like it was monitoring idle time, and thinking "ooh, the user is away, let's reboot the machine and lose all the state". I also recently had to switch Lenovo updater malware to manual, because it kept choosing the exact middle of our weekly team meeting as the time to forcibly update video drivers, blanking my screen for anywhere between 2 and 20 minutes.
>The only solution is a kernel that can place all newly attached USB devices in a queue for manual approval.
Would it recognize the newly attached one, if you do the swap while the computer is turned off and they have the same HW ID?
Because if not, then it's not much better than what Windows lets you do with group policies. Although on Windows you could do this swap even while the OS is running.
Apple claims they're "secure by design" when clearly they're not.[1] I don't think they're explicitly cooperating with any Government, I just think they have enough disgruntled employees who cooperate with the Government and companies that sell penetration software to put in back doors and enable exploits.
There's much less discontent among the rank-and-file at Microsoft, so this sort of thing happens less with them.
It's crazy to me that this is true. Does the government pay Microsoft and Apple to keep it this way, or are they just negligent?