Physical Attack: Unplugging Keyboard and inserting malicious keyboard/stick into sys-usb

RamLovingPenguin · October 31, 2025, 12:43am

My QubesOS computer is located somewhere that many people regularly pass by. It’s in a computer cage and motherboard bios password is set. Thus when the computer is off, I don’t have to worry about a quick fly by physical attack.

However, when QubesOS has already booted and the screen is locked and sys-usb is running with usb keyboard and mouse connected to it, can QubesOS be hacked merely by unplugging my usb keyboard and mouse out of my usb extension cable and placing a malicious keyboard or other malicious usb into my usb slot when the screen is locked? I always check the usb extension cable to make sure it hasn’t been tampered with before unlocking.

xahare · October 31, 2025, 4:53am

The qubes-os team should add a way to tell the lock screen that a usb device has changed, esp for situations without a sys-usb. Making a custom screen saver would add attack surface, but should be minimal.

I would stain or otherwise randomly mark the keyboard to make it harder to swap without you noticing. A splat of paint on a worn down sticker. Some hard to see scratches. Fuzzy coat or glitter nail polish over the screw holes. Or, if its safer, just keep your keyboard with you or somewhere else when not in use.

Just found this, but haven’t tried it yet. GitHub - proninyaroslav/blink-comparison: Simplifies comparing photos of tamper-evident seals and patterns using your eyes

MacGyver · October 31, 2025, 4:54am

Hi @RamLovingPenguin

Assume it is possible, though hopefully someone here knows for sure.

While we wait for a definitive answer, maybe this is something you could try out.

Theoretically:

To test this, you will need another identical keyboard and another usb keyboard.

Unplug and replace with the identical keyboard, wake up the machine and see if it is working.

Let the machine screen lock again, then unplug and replace with the alternative replacement keyboard.

If either one or both work without messages or errors, then I guess it ‘might’ be possible.

https://www.opswat.com/blog/the-danger-of-a-usb-device-and-keystroke-injection-attack

qubist · October 31, 2025, 7:29am

@RamLovingPenguin

I don’t know what exactly you mean by hacked but generally anyone with a physical access can damage a system. It is not necessary that to be through malicious USB devices. I am thinking of powerful EM field, a cup of acid, a heater blower (or hair dryer), fine dust (especially metal) blown against the zone where the fans suck air, etc.

In regards to Qubes in particular, the OS will accept any USB keyboard by default (in case there is no PS/2 alternative configured). A possible attack is to switch to console mode, reboot the system, boot from a USB stick and all the rest of it.

Hardened option for single USB keyboard

opened 12:29PM - 02 Jan 24 UTC

emanruse

P: default C: input proxy

### The problem you're addressing (if any) Currently, on systems which can us…e only USB keyboards, it seems possible to have unrestricted number of such USB keyboards that are automatically allowed to connect to dom0 due to `/etc/qubes-rpc/policy/qubes.InputKeyboard` permissive policy. This makes it possible a malicious USB device (e.g. a USB memory stick) to represent itself as a keyboard, do its mischief, then switch back to being a non-keyboard. Using usbguard inside sys-usb to allow only specific predefined keyboards is a possibility, however it might result in a situation when the user gets locked out of the system. Example: The user has only one physical keyboard and whitelists it in usbguard rules. If the keyboard hardware stops functioning (e.g. the keyboard is physically damaged), the user will be compelled to replace it with another. However, since the new keyboard will not be whitelisted, the user won't be able to access the system through it, regardless of the fact that it is a good (non-malicious) device. ### The solution you'd like Provide an option (perhaps even enforced by default) which allows the user to restrict the number of possible USB keyboards on the system to 1 (one) at a time. ### The value to a user, and who that user might be The proposed solution would make it impossible for a malicious device to act as described, as a second keyboard will be denied. The only way to use another USB keyboard would be to physically disconnect the first one, then connect another. That must also be documented properly. #### Possible caveat **I don't know if that is possible** (there are [some](https://forums.tomshardware.com/threads/every-usb-port-will-randomly-disconnect-for-a-few-seconds-on-new-pc.3793952/) [reports](https://superuser.com/questions/1450976/external-usb-hard-drive-momentarily-disconnects-when-additional-external-hard-dr)), but just for extra consideration: If for some reason (e.g. a driver bug, power related issues or other) the malicious USB device is able to cause the original keyboard to (appear to) disconnect or simply "sneak in" while the original good keyboard is actually disconnected, the proposed solution will not work *per se* - the malicious device may still connect as a keyboard and accomplish the described attack, and during that period the actual keyboard will be blocked. To prevent such possibility, additional possible measures to the solution might be: - Enable any newly connected USB keyboard **only after reboot** In this way, even if a temporary disconnect happens, no other device would be able to take over a running the system, because to accomplish an attack the malicious device would have to cause a reboot of dom0 through sys-usb, which seems impossible in Qubes OS (at least not without a serious security bug). - UI for easy whitelisting of newly connected keyboards (using usbguard rules in sys-usb) Without other input device (e.g. at least a mouse able to click and confirm the newly connected keyboards), a possibility for user input might be the power button of the system. A service like `acpid` may be used to monitor for events. Example usage: A new keyboard is connected. The UI dialog shows up and asks for confirmation. The user is required to press the power button of the system to activate the new keyboard, after which it gets whitelisted in `/etc/usbguard/rules`. The `acpid` service may probably run in a separate VM (sys-acpi), thus making it impossible for a malicious device to attack both sys-usb and sys-acpi. Having sys-acpi may even provide extra security, e.g. the number of presses within a period of time might be configurable, e.g. "must press 3 times within 10 seconds", and may serve as a "password" for allowing new USB devices. **Additional notes**: As by default passwordless root is enabled in VMs, whitelisting devices in sys-usb itself may turn out vulnerable. I don't know what inter-VM communication mechanism for this may be suitable but it seems better to isolate the "credentials" of devices - have another VM store and verify if a device is whitelisted, then report the result back to sys-usb.

solene · October 31, 2025, 8:09am

If it’s in something like a rack in a data center, you could add a sensor reporting when it was opened, or cameras. You could also use your qubes os remotely through the network with sys-gui-vnc

I’m not convinced that for your threat model it’s enough to report about usb activity that happened on the system.

KitsuneNoBaka · October 31, 2025, 9:56am

app-linux-input-proxy v1.0.44 (r4.3)
app-linux-input-proxy v1.0.44 (r4.2)
A very interesting and exciting patch from security perspective. It is now possible to allow only certain USB input devices (Keyboards, Mice, Tablets) based on the vendor ID, Product ID or even the USB port it is connected to. This way, you could avoid most hardware keyboard loggers which usually could not fake the VID/PID (at the time of this post). This is very useful considering how such loggers have become so common these days everywhere and even open source implementations which could be easily implanted inside original devices are readily available. The only issue with this patch is that the documentation for it is not yet available. Tech-savvy users should not have problem to understand it and use it by reading the patch code and the related Github issue.

There’s githup page for it

I’m experimenting with it but only thing that I’ve achieved is that mouse pointer is not moving or keyboard don’t register special keys (CTRL, ALT) but mouse buttons still works and alphanumeric keys of keyboard also works - strange thing.

–

PS: OK, I have it, but it’s trial and error and I don’t know how to pull all relevant data

First, in a sys-usb terminal you need to list PCI devices to find usb controller to which mouse+keyboard is connected.

for me it’s

00:09.0 USB controller: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller (rev 01)

note device address - 00:09.0

Then you need devices vendor and product number - lsusb
mouse:

Bus 004 Device 018: ID 258a:0036 SINOWEALTH Wired Gaming Mouse

Vendor=258a Product=0036

keyboard:

Bus 004 Device 023: ID 0c45:8033 Microdia AK820MAX

Vendor=0c45 Product=8033

Then in dom0 in Qubes Policy Editor open 50-config-input.policy

default:

# THIS IS AN AUTOMATICALLY GENERATED POLICY FILE.
# Any changes made manually may be overwritten by Qubes Configuration Tools.

qubes.InputMouse	*	sys-usb	@adminvm	ask
qubes.InputKeyboard	*	sys-usb	@adminvm	ask
qubes.InputTablet	*	sys-usb	@adminvm	ask default_target=@adminvm

after changes (I’ve watched notification about mouse/keyboard denied in dom0):

# THIS IS AN AUTOMATICALLY GENERATED POLICY FILE.
# Any changes made manually may be overwritten by Qubes Configuration Tools.

qubes.InputMouse	+usb-0000_00_09.0-1.4+3-258a-36-111	sys-usb	@adminvm	allow
qubes.InputKeyboard	+usb-0000_00_09.0-1.3+3-c45-8033-110	sys-usb	@adminvm	allow
qubes.InputMouse	+usb-0000_00_09.0-1.3+3-c45-8033-110	sys-usb	@adminvm	allow
qubes.InputTablet	*	sys-usb	@adminvm	ask default_target=@adminvm

+ is for one argument
usb-0000_00_09.0 is from PCI list
-1.4+3- and -1.3+3- dunno from where is taken
258a-36 and c45-8033 is from lsusb (leading zeros are omitted)
-111 and -110 dunno from where are coming

But it works.
If I connect any other mouse/keyboard it shows notification about denied:inputMouse or denied:inputKeyboard

One thing - there was bug in qubes-app-linux-input-proxy package and it didn’t worked.
For this to work template must be upgraded to testing repository:

4.2

sudo dnf update --enablerepo=qubes-vm-r4.2-current-testing

4.3

sudo dnf update --enablerepo=qubes-vm-r4.3-current-testing