USBGuard - what should we allow or disallow by default?

Development
1

Kicksecure 18 is intended to ship USBGuard by default, with a configuration that should block likely-malicious, unknown, and unusual devices. The hope is that it won’t block so much as to significantly increase the difficulty of using Kicksecure, while also making it more difficult to use devices such as the Hak5 rubber ducky or O.MG plug (popular keystroke injection devices).

Our current USBGuard configuration is visible at security-misc/etc/usbguard/rules.d/30_security-misc.conf at master · Kicksecure/security-misc · GitHub. The original intent was to allow everything connected at boot, and then disallow everything other than mass storage devices, keyboards, and mice, while also not allowing keyboards or mice to be combined with other interfaces, and not allowing additional keyboards and mice to be attached if one is already present. However, as pointed out by Marek (the lead Qubes OS developer), this is going to cause tons of legitimate devices to be blocked: Polish USBGuard configuration · Kicksecure/security-misc@cba1687 · GitHub

We have a pretty classic security vs. usability tradeoff here. We don’t want to block so much that users disable USBGuard because they can’t live with it, but we also don’t want to allow so much that malicious devices work in common configurations. It’s already risky enough allowing keyboards and mice to be attached after bootup, since if the only keyboard and mouse present on bootup is non-USB (as is the case with most laptops if you don’t plug additional devices into them), keystroke injection devices that present themselves as only a keyboard will be able to attack the system and succeed. But blocking everything other than keyboards, mice, and storage devices may be overkill also.

Does anyone have input on what should be blocked or not blocked by default? Some USB devices to think about here are:

  • Webcams
    • On its own, a webcam probably can’t cause too much trouble… the worst it could do is video the user on the user’s own machine, it would probably be much more useful for an attacker to record the user with an attacker-controlled machine, which of course USBGuard can’t do anything about.
  • Microphones
    • Similar situation as webcams.
  • Headsets/speakers/miscellaneous other USB audio devices
    • Similar situation as webcams.
  • Printers
  • MIDI interfaces
    • Probably pretty rare, no idea what the risks are of allowing these to be used by default, would probably block them just in case.
  • Touchscreens
    • Input device, similar to a mouse, might even be handled already by allowing mice in the system. Dangers are similar or identical to allowing mice.
  • Android devices
    • Uses or at least used to use Media Transfer Protocol. Unsure what the risks are here.
  • USB Ethernet
  • Bluetooth dongles
    • Could be used to attach arbitrary devices to systems remotely, but this would require some user interaction. Unsure what the implications of a malicious Bluetooth dongle would be. Internal Bluetooth cards actually use the USB bus, but they’ll be present on boot and thus allowed, if everything works as expected.
  • 2FA keys
    • I believe these present themselves as a human interface device, not sure how safe or unsafe this is or if it’s feasible to allow it by default.
  • Anything else we should consider allowing or not allowing by default?
3 Likes
2
2 Likes
3

If it were me, I wouldn’t have given this a second thought. If security requires disabling so much, then it is what it is.

Good to have.

Old bs stuff e.g:

  • USB to VGA?
  • USB joysticks?
  • Consider to allow only 3 and above USB version?
4

related:

5

should be blocked or not blocked by default?

Webcams

https://thehackernews.com/2025/08/linux-based-lenovo-webcams-flaw-can-be.html

Microphones

Same as webcams they can be used to record passwords and text via acoustic keyboard eavesdropping with tools like Keytap2. The best thing if someone was concerned would be to unplug these ribbon cables from their computer or de-solder them if its a newer (landfill device) where everything is soldered in.

MIDI interfaces

Arduinos can indeed be used as MIDI interfaces and are used in hacking peripheral devices

Bluetooth dongles

No brainer here Bluetooth is unsafe

Thing I’m conflicted on here.

USB Ethernet

I don’t get it considering there’s good amount of people that use them to get around Intel ME. Many people including myself would remove the WiFi card and us an external Ethernet USB Adapter as a mitigation technique.

Machines whose AMT version is 6.x (Q57/Q67/C206 chipsets, 2010-2011 (early 2012) Core i3/i5/i7) have ME that can talk only through the NIC that is soldered to the board, no external NIC will ever be visible to the ME.

It’s even debatable if it can communicate on newer device through an adapter in my opinion.

Not to mention people that only want wired many newer (landfill devices) computers require you to buy an USB adapter since they don’t seem to have them on boards anymore (laptops).

On the other hand external peripheral devices are generally no allowed by organizations and corporate companies due to attack vector with the exceptions of mouse and keyboard. Malicious USB ethernet devices exist but the general rule of thumb in this manner is don’t buy online and only buy locally from a trusted vendor (brand). Supply chain attack is a real threat but atleast is wouldn’t be targeted to you specifically unlike buying online.

1 Like
6

Allow us to chose just like with the web browsers.

2 Likes
7

I’m not really concerned about this because:

  • You have to compromise the system to overwrite the camera’s firmware and turn it malicious. By the time you’ve compromised the system enough to do that, it’s already “game over”.
  • The camera has to present itself as a keyboard device in order to attack the system. If the camera is plugged into the system after boot, USBGuard will see one of two things, depending on how the camera presents itself:
    • Either, it will see a camera and a keyboard together, and will thus reject the camera because it combines a human interface device with some other device.
    • Or, it will see just a keyboard, in which case if the user has any other USB keyboard already attached, it will reject the keyboard. (If the user doesn’t have a USB keyboard already attached, then it’s “game over”, but if the camera is only presenting itself as a keyboard and not as a camera, it would be able to evade even the current highly strict settings.
  • If the camera is already plugged into the system at bootup, then it’s “game over”, but again, that would be the case even with the current highly strict settings, and if an attacker is able to compromise a system enough to flash a camera with non-standard firmware, they can probably also control USBGuard and allow the camera to be used so it can be attacked.
    • A counter-argument to this is that USBGuard makes an attacker have to take one more step to attack the camera (maybe - does this exploit work even if the system rejects the camera? It probably doesn’t…), and that one more step may be enough to thwart an attacker that doesn’t know they need to take that step.

I’m not sure how I see how this applies to the threat model USBGuard is intended to help with - Keytap-style attacks require either compromising the user’s computer (in which case, why bother with Keytap, just install a keylogger and be done), or requires the attacker to be able to place their own microphone physically close to the victim (in which case the victim’s computer isn’t the one the microphone is plugged into).

I don’t really understand how that would work but it sounds neat, maybe you can share a link?

I don’t think it’s quite that cut-and-dried, but I agree in general that individual Bluetooth devices can have questionable security (as is true with wireless devices in general sadly) and I would not rely on them in a high-risk situation. That being said, I personally use a Bluetooth mouse and keyboard with my workstation, but I also don’t have a threat model that includes nearby skilled attackers with radio equipment.

I’m not referencing the idea of USB Ethernet in general when calling it very high-risk, though I do consider it a risk as I’ll explain in a bit. The main problem with USB Ethernet is the implementation - RNDIS (which is used for most Android USB tethering sadly) reportedly has serious protocol-level vulnerabilities, so bad that the kernel maintainer who is arguably second-in-command to Linux Torvalds has tried to remove support for the protocol from Linux entirely, three times. He hasn’t shared what the vulnerabilities are yet, but I think he probably knows what he’s talking about and wouldn’t try to do this if the protocol wasn’t legitimately unsafe. There are other USB Ethernet protocols besides RNDIS, I don’t have as much of a problem with the protocols there.

RNDIS aside, one could argue that if a device presented itself as something normal and a USB Ethernet device, that could be used to mount an attack against running services on the system. Assuming Kicksecure has no open ports by default (I wouldn’t expect it to, but haven’t actually checked), this probably isn’t much of a concern, but if someone’s running something like CUPS on their machine, LAN access to the machine could be enough to take it over completely, if one security researcher is to be believed. See the link about CUPS vulnerabilities in the original post. A device could present itself as USB Ethernet to gain LAN access to the machine, assuming the machine automatically connected to the “network” presented by the device (I believe NetworkManager does this by default).

I do not deny the very good usability benefits of USB Ethernet, but I think in general it presents a significant attack vector from the standpoint of USB devices mounting attacks against a system. I’d prefer if we documented how users can manually allow USB Ethernet, instead of allowing it in general.

This brings up a potential hardening idea I’ll save for another post, it might be possible to mitigate this risk such that we can allow USB Ethernet by default. (Edit: I filed the post, for those who are interested: NetworkManager: Disable automatic connection to wired networks?

Keep in mind that one threat vector we have to be ready for is a device that looks like one thing to the user but presents itself as something else to the computer. For instance, a malicious pair of USB headphones may present itself to the computer as a USB Ethernet device as well as a USB audio device. Sometimes the malicious device will be one an attacker walks by and plugs in, so the user’s choice of what to buy may not protect them, and the user’s understanding of what they’re plugging into their system may be wrong.

2 Likes
8

Agreed. If users can’t choose what to use or not use on their own systems, something is badly wrong. We’re discussing what to allow or disallow by default, the user will have free reign to override the defaults however they want.

2 Likes
9

This requires third-party kernel drivers (DisplayLink), so it would be a pain to get this sort of thing to work anyway. I don’t see a problem with leaving this disabled by default.

Agreed, leave disabled by default.

Not sure if this even can be done with USBGuard, but it’s an interesting question to think about. USB 2, as I understand it, simulcasts data packets to all USB 2 ports on the system, then expects devices to ignore packets that aren’t addressed to them. This allows passively stealing data from the system by logging packets that weren’t addressed to the logging device. USB 3 only sends data to the individual devices it is intended for, thus this potentially reduces risk a bit. But at the same time, lots of devices are USB 2 only (I don’t think I’ve seen a USB 3 keyboard in my life), so this would probably break way too much. If we were to offer it, it should be something that is opt-in, not opt-out, in my opinion.

2 Likes
10

Ok, so I wanted to chime in on this discussion. I saw this and it made me do some digging into this.
Is this correct for the classifications?

Defined Class Codes | USB-IF

    USB‑IF class  0xEF (Miscellaneous)
    Subclass    0x04 (RNDIS)
    Protocol    0x01 (RNDIS‑over‑Ethernet)

If so is this format correct and would it only block RNDIS based devices such as Ethernet USB adapters?

# Block any USB device that advertises the RNDIS Ethernet interface
reject with-interface-type 0xef:04:01

Or would you need a wildcard if the device has its interface not as interface #0 or presents the class/subclass further down the descriptor?
reject interface all-of { 0xef 0x04 0x01 }

How common is RNDIS for USB‑Ethernet adapters?

Wikipedia states RNDIS is “a Microsoft proprietary protocol used mostly on top of USB”. What I also read is that inexpensive adapters sold for Windows PCs expose the RNDIS class because Windows already includes a built‑in RNDIS driver, making the device “plug and play”.

Well does that mean that adapters aimed at cross‑platform use (Linux/macOS, embedded boards, Android) often implement CDC‑ECM or vendor‑specific classes instead of RNDIS?
Is it safe to say that the standard is CDC‑ECM in most Ethernet USB adapters rather then RDNIS?

https://old.reddit.com/r/embedded/comments/aeqxbl/which_usbethernet_standard_should_i_implement/edrrd03/

However I also read this though from 2023 so I dont know?

Why Android can't use CDC Ethernet

You would need see what the standard that is found commonly on the market? My guess is in cheap Chinese brands or adapters use RDNIS?

1 Like
11

Couldn’t you just harden CUPS to disable remote printing and turn off printer sharing among other hardening or you talking the CUPS service in general?

12

That looks correct to me at first glance.

I don’t think the 0x at the start of 0xef is correct, and with-interface-type should just be with-interface according to Rule Language | USBGuard. You’d probably want:

reject with-interface ef:04:01

Or, better yet since RNDIS in general is dangerous I believe:

reject with-interface ef:04:*

(Or should that be reject with-interface one-of { ef:04:* }? The documentation doesn’t make it entirely clear to me…)

I have no idea. I know Linux has supported RNDIS for a while and that every Android device I’ve ever tethered to uses it for USB Ethernet.

This is about using USB Ethernet adapters on Android. I’m talking about Android phones presenting themselves as Ethernet devices to laptops (this weird-sounding feature is called USB tethering). That’s what uses RNDIS all the times I’ve seen.

Hardening CUPS might be possible, but I don’t know how much I trust it. I linked an article by a security research about CUPS above, he has an extremely low opinion of it, and given that he just woke up one day, decided to hunt for a CVE in CUPS, and was rewarded with a severity 9.9 CVE after a couple days of research, I’d argue his opinion is probably well-supported.

13

I am not sure this is something we can address in context of the threat model of USBGuard.

It is not an issue specific to webcams. We need to read the original source, not the news report. From the original report…

Quote BadCam: Turning Linux Webcams Into BadUSB Attack Tools - Eclypsium | Supply Chain Security for the Modern Enterprise

  • Two attack paths are possible: 1) An attacker can send someone a backdoored webcam (or, with physical access, attach a weaponized webcam to a computer) or 2) remotely compromise a computer and infect the Linux-based webcam to perform attacks.

There is nothing very specific about webcams in this report. Yes, it happened with a webcam. But it could also been a different class of devices.

For instance, the firmware of a hard drive has also been compromised. See Hard Drive Firmware Trojan.

eclypsium is providing a nice illustrative image badcam-diagram.png. Their first step starts with “initial compromise”.

attacker gains remote access to victim’s PC through phising, malware or software exploit

They then discover a vulnerable device, that supports firmware update but does not verify firmware signature (webcam) and then starts abusing that device.

The threat model of USBGuard is a different one: The PC is not compromised and an attacker attaches a malicious USB device such as a USB Rubber Ducky.

Bluetooth Hardening

1 Like
14

Keyboard with USB 3.0: search Kensington K72357FR. But yeah would be nice to have the ability to disable old/backward compatibility as an option for the users.

15

Some discussion here:

16

Disabled USB joysticks?

That would be good to to promote nofap among Kicksecure users lol

Joking aside I think Kicksecure should reject USB Webcams honestly and agree with @desi_fubu in relation to Keytap2. While also realistically agreeing with what @arraybolt3 about how if they want to get your keystrokes an attacker would try to go with installing a software keylogger on your system as it’s less work. However since AI is becoming more and more relevant I can see Keytap2 based malware or attacks as a probability in the future.

The only thing is modeprobe also doesn’t disable the driver uvcvideo so if you were to you need to un comment that part in the conf also.

I really like the addition of USBGuard I think it will bolster and draw more users in to Kicksecure.

While the current rules look like they will broadly cover rejecting device with HID interfaces. Would it be good to block specific vendor ids that are used for such products like rubber ducky and other hacker sold products?

https://forums.hak5.org/topic/16696-version-1-usb-vendor-idproduct-id/

USB vendor ID that OpenMoko released (0x1D50) has become a popular building HID keyboard emulator style rubber ducky projects:

Another one that comes up is the vendor Amtel when it comes to “Rubber Ducky” type clones.

1 Like
17

Not trying to get off topic but rndis is kernel driver:

find /lib/modules/$(uname -r) -type f -name '*.ko*' | grep -E 'rndis'

/lib/modules/6.1.0-38-amd64/kernel/drivers/net/usb/rndis_host.ko
/lib/modules/6.1.0-38-amd64/kernel/drivers/net/wireless/rndis_wlan.ko
/lib/modules/6.1.0-38-amd64/kernel/drivers/usb/gadget/function/usb_f_rndis.ko

On the topic of USB WiFI (rndis_wlan) I want to put in my voice here I dont think we should block USB WiFi adapters only USB WiFi devices with HID if that’s possible.
I dont know of Adapters that use rndis_wlan and think it would have to look into this like @NTH9R6 mentioned like USB Ethernet adapters on whats common on the market.

2 Likes
18

Android devices should be blocked by default

An attacker can manipulate filenames or directory paths sent over MTP to read or write files outside the intended media storage area.
Flaws in the MTP driver’s handling of buffers can lead to crashes or remote code execution if crafted packets trigger invalid memory accesses.
On systems where the MTP service runs with elevated rights, exploiting a driver bug may allow an attacker to gain higher privileges.
Improper validation of MTP commands can expose private media or metadata to a malicious host.

For easy usability and user choice I think a USBGuard element/button part on the sysmaint panel should open the 30_security-misc.conf in nano so users can comment or un comment out what they need.

Consider to allow only 3 and above USB version?

This is too restrictive and blocking USB 2.0 only devices does not eliminate DMA or the BadUSB exploits. It would simply break a heap of legacy peripherals while giving a false sense of security.
Best defense is allow listing devices by vid/pid (as rejecting devices that have HID), enabled IOMMU enforcement and disabling autorun/auto-mount features which I believe Kicksecure already does right?

Blocking USB 2.0 devices for security is impractical due to their widespread use, despite potential security risks.
USB 3.0 does reduce passive sniffing but both USB 2.0 and USB 3.0 can be used for BadUSB, or DMA based memory corruption.

2 Likes
19

Occasionally do use my printer myself to print sometimes but I wouldn’t mind if you rejected printers (class 0x07) with reject with-interface 07 by default.

Looking at that both reject with-interface interface-type="07" or reject with-interface 07 syntax’s seem to be correct but I would stick with whatever matches the style of the rest of your USBGuard policy so in this case reject with-interface 07

Also USB A-to-B or USB C-to-B “printer cables” that come with or in my case had to buy to plug into the the “printer port” (USB B) and into my PC via (USB A) would not be able to bypass this rule correct?

Would or could some printers come up as Mass Storage Class (0x08) or Communication and CDC Class (0x02 or 0x0A) and bypass it?

HP Printers and scanners:

Epson Printers and scanners:

Two other common vendors are Cannon and Brother when it comes to printers and scanners.

1 Like
20

That spooks me a bit. Atmel is a reputable microcontroller production company, do we want to block every keyboard or mouse that uses their controllers? I wouldn’t expect so. The Hak5 rubber ducky presents itself as an Atmel device by default (according to information from https://forums.hak5.org/topic/25510-question-vendor-id-and-product-id-of-the-duck/ and All USB Vendors | Device Hunt anyway), but a lot of other devices might do the same.

Also, bear in mind that the vendor ID and product ID of the Rubber Ducky can be changed by the attacker according to ducky-decode-wiki/Guide_Change_USB_VID_PID.wiki at master · cypher2048/ducky-decode-wiki · GitHub, so at best, vendor ID rejection would only protect against attackers who didn’t really know what they were doing. I’m sure there’s a lot of those kinds of attackers out there, but I don’t really the benefits outweigh the costs here.

If we don’t block that already in security-misc, we really should. We have modprobe config for disabling things…

Yeah, that’s the sort of thing I was afraid of. Then I think probably leaving MTP off is better.

Hmm, I like that idea!

It shouldn’t, at the end of the day the cable isn’t anything more than an electrical connector that gets four (or nine, in the case of USB 3) pins from the device attached to your computer. Unless the cable is itself malicious (which is a thing), it shouldn’t present any extra danger as opposed to usual USB devices. Of course, if you were unlucky enough to use one of these then there would be a problem, but USBGuard should protect you in that instance, again, assuming you have a normal USB keyboard already connected and the cable wasn’t plugged in at boot time.

I don’t know enough about how the USB protocol works under the hood to give a definitive answer there. I would hope the USB protocol isn’t so poorly designed as to allow a flash drive to call itself a flash drive but then act like a printer (which is the kind of think that would be enabled if a printer could still work as a printer even if it called itself a flash drive).

2 Likes