USB device registration

[rikona]

On Sun, 30 Jan 2022 05:08:16 +0100
Ralf Mardorf via ubuntu-users <ubuntu-users at lists.ubuntu.com> wrote:

> On Sun, 30 Jan 2022 04:51:24 +0100, Ralf Mardorf wrote:
> >On Sun, 30 Jan 2022 03:48:21 +0100, Ralf Mardorf wrote:  
> >>While a faked HID devices can work cross-platform, somebody needs
> >>to prepare the hardware. Examples on how to do this kind of attacks
> >>are shown by using USB development boards. I suspect that it's
> >>virtually impossible to reprogram a connected USB data storage
> >>device by malware, to fake a keyboard and than to do nasty things
> >>beyond a fork bomb.    
> >
> >"HID (Human Interface Device) spoofing: HID spoofing keys use
> >specialized hardware to fool a computer into believing that the USB
> >key is a keyboard. This fake keyboard injects keystrokes as soon as
> >the device is plugged into the computer. The keystrokes are a set of
> >commands that compromise the victims computer. As we will see later
> >in the post (spoiler alert!), with a bit of work and ingenuity, we
> >will create a HID device that spawns a reverse TCP shell that will
> >give us full remote control over the victims computer." -
> >https://elie.net/blog/security/what-are-malicious-usb-keys-and-how-to-create-a-realistic-one/
> >
> >tl;dr it seems to be possible to get remote access by a TCP
> >connection. Since I didn't read it yet (I'll read it later), I
> >wonder how to get access to a shell in the first place, either to
> >just launch a fork bomb or to go beyond it and get remote access.
> >However, it likely requires to prepare hardware manually. Replacing
> >firmware might be possible for some USB devices, but I suspect that
> >there's no way at all to replace the firmware of the majority of USB
> >devices.  
> 
> On my machines Ctrl+Alt+T usually opens a terminal emulation with user
> privileges. So it would be possible to run a fork bomb and probably to
> do this TCP magic, too, but with user privileges only.
> 
> All this requires to be visually as well as haptically impaired in the
> first place: 
> 
> https://elie.net/static/images/images/what-are-malicious-usb-keys-and-how-to-create-a-realistic-one/usb_key_failed_due_to_lubricant.960.webp
> 
> Even this one isn't that perfect, the USB jack of the original key is
> in the middle, the one of the faked key isn't:
> 
> https://elie.net/static/images/images/what-are-malicious-usb-keys-and-how-to-create-a-realistic-one/teensy_sucessfully_consealed_as_USB.960.webp

Thanks much for the reply. I installed hwinfo and can see the device(s).
I'm familiar with how the exploit works, which is why I asked how to see
it. And it does work immediately, unfortunately. Tricky to avoid this.
I have a real USB keyboard so can't disable that in the comp to avoid
the 'instant' problem. Is there a way to just disable one selected port
on the internal root usb Linux hub on the MB?

Or, is there another way to selectively disable just that USB keyboard
and allow other USB keyboards to work? Or, wild idea - would a virtual
comp/OS shield the hardware box from being infected, or does this run
at a MB level?

BTW - there is S/W that can install this kind of malware on any USB
device, by essentially upgrading the firmware. Easier to do than I
first thought - any good hack could do it. Major potential threat.

Anyway, thanks for the info re how to see it. Now need a way to see it
WITHOUT HAVING IT DO ANYTHING TO A COMP with an operating USB keyboard.

All ideas much appreciated.