Alright, so please join me in welcoming Mark Newlin. This is Mouse Jack injecting keystrokes
into wireless mice. Well thank you guys for braving the lines to come out and see me talk. My
name is Mark Newlin and I work as a security researcher at Bastille Networks. And so I spend a
lot of time working with software defined radios and thinking about the security of wireless
devices. Before I joined Bastille I got into software defined radio by way of a couple DARPA
challenges. So in 2011 I competed in the DARPA shredder challenge which was this competition to
figure out how to reassemble shredded documents. And I ended up doing pretty well on that and I
finished that in third place out of the 9,000 or so teams. And I decided after that that I would
sign up for any future DARPA challenges that seemed you know feasible to do in my spare time. So
in 2013.
DARPA announced the spectrum challenge which was their first software defined radio competition.
And I signed up despite not knowing what SDR was. And there's a three week period between signing
up and the start of the qualifying round. So I managed to learn just enough to qualify as a
finalist. And I had the great distinction of being the only solo finalist team. And I was also
the only finalist who hadn't gone to college. Then at Bastille I've been responsible for the
mouse jack and key sniffer vulnerabilities which is why I'm up here today. So I'm going to start
with some background on the project. Get into the vulnerabilities. And then I'm going to start
with some demos and then have time for some questions. So the scope of this talk is 16
vulnerabilities I've identified in non-Bluetooth wireless keyboards and mice. These are
proprietary protocols with devices from 16 different vendors. Four different families of
transceivers. And they're mostly keystroke injection vulnerabilities and most of the devices
cannot be patched just due to hardware limitations. On the keystroke injection side we have
three basic scenarios. We have unencrypted keystrokes. We have unencrypted keystrokes. We have
a malicious macro-programming vulnerability which we're sending to a USB dongle for a mouse, or a
USB dongle for a keyboard. And then in some cases we can actually generate our own encrypted
keystrokes without knowledge of the AES key and inject those into the USB dongle of the
keyboard. Then we have a number of unencrypted keyboards and for these we can sniff and clear
text all the keystrokes a user is typing and also inject keystrokes into those. Then we have a
forced pairing vulnerability affecting certain Logitech devices. We have a malicious macro
programming vulnerability and for this we're going to inject a keystroke into the AES key. And
this an attacker can program a keystroke macro into somebody's mouse to trigger the next time
they hit a certain button and then we have some denial of service vulnerabilities affecting a
few Lenovo devices. And you might think that these kind of vulnerabilities are specific to
these you know second tier more obscure vendors but it turns out that really a lot of primary
vendors in this market sell vulnerable devices. So everybody on this list has at least one
keystroke injection vulnerability and many have keystroke sniffing and other vulnerabilities
as well. And I'm going to read the list just because it's really fun to say. So we have
Logitech, HP, Microsoft, Dell, Anchor, Lenovo, Toshiba, Amazon, Gigabyte, Insignia, Schmaus,
HDE, GE, Jasko, Radio Shack, Eagle Tech and Kensington. And so it's really an industry wide
problem. So before I continue I want to highlight some prior research in this space. In 2010
Thorsten Schroeder and Max Moser discovered that the XOR encryption used on certain Microsoft
wireless keyboards was weak. And what they discovered is that
the address of the keyboard was XORed with a payload and that was the encryption. So they
custom fabricated a device to sniff keystrokes from these Microsoft wireless keyboards but it
was kind of a high barrier to entry because it was custom hardware. So in 2011 Travis Goodspeed
discovered this kind of pseudo promiscuous mode that you can use on these common Nordic
semiconductor radios. And using that he was able to demonstrate the same type of keystroke
sniffing using commodity hardware. Then last year Sammy Kamkar built this device called
KeySweeper which is a USB wall adapter. And he was able to use this device to sniff keystrokes and
then send them back over a GSM backhaul. So on a high level you might think that a mouse and a
keyboard when you're using it is communicating directly with your computer. But really there are
two steps to the communication process. First your mouse or keyboard sends a radio packet to your
USB dongle. This is in response to you moving the mouse, clicking the mouse, or typing on the
keyboard. And the mouse and keyboard has no idea that there's a computer. All it knows is it's
sending this data to a radio inside that USB dongle. Then the other side of the link is the
USB dongle plugged into the computer. The USB dongle receives these radio packets from the mouse
or keyboard, determines what they mean, and generates USB human interface device packets which
it sends over USB to the host computer. And then the host computer does not know when a user is
that the source of the keystrokes or mouse movement was a wireless device. So the keystroke
injection vulnerabilities and force pairing vulnerabilities take advantage of that second
side of the link and send radio packets directly to a victim's USB dongle. And from the
computer standpoint, because it cannot distinguish between malicious packets and legitimate
packets that the user typed, the USB dongle has no way to filter these out. For the keystroke
injection or sniffing side rather, it's looking at the other side of the link. When you're
typing on an unencrypted wireless keyboard, it's sending these keystroke packets to your USB
dongle. But because they are unencrypted packets, an attacker can simply decode those going
over the error and see everything you're typing. So when I started this project, it wasn't a
vulnerability research project and I wasn't yet on the research team at work. I had done a lot
of protocol decoder implementations with software defined radios for known protocols up
until this point. But I was not yet on the research team at work. I had done a lot of
protocol decoder implementations with software defined radios for known protocols up until this
point. But I really wanted to see what the process was like to figure out how an unknown or
undocumented protocol works. And for me, the clear choice was the Logitech mouse I was using
at the time. And so I started doing some research to see if Logitech had published any data on
how their wireless mice communicate. And I came across this quote from a white paper in 2009,
where they say, since the displacements of a mouse would not provide any useful information to
a hacker, the mouse reports are not encrypted. And this is a reasonable statement because if all
you can do is listen to the direction of somebody's mouse movement, you're not going to get
anything out of that movement and the timing of their clicks, that doesn't really leak a lot of
data. But because they used the word hacker in there, I decided that I was going to find some
vulnerabilities. And so I started thinking about this from more of a security standpoint. So I
did the initial research using this Logitech mouse and a software defined radio. And for this,
it was, you know, passive receive only sniffing. So I was using GNU radio and a software defined
radio decoder to decode the packets going over the air between the mouse and dongle. So I could see
what the mouse was transmitting and what the dongle was transmitting.
And this allowed me, because it was unencrypted, to figure out the payload structure that the
mouse was using and start to get an idea of how this protocol behaves. The problem is, you
couldn't do a transceiver very well with this for timing constraints. So for example, if you want
to spoof a dongle, you need to be able to receive a packet from a mouse and then reply to that
with an ACK in, on the order of a, you know, millisecond or maybe even microseconds. With the
SDR decoder, by the time you know you need to send an ACK, that timeout has elapsed. So I needed
more of a specialized setup.
And conveniently at the time, this was last July, I was getting ready for Burning Man last
year. And for Burning Man, I built this giant LED cover top hat. And the only thing I could think to
do with this top hat was make a wireless NES controller for it. And it turns out, I put the
same type of radio, a Nordic semiconductor chip, in the NES controller as Logitech uses in
their wireless keyboards and mice. So I'm building this hat and working on this NES controller.
And I got the NES controller built about a week before DEF CON last year. And it occurred to me that
I could actually update the firmware on the controller to behave like a Logitech mouse. So I
set it up so I could listen for nearby Logitech mice. When it found a mouse, it would start
spoofing that and I could control that person's mouse with the D-pad for moving the cursor
around. And then right and left click with the A and B buttons. But the problem was everybody
had Logitech mice last year at DEF CON. So I would be controlling a mouse but I would have no
idea whose mouse I was talking to. So I added this mayhem button and this would generate random
movement and click packets. And I would hold that down for a second or two and look around and see
who's either screaming at their friends or violently pulling their dongle out. And it made it
pretty easy to identify the actual mouse I was talking to. So good for trolling but still not
practical. And then I found my way to the IOT Village last year and they were using a
Logitech mouse for their presentation clicker. And so I wrote this haiku that I think summarizes
the experience. IOT Village.
A Logitech mouse clicker did not like the hacks. And as you can see with that post it note they
politely asked me to stop fucking with them which I did. So after DEF CON I decided to make things
more complicated. And so I added this OLED display to the front of the controller. And this
made it possible to have a visual enumeration of the nearby devices so I could select a specific
device and control it at will. And then the asterisk next to the channel number indicates
activity. So I could correlate this visual activity with somebody moving their mouse and see
whose mouse it was.
And I also wanted to see how much stuff I could fit inside the controller. And this got kind of out of
hand and I ended up with a teensy and five radios and a lipo battery and charge controller and the
OLED display and 32 gigs of SD storage which was not necessary but still fun. And so I went to
TORCON last year and I gave a talk about this NES controller. But the problem was I didn't have
any vulnerabilities it was just a neat toy I built. So I implemented this on-screen keyboard
attack that you can do with wireless mouse communication. And there was a lot of stuff that I
could do with it. And the way this works on Windows 8.1 and 10 assuming a computer is at the
default DPI settings you can actually deterministically open the on-screen keyboard and then
deterministically put it in this tablet mode. And this mode works so you can have a thumb on each
corner of the screen if you have a touch screen. But what's nice is it's anchored to the bottom
left and bottom right hand corner of the screen. So then you can easily get to those corners you
can just go really far left and really far down and from there it's a fixed number of pixels up
and over to each character. And this made it possible to do an actual keystroke injection to a
keyboard attack using the on-screen keyboard without any visibility of the screen. But it was
not practical because you had to go very slow. So cursor acceleration kicks in pretty quick and
this means you have to go you know basically one pixel a millisecond somewhere in that order in
order to know where on the screen you've moved the cursor. So it takes a few seconds to type each
key so maybe several minutes of moving a mouse around and clicking the on-screen keyboard to
execute an attack so a fun demo but not terribly you know functional in the wild. So I was getting
back from TORCON and the project had more or less run its course. I had built a neat toy,
hadn't found any vulnerabilities, gave a talk, learned some stuff about the Logitech protocol but
I really wanted to continue this because I had this gut feeling that there was something to find.
So I kept working on this in my spare time and at this point I had a pretty good idea of how this
protocol worked. The mice aren't encrypted, the keyboards are encrypted and so I could see what
the mouse was sending over the air and what the USB
dongle was sending to the host computer for mouse movement and then I could see the encrypted
data the keyboard was sending and the unencrypted data the USB dongle was sending to the host
computer and I was able to infer what an unencrypted keyboard packet might look like over the
air. So I tried sending this and lo and behold it was accepted and this was the first
vulnerability I had ever found so I got pretty excited and I started collecting wireless mice and
keyboards and I basically went on Amazon and just ordered everything I could find. But the
problem was now I had these 50 devices and I had to be very, very careful about what I was going to
do and I had to be very efficient about evaluating them because if I took a week per device that
would be kind of insane. So my general strategy was to pwn all the peripherals and it turns out that
it worked out pretty well. So for each device I would start with some open source intelligence. So
this would be going to the FCC website and looking up frequency information, modulation schemes,
bandwidths where available. If there were documented transceivers I would look up the spec
sheets for those and I would use this data to implement a software defined radio decoder. And
this would allow me to see the physical layer packets going over the air between the device and
it's USB dongle. It wouldn't necessarily tell me what that data meant if it was encrypted for
example but I could at least decode the packets going over the air. And this uh white box in the
bottom right hand corner there this is from a radio track device and I love this uh please use a
transceiver in human house only and then children don't too install the transceiver. And it's
unclear what exactly they're trying to communicate there but there's a lot of this kind of
ingrish that's involved in these FCC docs so it's somewhat entertaining.
So after I would have the SDR decoder I would then try to figure out how the protocol worked. The
first step of this was figuring out what the payload formats were. So in the case of an
unencrypted device like a mouse it's just a matter of clicking different buttons and seeing what
bits and bytes change over the air. In the case of the keyboards if they're encrypted you might say
there's an incrementing counter here or a sequence number here or that sort of thing. And
after I had a basic idea of how the protocol worked I would start to look for low hanging food. And in
some cases this would be an unencrypted keyboard and then it's immediately vulnerable to
sniffing and ejection. There's actually a mouse which sends unencrypted keyboard packets from a
mouse and that was another easy sell. There's a lot of tech devices that send this raw USB HID
data. In that case it was just sending keyboard HID data in that place. In a lot of cases there
were some pretty quick vulnerabilities to find. But if there weren't I would get into the fuzzing.
And the basic premise here was to send unexpected data to a USB dongle and see if I could get it to
keystroke on the other end. And so I used the USB mon kernel module in Wireshark to monitor the
data going between the USB dongle and the computer. And then I would initially use the NES
controller to send packets to that USB dongle. If I got it to produce something that looked like a
keystroke I would then look at the last 30 seconds or so of radio packets and work out exactly what I
had to send to get it to generate that keystroke. One problem here is that even if you disable the
keyboard using xinput the magic sys request keys still work and so if you
spam a bunch of random keystroke packets to your computer it really really quickly causes a hard
reset. So I found disabling magic sys request during this process to be pretty vital. So most of
these devices are based on the Nordic Semiconductor NRF24L series of transceiver. And this is the
same chip that I had in the NES controller and it's a pretty popular low power 2.4 gigahertz
transceiver. They have multiple data rates, multiple payload widths, multiple CRC options. And
then they have a couple different versions of the Nordic Semiconductor. The Nordic Semiconductor is a
version of flash memory or memory rather. So you have some of these transceivers have flash
memory which can be written to multiple times. So the firmware writes once at the factory and then
again in the field if needed. You have other variants which have one time programmable memory.
This can be written once at the factory but not again in the field and a lot of vendors have used
these OTP chips which are then not able to be updated in the field. So if they have a
vulnerability all the devices out there will remain vulnerable. The transceivers also are
have 8051 microcontrollers built in and AES coprocessors. So with the AES coprocessor they can
do the AES computation but what the you know if they implement poor logic around there it still
leaves them potentially vulnerable to attack which a lot of them have done. So there's some
basic PHY and MAC layer functionality these Nordic chips provide. They have this enhanced
shock burst packet format which is a variable length packet format protected by a one or two
byte CRC. And then with this they have automatic ACKing and automatic reach
transmit. So from a firmware standpoint you basically say I want to send these bytes to this
address, use this ACK timeout and retry this many times before failure. And conveniently all of the
vendors who use these Nordic chips have adopted the same configuration of the parameters. So
they all use a 2 megabit data rate, a 5 byte address length, a 2 byte CRC and they use the
automatic ACKing and automatic retransmit. And then they vary in terms of what frequencies they
operate on and the actual links and forwarding. So they all use the same configuration and
the same format of the payloads. But because the physical layer is the same. That means a fuzzer
can be the same and the decoder can be the same across all of these devices. So all of the
mouse jack devices use these chips in this configuration. And that's why I was able to crank
those out in just a few weeks. So unifying by Logitech I think is the most interesting of these
protocols. And the reason is that it has a lot going on. So I'm going to touch on some of the
features of it here. A neat thing is that you can pair any unifying device to any unifying dongle.
So that means you're not going to have to have a power supply, you're going to have to have a
if you have a unifying dongle from 2009 you compare it to a unifying keyboard from 2016. The
dongles support firmware updates but most of the keyboards and mice do not. And so this
introduces a problem because you can fix bugs in the dongle but you can't make any protocol
changes because you can't update the firmware on most of the devices in the field. They're
mostly based on these Nordic chips but then some higher end Logitech devices use compatible
chips from TI. The TI chips have a higher transmit power but are otherwise over the air
compatible with the Nordic chips. Now the encryption is kind of weird here because you have
all of these transceivers support AES but they only use AES for a subset of the keyboard keys.
So the mice are completely unencrypted, the multimedia keys on the keyboard, so that would be
the volume keys and that sort of thing are unencrypted and then the regular 104 keys on the
keyboard are encrypted. And so what this means is you have a USB dongle which can accept both
encrypted and unencrypted keystrokes. There are also some white label unifying devices. So
specifically there's the Dell KM714 set and it has a Dell brand on it but it's really unifying
under the hood. All of the Logitech packets have the same basic format. So you have a 5, 10, or
22 byte payload and a 1 byte checksum. And the checksum I don't quite understand because it's
already protected by a 2 byte CRC by the enhanced shock burst packet but they've added this
checksum on all their packets for some reason. And then the addressing is based on the serial
number of the dongle. So the TI chips and Nordic chips each have a 4 byte check sum and the
4 byte serial number and this becomes the upper 4 bytes of the wireless address. And then each
device gets its own unique index. So the dongle is index 0. If you go by a mouse at the store it's
going to be index 7 and then as you pair new devices the index increments. So one interesting
feature of this is that if you find one device you can quickly enumerate the other 256
potential addresses by pinging them and find the total number of devices that are paired with a
dongle. Then they have this kind of quirk with this alternate
payload addressing scheme. So you have a maximum of 6 devices you can pair with a Logitech dongle
but it can only listen to 6 addresses at a time. And this is a problem because if you have 6
paired devices plus the device index 0 for the dongle that's 7 total addresses. But it can only
listen to 6. So if you're that 6 device and the other 6 addresses are in use you can't actually
contact the dongle on your assigned address. So they have this scheme where you can contact the
dongle by its address. So you send a packet to the dongle and then you send a packet to the
dongle at index 0 and say hey I'm here and then the dongle will start listening on your address.
But this means that only 5 of the 6 devices can be in use at a time. So with normal behavior you
have the keyboard or mouse send a packet to the dongle and the dongle replies with an ACK. The
dongle is always in a mostly receive mode. So it receives packets from a device and it will only
transmit when it's sending an ACK. This means that the dongle can't actively reach out and talk
to a keyboard or mouse. So they use this ACK payload. So the dongle is always in a mostly
receive mode. This means that the dongle can't actively reach out and talk to a keyboard or
mouse. This means that the dongle can't actively reach out and talk to a keyboard or mouse. So a
keyboard or mouse will send a normal packet to the dongle. And then if the dongle needs to do
something like query battery level or do an over the air firmware update it will use ACK payloads
to send that data back to the mouse or keyboard. And here's an example of ACK payloads. In
green we have some keepalive packets followed by some ACKs. Then in yellow we have an ACK with a
payload that's requesting a certain piece of version data. The mouse replies to that version
data and it continues as normal. And to use dynamic keepalives you have to use the ACK payloads
to manage the battery consumption and responsiveness. So the idea is that you have these
keepalives going back and forth between the mouse and the dongle. You have short keepalive
intervals when you're actively using the mouse so it's responsive. And you have longer
keepalive intervals when the mouse is idle to manage better battery life. So here we have a
keepalive example. We have in blue some mouse movement packets. Then we have some 110
millisecond interval keepalives in green. After five seconds of that it steps
off to these 1.2 second keepalive intervals and it will step off further until the device is
idle. Pairing is pretty straight forward with LauderTek devices. You have this LauderTek
unifying software so as a user you open this up, you hit pair new device and this tells the
dongle to listen on a fixed pairing address for 30 to 60 seconds. If a pairing request comes in
during that 30 to 60 seconds it will pair with the dongle. During the pairing request however
the mouse or keyboard fully describes itself and it's capability. So you can see that the mouse
and keyboard is in set for pairing and in set for pairing could be solved by pairing the
device to some of the other power capabilities. So this includes the name of the device, the
model, the type, the serial number. But importantly the USB HID capabilities which are
either you know mouse movement, mouse click, keystroke whatever. Then when you turn on a
mouse or keyboard it first tries to ping it dongle. If that dongle is not in range it
immediately tries to pair with any other dongle in pairing mode. So for pairing to happen you have
to have a dongle in pairing mode. And you have to have your pairing device, not in range of its dongle.
So now we can get into some vulnerabilities. And I've omitted some of the specifics and packet
formats just due to time constraints but they're all contained in the white paper on the CD and
I'll be posting them later online. So we'll start with the encrypted protocols where we're
sending unencrypted packets. And I call it an encrypted protocol if any part of the protocol is
encrypted. So Logitech unifying for example would be encrypted because you have encrypted
keyboards despite the unencrypted mice. So we have the unencrypted keystroke injection targeting
the wireless address of the keyboard. And this is the first vulnerability I found effecting
these Logitech devices. And this works by sending an unencrypted USB HID packet to the RF address
of the keyboard. So you're sending this packet directly to the dongle and causing a keystroke to
be injected into the host computer. This also effects the Dell KM714 set which is unifying
under the hood. But the problem is that it's not unifying the host computer. It's not
unifying the mouse door, it's not unifying the keyboard. And the problem is when people are out
and about they're not likely to have a wireless keyboard with a laptop. However, people will
frequently have a mouse with a mouse dongle. So it turns out that even though pairing is supposed
to happen on this fixed pairing address, you can also transmit a pairing request to any address
that the dongle is listening on. So if you can overhear mouse movement and get the address of the
mouse, you can actually send a pairing request to that address and it will be accepted and you can
pair your own keyboard with somebody's dongle and then inject keystrokes into that keystroke and
keyboard that you paired. But then we have this problem where what if the user sees a new
keyboard paired with their computer. So you can take advantage of the fact that the device is
fully described during the pairing process and you can actually pair a device that shows up in
the Logitech software as a mouse but functionally is a keyboard. So we notified Logitech of
these vulnerabilities in November, disclosed them publicly in February. Logitech released a
fix in February for the forced pairing vulnerability and a partial fix for the keystroke
injection vulnerability. The keystroke injection vulnerability was fixed on clean installs of
Windows but it turns out there are a few situations in which it would still work. So the
first is if you're using Linux the keystroke injection vulnerability still works. If you're
using OSX it still works. And my favorite is if you have a clean install of Windows it's fixed
but if you install the Logitech setpoint software on that same machine the attack starts
working again and this kind of blew my mind. So we notified Logitech of these bypasses in
April and last week they released a fix.
The firmware update which does in fact fix the keystroke injection vulnerability when the
Logitech software is installed. Then we get to this Logitech G900 chaos specter mouse. And this is a
$150 gaming mouse and it's billed as having professional grade wireless. And I was really
curious what exactly professional grade wireless meant. So I took it apart and sort of
looking at the protocol and it turns out it's just unifying with the knobs turned up. So it
doesn't support pairing. It has fewer channels and it has shorter ACK intervals. So it's not
unifying. But everything about it is identical to unifying. So the first thing I tried is
unencrypted keystroke injection and sure enough that worked. And then we have this Logitech
gaming software. And you can use this to program keystroke macros into your mouse. So the
idea is the data is stored in firmware on the mouse. You press a button on the mouse that you
can define and then it will send keystrokes to your computer. It turns out you can program
these macros wirelessly. So a scenario would be a user has this Logitech G900 mouse and it's
turned on. It's beaconing for its dongle. An attacker can reply to those beacons and actually
program a macro into the mouse when it's just in this guy's laptop bag. The victim gets home,
presses the button on their mouse and it executes the attack by injecting keystrokes into
their computer. We notified Logitech of these vulnerabilities in April and they released a
firmware update to fix the unencrypted keystroke injection vulnerability last week. Then we
have unencrypted keystroke injection targeting the computer. So this is the first time we've
been targeting wireless mouse dongles outside of the Logitech one. This affects the Amazon
Basics wireless mouse, the Dell KM632 wireless mouse, the Lenovo 500 wireless mouse and most
Microsoft wireless mice. And this is simply sending unencrypted USB HID data to the dongle
belonging to one of these mice. And the Microsoft case was really interesting because they
have this sculpt ergonomic mouse. And this has a Windows button on it. It turns out if you press
this Windows button it sends an unencrypted keystroke packet over the air. So it's a
really cool feature. So finding this was literally a 10 minute process of watching this packet,
changing it to a different key other than the Windows key and injecting arbitrary keystrokes. And
I would have expected that after their XOR encryption debacle that this would have been
implemented better because they do incorporate AES encryption on their keyboards now. But this
applies to all of their AES encrypted mice or rather mice from the AES encrypted series as well
as mice from the XOR encrypted series. We notified Amazon in November of last year. Uh no
response from them. We notified Dell in November of last year. They don't have the ability to
update the firmware on their devices but they did fix the firmware going forward and sent us an
updated unit to test. So existing devices on the market will remain vulnerable but new devices
will be fixed. And same story with Lenovo. No firmware updates available but going forward this
is fixed. Lenovo also went as far as sending an engineer to our office in Atlanta to see how we
did this research. So I have you know mad props for them.
Then in April Microsoft released a Windows update that partially addressed this
problem. Because it's a Windows update it doesn't apply to Linux or OSX. And it also only applies
if you're using a mouse that was purchased independently of a set. So if you have a keyboard
and mouse set that's still vulnerable on all versions of Windows. If you're using Windows
server that's still vulnerable. But if you're using client versions of Windows it's still
a Windows update. So I have a dedicated client that has Windows and a mouse that was purchased
with just the mouse and the mouse dongle and an updated version of Windows then you're fixed.
Also Microsoft does no firmware update support on any of their devices. Then we have a denial of
service vulnerability affecting certain Lenovo devices. And this is kind of interesting because
you have three different products made by three different OEMs but they all have a different
flavor of this vulnerability. And this works by sending a packet of a given length to a USB dongle.
and it doesn't matter what the data is in that packet just the dongle receives a packet of
length n and then it crashes until it's reseated. Now we have kind of an interesting case
where a lot of vendors have implemented counter mode AES but done it in such a way that
it's vulnerable to an encrypted keystroke injection attack. So with counter mode AES you
start with a nonce and a counter. So the nonce is going to be just a fixed length or rather
fixed piece of uh data and you have a counter which increments between each packet. You take
your nonce and your counter, that functions as your initialization vector for the AES
encryption, you encrypt that, you get your ciphertext, you XOR your data with that
ciphertext and then that output data is sent over the air with the counter. Now the expected
behavior is that the dongle would not accept the same counter twice. So the idea is that you
use a different essential
different key between each packet but unfortunately many of these vendors accept the same
counter twice. So on the surface that allows you to do a simple replay attack but some quirks
about how the USB HID packets are formatted makes it possible to actually generate your own
packets using this technique. So when you type a key on a keyboard it sends two packets. You
have the first one is a key down packet and then you have a key up packet and they're going to go
in quick succession usually. So if you're observing this you can usually infer that you have a key down
and key up packet. The key down packet is going to contain the scan code of the key you pressed.
But the key up packet is all zeros. So what happens is you're sending all zeros XORed with the
ciphertext. That means the actual ciphertext goes over the air with the counter. And so you can
actually just XOR that ciphertext with your arbitrary data, send it with that counter and
inject your arbitrary injected keystrokes. And what's crazy is most of these devices, the
keyboards rather, reset their counter when you power cycle them.
So it's difficult for the vendors who can't update their dongles to do any kind of protocol fix
because that would break keyboards out there in the field. This affects all of the Logitech
unifying keyboards including the Dell KM714, the Dell KM632 keyboard, the Lenovo UltraSlim
keyboard, Amazon Basics wireless keyboard as well as the HP Wireless Elite version 2 keyboard.
We notified the vendors in April and did a public disclosure last week. Logitech has been
working on a fix. Dell fixed this by changing to a different protocol on their keyboard, which I
haven't evaluated yet. They sent a keyboard to me to test and it is in fact fixed for this specific
vulnerability. No response from Amazon. And HP was actually part of the November disclosure and
did not acknowledge the vulnerability. Now we have the case of completely unencrypted
protocols. And this is kind of crazy because you have devices that have come on the market as
recently as last year that have keyboards with built-in ciphertexts. And this is kind of crazy
because you have zero encryption. We have three different types of transceivers that are
common in these keyboards. And they're all mostly undocumented. So I was looking at these
devices and I was expecting that the first part of the process would be figuring out how the
physical layer works and what their packet formats are. But after getting past that first step, it
turned out that they were just sending clear text keystroke data. So we have Mozart Semiconductor
makes transceivers in six of the vulnerable keyboards. And this is just a simple GFSK
protocol. Uh no encryption. All you have to do is type in the password and you're good to go. So
we have a keyboard that operates on a single channel. We have this Signia transceiver and a
Toshiba keyboard and mouse set. This is another simple GFSK protocol. Frequency hopping, but
again, no encryption. And then we have this GE Jasko keyboard. Now GE has the brand on the
keyboard. But it's actually made by this company called Jasko who licenses the trademark from
GE. I have no idea what the transceiver actually is in this thing except that it's 500 kilohertz
GFSK and no encryption. So all of these are vulnerable to keystroke sniffing and keystroke
injection.
So here's a list of devices we have, or the Mozart devices. We have devices from Anker,
EagleTech, HP, Insignia, Kensington, Radio Shack, Schmaus, and HTE. All the vendors were
notified in November, or rather in April except for Schmaus because they had apparently no web
presence and we weren't able to find any contact details. The last two are mice, but they do use
transceivers that have keyboard logic in them. So that means with normal operating behavior,
they function as mice, you can still inject keystrokes into those dollars. So this is a
nice extension of that. So this is the keystrokes that we're going to be using for the
keyboard. So we have the keyboard, there's a keyboard that has a keyboard that has an
unencrypted Nordic chick binnet and then the Toshiba keyboard. Again, these are all
vulnerable to keystroke sniffing and keystroke injection. Now what's interesting with the
Mozart devices is that they're constantly beaconing to the keyboards. So they're sending these
synchronization packets every 8 or 16 milliseconds. And the keyboard, when you turn it on,
it will look for these synchronization packets and then lock on to that TDMA timing. That
means, though, an attacker, even if users aren't at their computers, can enter a room or a
building and quickly survey for all of the computers using these unencrypted keyboards. Now
because all these keyboards have unique identifiers, that same attacker can also record
keystrokes from everybody's keyboard if they're using these devices.
We received responses from some of these vendors. Anchor will be exchanging their
vulnerable keyboards for Bluetooth devices through the end of this month.
Kensington claims to have a new AES encrypted keyboard. I have not seen this or tested it, and
the FCC docs show no new keyboards this year. Insignia has told reporters that their
keyboards are encrypted, however they, at least the model that I have tested, is
unencrypted.
And then GE Jasco is no longer producing wireless keyboards or mice and will therefore not be
fixing the firmware.
So one question I've been asked a lot is if I think there are other devices on the market with
these same vulnerabilities. And I think there are because you have a lot of these devices that
are white label hardware. So a company will go to an OEM, they will license this OEM's keyboard
or mouse and put their brand on it. And the assumption is that with this white label hard
wear comes white label vulnerabilities. So I'm going to highlight a few different comparisons of
an OEM keyboard versus a vendor keyboard. So here we have the HP wireless classic desktop and then
the OEM equivalent on the right. So here we have at least two copies of this same keyboard. Then
we have the Amazon Basics wireless keyboard and mouse and then the OEM equivalent on the right.
Now this OEM Taconi also makes the Dell KM632. The Amazon and Dell keyboards have the same
encrypted keystroke injection vulnerability. So it's feasible that other Taconi devices might as
well. Then we have the RadioShack wireless keyboard and the OEM equivalent on the right. And so
the point here is you have all these OEM's making this hardware. The vendors may not be aware of how
these devices operate or what protocols they use and therefore they may have a lot of
vulnerabilities out there that we're unaware of. So for doing these kind of attacks I'm a big fan of
using these crazy radio dongles. This is part of the open source quadcopter project called
CrazyFly. It's an open source quadcopter project called CrazyFly. It's an open source quadcopter
project called CrazyFly. And it has a Nordic chip on it and also an amplifier. Using these we've
been able to range test injection attacks into the Nordic based devices out to 225 meters away
using one of these and a directional antenna. The firmware that comes with these is great but not
good for these kind of purposes. So I built some open source firmware that you can flash onto
these crazy radio dongles and use them for generic transmission and reception of wireless
packets. And that's up on GitHub. The problem was, I didn't know what I was doing with this
thing. After Mousejack came out, everybody went and bought these crazy radio dongles. They got
expensive and hard to find. So the Logitech unifying dongles have the same transceiver but
without an amplifier. So I figured out how Logitech does their firmware update process and
now you can actually flash my firmware directly onto Logitech dongles. And it's just running
And so you pull the firmware down, plug in your Logitech dongle and run sudo make Logitech
install and it flashes this onto your dongle. And these things are cheap, they're available, they
don't have as good of range as the crazy radio dongles but they're still effective. Also I have a
pocket full of these dongles and if you want one I am happy to give you one. Then we have an
Android app that I produced that is able to do device detection. So you can plug a Logitech
dongle into your Android phone and it will scan an area and classify devices based on the packet
format. So it'll classify mouse or keyboard or trackpad or touchpad for Logitech and Microsoft
devices. And then it'll do a little bit of testing and see what it's doing. And then it'll be able to
identify devices based on the packet format and then identify without classification other
Nordic based devices. We'll be releasing this very near future. So now we get to some demos. And
for the demos this is kind of fun because I will be using Logitech dongles to execute attacks
against other Logitech dongles with this custom firmware. So I have this Logitech M510 mouse
here. Just the regular Logitech dongle which I'll plug into my computer. And then I'll run this
into this computer. And then in my other laptop here I have a Logitech dongle which is running my
custom firmware. So the first attack I'm going to do is this forced pairing. And this allows us to
force pair new device with this Logitech dongle even though it's not in pairing mode. So this
will run that and we'll see new device pop up momentarily here. And the thing is right now this is
showing up as a mouse. But there's actually a number of device types we can have it show up as. So
we'll go do the go do another demo here. This will be number two. And now we have a keyboard. But
there are more device types yet. We can also do a number pad. We can also do a number pad. We can
also do a number pad. And then finally a presentation presenter. Now using these devices
that we've paired we can now inject keystrokes directly into the addresses that have been
populated on the dongle. So now we'll do a keystroke injection attack targeting that first
mouse that was paired. This will bring up an administrative command prompt and add a user on
this machine. So now we have a keystroke injection attack targeting that first mouse that was paired.
And if you'd like to see some more demos I have some additional ones prepared that I can show you
if you find me after the talk. Also I'm very very happy to give you one of these LauderTech
dongles flashed for this custom firmware and tell you all about how this works. And now I have some
time for questions.
So for the questions you need to come to this microphone up here.
So you said that the dongles got really expensive because people started buying all of them. Does this
firmware work with the the chiefs chinese copies of the uh Nordic chip? It should I haven't tried
it with any of the chinese copies but as long as their uh compatible with the Nordic chips then
that should be fine. First of all thank you very much very
interesting. Thank you. I was wondering if you happen to check the bluetooth side um
controllers keyboard devices? Oh yeah I'm sorry uh I was unable to hear you. Okay I said that thank
you very much, it was very interesting. Uh, basically all our offices are compromised now.
Um, was wondering if you happen to check the Bluetooth devices? Uh, I haven't looked at
Bluetooth devices, I've specifically been looking at proprietary protocols. Thank you very
much. Hi, I was curious about the Logitech Nano receivers and how they are different and if
you've been able to find any exploits or attacks with them. Uh, I've only looked at one of
those and it's a similar protocol but I haven't explored it for any kind of
vulnerabilities. Okay, thank you. Why doesn't the, why doesn't the Bluetooth, uh, why
aren't the Bluetooth mouths or peripherals vulnerable? Um, so these are specific to vendor
implementations of these proprietary protocols but I just haven't looked at any Bluetooth
devices. Okay, great. I was just, I was just wondering about how many of, like
percentage wise of these types of devices are not patchable at all because of the
lack of ability for firmware updates. So, most of the devices cannot be updated. The
Logitech unifying dongles can be, but by and large everything else cannot be patched. Alright,
thank you very much. Uh, you mentioned pairing, uh, devices or doing the force pairing. You
would use the existing address of the previous device. Will that old device keep working once
you force pair it? Yeah, so what happens is the old device keeps working and then it just
generates a new address for the new device. Alright, cool, thanks. Yep.
I was just wondering why no Macs were involved in this testing. Is there any implementation or
device, is there? So the, the keystroke injection vulnerabilities do work on Apple
computers for these devices but I haven't looked at any of the Apple hardware. Oh. For the
Apple keyboards and mice. Okay, thank you. Okay, well thank you very much for your
time. Thank you guys. Alright, and so I, I think we have to go out to the hall for, uh,
passing out some dongles here. So let me just pack up real quick.