Peripheral Pwnage: Mousejacking 2.4 Ghz Input Devices
August 31, 2017 | Posted in Red Teams by Jonathan Renard
On internal engagements, poisoning name resolution requests on the local network (à la Responder) is one of the tried and true methods of obtaining that coveted set of initial Domain credentials. While this approach has worked on many clients (and has even given up Domain Admin in less time than it takes to grab lunch), what if Link Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NTB-NS) protocols are configured securely or disabled? Or, what if Responder was so successful that you now want to prove other means of gaining that initial foothold? Let’s explore…
|PROTIP: Always prove multiple means of access whenever possible during engagements!|
There are a multitude of attacks a penetration tester can leverage when conducting physical walkthroughs of client spaces. One of the more interesting, and giggle-inducing, involves exploiting wireless peripherals. This technique, known as “mousejacking”, gained some notoriety in early 2016 when Bastille, a firm specializing in wireless and Internet of Things (IoT) threat detection, released a whitepaper documenting the issue. At a high-level, the attack involves exploiting vulnerable 2.4 GHz input devices by injecting malicious keystrokes (even if the target is only using a wireless mouse) into the associated USB dongle. This is made possible because many wireless mice (and a handful of keyboards) either don’t use encryption between the device and its paired USB dongle, or will accept rogue keystrokes even if encryption is being utilized. WIRELESS WHOOPSIE!
You Vulnerable, Bro?
At this point, you are probably wondering which input devices are vulnerable. While a more comprehensive list can be found on Bastille’s website, I’ve personally had the most experience with Microsoft and Logitech products while on engagements.
Vulnerable Microsoft products include, and most certainly aren’t limited to, the following devices:
With Logitech, devices that are likely to be affected are ones that leverage the “Unifying” dongle, which is meant to work with a large number of wireless input devices the company produces. The dongle can be easily identified by an orange star printed on the hardware:
Have Your Hardware Handy
To help us conduct our mousejacking attack, we need to first acquire SeeedStudio’s Crazyradio PA USB dongle and antenna. This is a ~$30 long-range 2.4 GHz wireless transmitter (which uses the same series of transceiver, Nordic Semiconductor’s nRF24L, that many of the vulnerable devices leverage) that is intended for use on hobby drones; however, we are going to flash the firmware (courtesy of Bastille) to weaponize it for our own nefarious purposes. *EVIL CACKLE* This new firmware will allow the dongle to act promiscuously, adding packet sniffing and injection capabilities. Once the Crazyradio PA is in hand, the instructions for setting it up with new firmware can be found here.
It is also helpful to have one or more known vulnerable devices on hand to leverage for testing. In my personal lab, I am utilizing Logitech’s m510 Wireless Mini Mouse and Microsoft’s Wireless Mobile Mouse 4000.
JackIt In The Office (But Don’t Get Caught…)
The software of choice for this scenario is going to be JackIt, a python script written by phiksun (@phikshun) and infamy (@meshmeld). The project leverages the work of Bastille and simplifies both identification of devices and the attack delivery. Using Kali, or your distribution of choice, go ahead and grab the script:
Take a gander at the README.md file and follow the instructions to install JackIt. Once that is completed, ensure that the flashed Crazyradio PA dongle is plugged in prior to starting up the tool. Failure to do so will cause JackIt to throw an error. Let’s start by running JackIt without any arguments, which will put the tool into reconnaissance mode, allowing you to see what wireless input devices are in range:
Take a few moments to inspect JackIt’s output before continuing:
When a device is discovered, a new row is created with a number assigned in the KEY column based on order of initial appearance. You will need to reference this number when targeting a particular device (more on that shortly). The ADDRESS column shows the hardware MAC address for the wireless device. This can be useful when determining whether you’ve previously seen / targeted a particular device (JackIt does not keep track of your previously targeted devices, so when working with multiple devices, you’ll need to keep track of them yourself). The TYPE column displays the brand of the device once enough packets are captured by JackIt to accurately identify. Note that in the screenshot above that the second device (KEY 2) has not been adequately fingerprinted yet.
|WARNING: You cannot successfully target a device without the TYPE column populated.|
The COUNT and SEEN columns relate to wireless communication detected between a device and its dongle. COUNT refers to the number of times communication between the device and dongle were picked up by the Crazyradio PA. SEEN informs us how many seconds have passed since the last communication was detected. Devices that haven’t been detected in a while are either a) not being actively used at the moment or b) no longer in range. With the former, there is a potential that the user has locked their computer and stepped away. In either case, these are probably not ideal targets.
The CHANNELS column notates the channel(s) that the wireless peripheral and dongle are utilizing to communicate. Lastly, PACKET shows the contents of the last captured communication. For our purposes, we can ignore these two column(s).
To actually exploit devices that are discovered, JackIt will need to know what malicious keystrokes to send to a victim. The tool takes commands in Ducky Script format, the syntax leveraged by the Rubber Ducky, a keystroke-injecting USB thumb drive created by Hak5. Whereas a Rubber Ducky requires Duckyscript to be encoded prior to being used for exploitation, this is not the case for JackIt… simply pass the “plaintext” commands in a text file. If you are unfamiliar with Duckyscript, please refer to Hak5’s readme page to get your learn on.
A recommended starting point for a Duckyscript mousejacking template can be found below. Given that it may be possible for a user to see a mousejacking attempt in progress, an attempt has been made to streamline the attack as much as possible without sacrificing accuracy. DELAY times are much shorter than with traditional Rubber Ducky scripts as there is no need to wait for driver installation since we are not physically plugging a USB device into the victim’s machine. In addition to keeping the DELAY values low, it is also helpful to shorten the actual attack payload as much as possible. The reason here is twofold, less keystrokes means less time to send characters to the victim (each keystroke is literally “typed” out on the target and can draw attention to the attack) as well as lessening the chance of any data-in-transit issues (wireless attacks can be unstable, with possible lost or malformed characters). We will discuss these types of issues in greater detail later on.
Using the script above, JackIt would open the Windows “run” prompt, pause briefly, pass whatever malicious payload we specify, pause briefly, then submit the command. To give you an idea of the speed of keystroke injection as well as user’s visibility of active mousejacking attack, I have recorded a clip of sending a string of character’s to a victim’s machine using the above template: