Yeah, this is more of a UI problem that could be solved with a little effort. I would be concerned about a device that replaced the hub itself rather than simply adding a function. The core issue is that a system can always notify the user of newly connected devices (Windows seems to about half the time). But a malicious MCU emulating a hub and compromising or stealing data at the USB protocol level could appear exactly as expected. It could key log, inject, etc., undetected because it doesn’t have to interact with kernel drivers as anything other than the expected hub.

On Linux, GNOME has some USB protections when USBGuard is installed.

Macs warn you and require approval for any new USB device, including a keyboard, starting with macOS Venture.

Isn't that only when using lockdown mode?

No, since Ventura I get these dialogs for all USB/Thunderbolt devices that I connect (except chargers I think?):

https://support.apple.com/en-bw/guide/mac-help/mchlf779ae93/...

Unfortunately the dialog doesn't tell you what kind of device it is.

MacOS has a pop up that tries to identify the keyboard layout. If this screen came up when I plugged something in that wasn’t a keyboard, I would assume the device was malicious.

It is probably possible to automate the keystrokes to quickly kill this screen though.

If I were a bad actor with the resources, I would dedicate more engineering effort to making the device subtle. It would try to remain invisible until a mouse/keyboard was plugged into the dock. The interceptor would then read that fingerprint and present that to the host OS, keeping the user unaware of the middleman.

My point is that no matter what you tell the OS, there will still be one more device connected than expected. If you plug in a keyboard and two are suddenly connected, it’s still very noticeable. This counting problem is occurring at the hardware level in the USB hubs and host. The attacker needs to compromise an external hub to behave like a USB protocol analyzer capable of intercepting and modifying data seamlessly in order for an attack like this to be anything other than trivially detectable. Fitting something like that into an existing enclosure means writing lots of low level code and embedded hardware design which is a different level of difficulty.

I was thinking more man-in-the-middle, not a sidecar device. Obviously more technically challenging to accomplish, but far harder to detect.

Sorry, I think I misunderstood your original comment - we’re having the same thought with MITM. Definitely more technically challenging but much harder to detect.

You could insert a device between the actual keyboard and the computer (man in the middle).