USB device registration

[rikona]

On Mon, 31 Jan 2022 15:12:19 -0600
Keith <keith at caramail.com> wrote:

> On 1/31/22 2:00 PM, rikona wrote:
> > On Sun, 30 Jan 2022 13:43:49 -0600
> > Keith <keith at caramail.com> wrote:
> >  
> >> On 1/30/22 12:28 AM, rikona wrote:
> >>
> >> [snip]
> >>  
> >>>
> >>> 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.
> >>>  
> >>
> >> 1. Plug any untrusted usb devices into an air-gapped system and
> >> monitor the logs for any unusual behavior, i.e. a storage device
> >> identifying itself as a keyboard.
> >>
> >> 2. Install the usbguard package
> >>
> >> "The USBGuard software framework helps to protect your computer
> >> against rogue USB devices (a.k.a. BadUSB) by implementing basic
> >> whitelisting and blacklisting capabilities based on device
> >> attributes."
> >>
> >> https://usbguard.github.io/  
> >
> > Thank you!! That software looks like just what is needed.
> >
> > Re the 1,2 order above, AIUI BadUSB and others install on the comp
> > and try to infect any USB devices connected later. Would #1 really
> > require a 'throw away' comp to look at the device? Right now #1 is
> > my main box and no spares. That's why I was thinking of a virtual
> > machine originally.
> >
> > Would it be better to do #2 first, then #1? It looks like USBGuard
> > can look at the device info without allowing the device to register.
> >
> > Thanks again,
> > Rik
> >
> >  
> 
> The air-gapped system is just an added layer of protection to keep
> your main system safe. You could repurpose some old hardware, or
> invest in a low cost raspberry pi system running Ubuntu and usbguard.
> If the usb key doesn't cause a problem on the air-gapped machine its
> probably safe for your main system.

I agree - a good suggestion. But, I donated all my extra hardware to
someone who refurbishes it for low-income kids, so I don't have
anything I can use for that. I've considered the pi a number of times,
for various purposes - maybe it's time to go down that road. :-) IIRC
there is an easy way to completely clean a system and restore it to a
'new' system, but I don't remember how to do that. That might be a good
way to get a 'throw away' system for testing with the pi.

> Whether you use a test system or not, usbguard can be used to set
> whitelist and/or blacklist policies that can specify what type of
> device can be used on specific port. So if you have a usb keyboard in
> port 1, you would craft a policy that only port 1 will allow usb
> keyboard devices. Plugging a keyboard device into any other usb port
> will fail. So any badusb key that tries to register itself as a
> keyboard will fail since only port 1 allows keyboards and your
> keyboard is already in port 1. This action alone defeats the more
> popular attacks by badusb.

That's what I  was thinking about doing in my main box *before* plugging
in the other USBs.

Thanks again for the suggestions - much appreciated.