MouseJack Hack: Wireless Keyboard & Mouse Lets Bad Guys in the House

  • Keyboard Lock

Serious Vulnerability in Non-Bluetooth Wireless Human Interface Devices (HIDs)


Over the last week, I have been working to better understand the MouseJack hack and how easily it could be exploited. It turns out that this is a very concerning attack. Without purchasing any hardware (mostly because I have several different Logitech keyboards and mice), I was able to re-flash the firmware on a standard Logitech Unifying receiver.

From this point, I was able to see any and every packet sent from a Logitech device in the area. This was not limited to devices hooked up to other unifying receivers, it also included “unpaired” devices. It is important to know that, despite the fact that I could see communications from attached devices and even see the types of devices that were sending signals, I was unable to read keyboard packets in plaintext. Logitech has, for some time, encrypted all communications between their wireless keyboards and receivers. Mouse movements, however, are not encrypted. There’s some fairly good logic behind this choice though – how much information could an attacker get out of mouse movements? They are just x and y coordinates and would not provide any useful information to an attacker. Minimally, they would need to have the exact starting coordinates to ascertain where the mouse was on the screen. Practically, they would have to have a real-time view of what is being displayed on the screen to truly take advantage of this knowledge.

The Attack Itself

There are several practical attacks that can be used against this vulnerability and many of them are quite concerning. Using the modified firmware that was released on Marc Newlin’s GitHub, I was able to quickly and easily flash the firmware on an existing unifying receiver. As I said above, I was able to see and log any communications from the keyboards and mice in my lab/office, but that information was not useful beyond identifying that there were wireless input devices in use. While not taking this beyond the initial research, I was able to prove the simplicity of these types of attacks. For example, I was able to “force pair” any type of Logitech input device to a dongle that connected to only a Logitech mouse.

“Force pairing” allows an attacker to, using the modified Logitech Unified receiver, force any other Logitech type of Human Interface Device (HID) to appear to be connected. This would give the victim system no warning, and as long as the attacker is patient and waits for the victim to walk away, there would be no indication of compromise.

Upon first making contact with a victim system, the first logical step is to either inject false mouse movements (also known as “jiggling” the mouse), or connect an emulated mouse that moves a single pixel back and forth until the user walks away. This will allow the attacker to avoid the screen locking out but will not notify the user as the movements are too small for the human eye to perceive. Once the user has walked away, the damage that can be done is virtually limitless. Any research that can be found from other HID-based attacks (e.g., USB Rubber Ducky, HID Emulation, etc.) can be applied. An emulated keyboard will allow virtually any command or code to be injected into the system. This can range from running a PowerShell attack that inserts malware (e.g., keystroke logging, bot net, etc.) to forcing the system to connect to a command and control (C2) system.

How Could We Possibly Protect Our Systems?

These are the two most important things you can do to protect yourself or your business:

  • Lock your screen whenever you walk away
  • If you use a wireless mouse or keyboard, check with the manufacturer to find out if yours is affected.

Here are a few questions that you and your organization need to ask yourself:

  • Are we aware of who is using non-Bluetooth wireless devices on the organization’s systems?
  • Does the organization’s Acceptable Use Policy (AUP) allow the use of wireless HID?
  • If it does allow their use, should this practice continue?
  • If it does not allow the use of non-BT HIDs, is this enforced? It probably should be.
  • If you want to allow the use of non-BT HIDs, consider the risk and make sure that the executive leadership is also aware.
  • Should wireless HIDs in use be BYOD? Probably not.

It should be noted that Logitech has released an update to the Unifying Firmware. If non-BT HIDs will continue to be used, this update should be enforced across the organization. In addition, if there is a real need for wireless devices to be used on company owned assets, then specific limitations should be placed on what devices are allowed, and they should only by allowed by exception. In a typical office setting, there is rarely a need for wireless HIDs since users are probably sitting less than three feet from their computer.

August 23rd, 2016|

About the Author:

John Nye
John Nye is Senior Director of Cybersecurity Research and Communication for CynergisTek and has spent the majority of the last decade working in Information Security, half that time working exclusively as a professional penetration tester. Besides testing and improving security, John has a passion for educating and informing the public. He accomplishes this by presenting hacking demos regularly at industry conferences and groups as well as writing blog posts for CynergisTek and industry publications.Nye’s specialties include Wireless, web, and system penetration testing, user education and public speaking, information assurance, security auditing, policy compliance and writing, and security research and analysis. Some of his industry certifications include CISSP, Licensed Penetration Tester (LPT) and Certified Ethical Hacker (CEH).