# Protecting from BadUSB and Other Trickery

## 229566

I wasn't sure where to post this, under Security or Hardware, but I guess it is more relevant to security.

I got this Gigatech mouse, http://www.giga-tech.eu/products/gigatech-mouse-gm-700/ and it registers as

```

Bus 004 Device 009: ID 1d57:0005 Xenta Wireless Receiver (Keyboard and Mouse)

```

```

[314472.690559] usb 4-2: new full-speed USB device number 8 using ohci-pci

[314472.857564] usb 4-2: New USB device found, idVendor=1d57, idProduct=0005

[314472.857569] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[314472.857572] usb 4-2: Product: HID-compliant Mouse

[314472.857574] usb 4-2: Manufacturer: HID-compliant Mouse

[314472.864432] input: HID-compliant Mouse HID-compliant Mouse as /devices/pci0000:00/0000:00:12.1/usb4/4-2/4-2:1.0/input/input35

[314472.864706] hid-generic 0003:1D57:0005.0008: input,hidraw0: USB HID v1.10 Mouse [HID-compliant Mouse HID-compliant Mouse] on usb-0000:00:12.1-2/input0

```

I tried to google for "Xenta Wireless Receiver" but couldn't find any meaningful results, or even anything security related, so I was wondering... given that things like BadUSB exist... What the hell is this and why is it registered as a wireless receiver? (I guess that's a rhetorical question unless someone has had the same thing).

It is a wired mouse alright, but short of ripping it apart and looking for hidden radio transmitters or receivers inside it, is there any other way I can make sure this really is a wired device that won't become an alien landing beacon overnight while I'm asleep? Or that someone with a know how would not wardrive nearby and look for such devices and do stuff I might never have found out happened, if it really is a wireless thing...

So while I originally wanted to ask about that particular device, I realized this falls under BadUSB category so I guess the real question here is how to protect against BadUSB... Removing modules and compiling drivers directly into the kernel? I'm not sure how that would be helpful given that a device can change its opinion and become something the driver already exists for in the kernel, like a keyboard...

----------

## krinn

It just mean you think the output is taken from the device, while the output is taken base on the device identifier and from a database that match device id with products.

yes, you can nano /usr/share/misc/usb.ids and transform your evil wireless mouse into a black pegasus yourself.

they generally have the right vendor id, because vendor id part is suppose to remain taken by a vendor, but vendor may use material from other vendor and the id remain from that vendor ; so a "zlutk" product could appears as "ganishi" one.

It's of course only worst for the product id itself, as you either need to trust vendor (that may reuse the id for no reason) or trust user that report it.

It's the same for pci.ids if you want to know.

----------

## NeddySeagoon

GrueXYZ,

First off, just because you are paranoid does not mean that they are not out to get you.  :) 

The string "Xenta Wireless Receiver (Keyboard and Mouse)" comes from looking up the Vendor: DeviceID (1d57:0005) in the hwids database.

Every different device should have a unique  Vendor and DeviceID to identify it err uniquely.

Sometimes hwids is wrong, sometimes vendors mess up and issue two or more devices with the same ID. Some are worse that others. 

Google also claims that the ID 1d57:0005 belongs to "OrthoMouse" which is available in both wireless and wired versions..

I was only able to glean that because Google pointed out that they don't work in Linux for everyone.

----------

## 229566

 *krinn wrote:*   

> It just mean you think the output is taken from the device, while the output is taken base on the device identifier and from a database that match device id with products.

 

Ah, yes.... I totally forgot about these names coming from such a database. It is probably even different across distros. This is an Ubuntu box I'm enumerating hardware for before reinstalling Gentoo on it (which is currently emerging packages for the machine in a KVM instance).

 *krinn wrote:*   

> yes, you can nano /usr/share/misc/usb.ids and transform your evil wireless mouse into a black pegasus yourself.

 

True, I just checked it's there alright. BTW, my vim complained that :nano wasn't an editor command...   :Mr. Green: 

 *NeddySeagoon wrote:*   

> First off, just because you are paranoid does not mean that they are not out to get you. 

 

Heh heh, yeah. But in this case it ain't really paranoia (irrational fears). It's quite a rational fear.  (yes I know you didn't mean to suggest otherwise).

Thing is, what can we do to protect against that? Can MAC or RBAC be applied to drivers like that?

The successful malware is not the one banging on your door, but the one sneaking in, laying down and striking from behind the enemy lines when least expected. With things like SOC chips one can unknowingly bring home a weapon of cyberwarfare disguised as a mouse.   :Mr. Green: 

Edit: I forgot to thank you guys for fast replies.

----------

## Ant P.

The kernel actually has some built-in way to authenticate USB devices from what I've heard. However, I have no idea how it's supposed to work and it probably requires manual device manager rule-writing to be usable.

----------

## N8Fear

grsecurity actually has a feature that essentially disables the ability to plug in new usb devices until reboot.

----------

## 229566

 *N8Fear wrote:*   

> grsecurity actually has a feature that essentially disables the ability to plug in new usb devices until reboot.

 

Oh that's awesome. Does that mean this would protect against USB devices changing opinion on what they are after they were plugged in? AFAIK such devices would have to simulate unplugging and plugging back as something else in which case they would be blocked, correct?

----------

## NeddySeagoon

GrueXYZ,

It only allows USB devices to enumerate at boot time.  So if your hardened box breaks, you can't add a USB keyboard to poke at it without a reboot, if the feature is enabled.

For things that take firmware which changes their ID, I don't know what happens.

----------

