Mischievous Mice

I have a number of wireless dongles that I use only with wireless mice. Many vendors use the same dongle chip for both keyboards and mice, and even though I purchased only "mouse dongle" sets, keyboard commands can still be sent to them. These devices run at 2.4 GHz, and are likely unencrypted.

Quite a few receiver dongles have been found to be susceptible to mouse-jacking by an interloper, where packets are sent to the receiver dongle from the interloper but coded as "keyboard" packets instead of mouse packets. This has been shown to allow for the injection of keystrokes, and was a big story in the news about eight months ago. I'd hate to throw these mice away and go back to the messy wired mice.

Does anyone know of a way to mitigate the problem by using some kind of fix on the operating system side of things, since the dongles themselves cannot be fixed?
 
I used the usbhid-dump utility on Linux (also available on FreeBSD as sysutils/usbhid-dump). On Linux, I did:

Code:
       # Get the vendor:product number of receiver, and iface number of keyboard:
       lsusb -v

       # Use usbhid-dump to exclusively grab keyboard interface (xxxx hides real info):
       usbhid-dump -t 0 -d xxxx:xxxx -i 1 -es

-
The usbhid-dump utility on Linux detaches kernel drivers from the interfaces it dumps, exclusively, so that other programs cannot use them, and cannot receive input from the device. If FreeBSD also does this with its sysutils/usbhid-dump, then maybe this could be a sort of crappy mitigation**. I can't say for sure that it would stop mouse jacking, and I'm certainly no FreeBSD USB stack expert ***.

** Edit: see devd/devfs ideas (below).
*** Second edit: this probably wouldn't work anyway (see HID related post, below).
 
Last edited:
Quite a few receiver dongles have been found to be susceptible to mouse-jacking by an interloper, where packets are sent to the receiver dongle from the interloper but coded as "keyboard" packets instead of mouse packets. This has been shown to allow for the injection of keystrokes, and was a big story in the news about eight months ago. I'd hate to throw these mice away and go back to the messy wired mice.

What is the range of the 2.4 GHz wireless used here? How far away does your nearest neighbor live? How well do the walls of your house or apartment shield wireless traffic? You may not need to do anything at all; the hardware may just protect you.

Obviously that doesn't work if you take your laptop to the library or some place like that.

For a software solution: I think your first step should be to learn about how USB handles mice and keyboards. I'd start with Wikipedia, and then try to download the USB specification. Armed with that knowledge, I'd start reading the source code for the USB layer in FreeBSD . There may be a place there where you can "filter" or "block" the keyboard part of the traffic.
 
What is the range of the 2.4 GHz wireless used here? How far away does your nearest neighbor live? How well do the walls of your house or apartment shield wireless traffic? You may not need to do anything at all; the hardware may just protect you.

One day I was using my computer (not saying where I lived at the time) and it had no internet connection (wire pulled). I left the terminal for a bit to grab a coffee. When I came back someone (not me) was typing pings into my terminal window, trying to factor out the layout of my subnet.

Obviously that doesn't work if you take your laptop to the library or some place like that.

Yes

For a software solution: I think your first step should be to learn about how USB handles mice and keyboards. I'd start with Wikipedia, and then try to download the USB specification. Armed with that knowledge, I'd start reading the source code for the USB layer in FreeBSD . There may be a place there where you can "filter" or "block" the keyboard part of the traffic.

I know enough about the USB stuff to know that it's more than I want to know. It's extremely complicated. To be an expert knowledgeable to the level of device driver writing is what it would take for a driver level fix for this. I definitely ain't interested in going that route ATM. I spent all my years doing userland code, and that was enuf.

That's why I elected to try this already existing program as a blocking utility, but now that I think about it more, it probably isn't sufficient.
 
  1. If you have a lot of free time you might be able to hack together your own solution. Plug a usb mouse into a Raspberry Pi and forward commands out through some sort of IR emitter. From this you can then do something fancy like encode a special protocol that only your Raspberry Pi and modified mouse driver knows. I.e every tenth mouse event needs to be at 0,0 which then gets ignored. An arduino would be a lighter solution but perhaps quite a bit trickier.
  2. Bluetooth mouse with a correct pairing (if you trust bluetooth) might be the better option. Although it is a faff and I don't know how great FreeBSD support is for it. I know on OpenBSD it is non-existant.
  3. Other than that, when you leave your terminal, just lock it. Then they still need a password to do any damage. Or just disable moused and Ctrl-Alt-F1. The mouse will only work again when you jump back to X11.
Feel free to take your pick out of any of my terrible solutions haha :)
 
  1. If you have a lot of free time you might be able to hack together your own solution. Plug a usb mouse into a Raspberry Pi and forward commands out through some sort of IR emitter. From this you can then do something fancy like encode a special protocol that only your Raspberry Pi and modified mouse driver knows. I.e every tenth mouse event needs to be at 0,0 which then gets ignored. An arduino would be a lighter solution but perhaps quite a bit trickier.
  2. Bluetooth mouse with a correct pairing (if you trust bluetooth) might be the better option. Although it is a faff and I don't know how great FreeBSD support is for it. I know on OpenBSD it is non-existant.
  3. Other than that, when you leave your terminal, just lock it. Then they still need a password to do any damage. Or just disable moused and Ctrl-Alt-F1. The mouse will only work again when you jump back to X11.
Feel free to take your pick out of any of my terrible solutions haha :)

Well, I won't take anything off the table yet! I'm thinking my sysutils/usbhid-dump idea is ridiculously kludgy, even supposing it worked. For a simpler, more reasonable approach, it seems that maybe I could just add some configuration into devd.conf for this:

Code:
  match "vendor" "0xabcd";
  match "product" 0xabcd";
  action "???"

I'm not sure what the action should be, since ...

When the dongle is inserted, it produces device files for both the keyboard and the mouse, because the single RF receiver chip in the dongle services both (even though I only purchased a mouse, the dongle is keyboard capable). I'd want to disable only the keyboard (since I do use the mouse). Is there some way to specify the device interface number in devd.conf?
 
Last edited:
One day I was using my computer (not saying where I lived at the time) and it had no internet connection (wire pulled). I left the terminal for a bit to grab a coffee. When I came back someone (not me) was typing pings into my terminal window, trying to factor out the layout of my subnet.
.


This is really an interesting story ! thank you for sharing it.
 
This is really an interesting story ! thank you for sharing it.

It's my assumption they were trying to ping out to the internet (to their own machine, or a bot). But, it could have been someone innocently using their own keyboard on their own device, and hitting mine at the same time by accident. Let's give them a benefit of a doubt, even though I don't see how my give-benefit/optimist version could have worked successfully.

Some of these non-bluetooth devices are really not safe IMO - even if they're "supposedly" only connected to a mouse. Some manufacturers may be good or better, and some bad, but it seems the all-in-one-ness of the dongles could be a less secure approach to things. Since the USB ports & drivers are themselves pretty agnostic about non-bluetooth keyboards and mice, no security happens on the USB port side of the equation, and it all has to happen between the dongle and the remote mouse or keyboard or other device. If the manufacturer doesn't take care of it - look out.

I don't think we can do much on the OS side other than try to disable the things we aren't using, in my case the keyboard.
 
the story is more fascinating with the "ping my network" part ;)
it could be a good the starting point for a sci-fi short story, Philip K. Dick style.

PKD = "Imaginative prose in a difficult writing style," according to some. But, lame keyboard hack tricks wouldn't be good enough for Bladerunner or Total Recall. That stuff is too much an everyday thing now.

So, getting back to fixing this thing: In /etc/devd.conf, I could have:

Code:
      attach 20 {
      match "system" "USB";
      match "device-name" "ukbd[0-9]";
      match "subsystem" "DEVICE";
      match "type" "ATTACH";
      match "interface" "0x01";
      match "vendor" "0xabcd";
      match "product" "0xdcba";
      action "???"
      };

So, what's the best action to disable interface 0x01 of the receiver dongle (0x00 is mouse, 0x01 is keyboard) for everyone including root? Should I use "/etc/rc.d/syscons setkeyboard" and change the target device? Is it enough to simply remove the specific device config lines in the default devd.conf, or replace them with something specific to my wired USB keyboard? I don't mess with devd and devfs very often** .

**Edit: It looks like none of this will work (see related posts, below).
 
Last edited:
Eventually it uses kbdcontrol(1).
However, I'm doubting this effects Xorg stuff.

It never occured to me that an off-the-shelf wireless mouse would accept keyboard input from keyboards I didn't have and which weren't included in the package! It seems that *especially* with some of the (shall we say "inexpensive") imports, the receiver dongle is little more than a relay for the input devices, shoving whatever packets there are blindly into the USB port. I don't have a FreeBSD machine at the moment, to test some devd configs, so just speculating ...

For those wanting to know if they have affected devices, here's a list:

https://www.bastille.net/research/vulnerabilities/mousejack/affected-devices/

The list is not entirely complete IMO - since there are many cheapo no-name mice.
 
This comment is appended to the devd comments (from above).

It looks like both interfaces (interface 0=mouse, interface 1=keyboard) are handled by the the same USB HID driver, which relays packets up to the higher level input drivers (mouse/keyboard). Unfortunately, it seems that the HID drivers on some operating systems do not check the size of the packets, nor whether their attributes make sense for the interface indicated by the device descriptor, which can make various attacks possible. Mouse-jacking is not necessarily a HID attack from what I gather.

Some receiver dongles enumerate two interfaces, even when the package purchased is "mouse only." One of the interfaces on such a dongle indicates a keyboard and the other a mouse. The mouse-to-dongle traffic is usually not encrypted, so is easy vector. According to the previously listed source - by crafting special packets, an attacker pretending to be a mouse can send keystrokes to the dongle, which accepts them because there's no mouse encryption. Because of a mess-up (I don't know this - I am just repeating what I read here) in the dongle, it sends the received keystroke packet with keyboard interface assignment, and the computer accepts it.

The latter hack doesn't really seem to be what I'd call a HID problem. So - maybe that subset of mouse-jack causes could be mitigated by the technique I started to use (above). But, I'm not inclined to do that, as I'm not 100 percent sure of the veracity anything in this whole thread ...

I did find a way to stop enumeration on selected ports (but it's all or nothing and doesn't help:


[COLOR=rgb(65, 168, 95)]sysctl values:
hw.usb.disable_enumeration: 1
dev.uhub.0.disable_enumeration: 1
dev.uhub.1.disable_enumeration: 1[/COLOR]



I don't know if those sysctl values work as advertised, but even if they do work it seems they do not fix the problem: which by now has been changed to throwing the wireless mice in the trash and buying new mice.

I *totally* misunderstood the nature of this exploit. If someone verifies this line of thought even partially, I'll mark the thread solved, and go to the shopping mall looking for WIRED mice.
 
If someone verifies this, I'll mark the thread solved, and go to the shopping mall looking for WIRED mice.

I recently purchased a USB MicroSoft Optical Trackball mouse on ebay for $35 and felt lucky to get it. (I mean they only want $599 plus shipping for one on newegg. :p ) It's the second one I own, they originally came out in '98, and this one works and looks like it just came out of the box. The one I have from '98 is the same way. It's by far the best thing MS ever made IMO.

I don't use wireless for anything, too many neighbors.
 
I don't use wireless for anything, too many neighbors.

Thanks for the shopping tip, but I think I'll need to dent the bank account a little less than that! The more I discover about anything wireless, the more I'm in agreement with what you wrote. We recently had the WPA2 debacle, and it goes on and on. One or more of the mouse vendors have announced MS Windows patches for their mice. If what I wrote (above) is true, then I wonder how a vendor supplied patch could fix them. This is already 1.5 year old news in the lay press, but I'd suppose USB gurus have known about it forever. I saw some mailing-list posts about people wrestling with the issue in 2012. I guess when I originally saw the lay press article, I thought it really had to do with mice, so took a "who cares?" stance.
 
Sorry that I can not help you with your problem other than repeating "cable" but... is it only me or who else thought of Pinky&Brain when reading the thread title?
 
Thanks for the shopping tip, but I think I'll need to dent the bank account a little less than that!.

They're nice, not $599 nice, but nice.

They have ceramic bearings that hold the trackball and lets it rotate with minimal friction. I've probably dropped mine 100 times, the trackball pops out, I wipe it off, push it back in and continue using it. You don't have to move it around and get precision control for things like pixel art.

I have a Razer DeathAdder gaming mouse and much prefer my Trackball.
 
To combat the sore wrist, I use a graphics tablet. Maybe that is also worth thinking of?

Edit: you may know the RC sets which came up in the last years for model planes using 2.4GHz. The ones from one of the bigger brands use the same chips as your average BT mouse does, so range might be around a km with proper equipment on the other side.
 
Most of the mouse-jacking detail that I see on the internet seems more about dongle deficiencies than HID deficiencies. But since I've opened the HID can already ...

Random internet quote for HID: "HID class devices simplify USB by using a flexible driver that is available on all operating systems." I guess the "flexible" part is what get's us in trouble. Flexible often does not jive with security. I'm no USB guru but like I already wrote - I know enough to know I don't want to deal with it, except thru somebody else's abstraction libs. It seems there are too many ways to do things. For instance, a two HID device (i.e. mouse + keyboard) can be done two different ways:

1 - As a "top level collection" with one interface and two report descriptor IDs.
2 - With two separate interfaces.


In either case, the OS drivers create two separate devices from the operating system's perspective. Pipes are established to the endpoints associated (with the interface or collection). Report descriptors themselves are very vendor mangle-able, lengthy and IMO have redundant parts. In addition to report descriptors, there are device, configuration, interface, endpoint, and hid descriptors. See this document for a glimpse:

https://www.silabs.com/documents/public/application-notes/AN249.pdf

There are alleged exploit possibilities that use bogus firmware in wired USB devices to attack the host it's plugged into, by exploiting the HID's "flexibility". In spite of this, I think the direct cable connection is the way to go with USB. It's less "flexible" than wireless, but let's me worry more about the latest ported app I want to run on FreeBSD than other less attractive things :)

I also found this article quite informative:

https://cise.ufl.edu/~butler/pubs/acsac15.pdf

The thread's been a convenient excuse for me to "read up" on USB. Anyway, I guess I'll supply my own best answer for it, which is "If one day you see that someone else is typing stuff into your keyboard, and you don't believe in the invisible man, get the wired USB devices." Yes - the manufacturers are much more careful now (or I'd hope that they are), but no kind of mitigation is going to cover all the manufacturers different security setups (or lack thereof).
 
uhidd and moused can coexist - even on the same device. I was looking at having uhidd grab the unused keyboard interface but can't figure out how to tell uhidd to not pass the events through. Alas, this won't prevent broken USB wireless receivers from passing key events over the mouse interface.
 
uhidd and moused can coexist - even on the same device. I was looking at having uhidd grab the unused keyboard interface but can't figure out how to tell uhidd to not pass the events through. Alas, this won't prevent broken USB wireless receivers from passing key events over the mouse interface.

Right. Many of these wireless mice dongles - don't really have (only) receivers in them. They have transceivers (i.e. a transmitter & receiver combination) - which can (potentially) enable the return of acks, resends, etc as part of the normal protocol (which may or may not be used in all devices - I don't know that). Normally, a HID device is for input, so I'm not sure under what circumstances this would be a concern for misuse. I'd guess it'd take a number of things happening, including a pretty egregious boo-boo in the firmware to work. So it's probably not really a concern for anybody, but who ever really knows that or can say it with certainty? Somewhere in the world a mind is working on it.
 
Back
Top