 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 shredder documents and I ended up doing pretty well on that and I finished that in third place out of the 9000 SO teams and I decided after that that I would sign up for any future DARPA challenges that seems 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 was 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, do some demos and then have time for some questions. So the scope of this talk is 16 vulnerabilities I've identified and 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 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 a 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 force pairing vulnerability affecting certain logitech devices. We have a malicious macro programming vulnerability and for 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, Anker, Lenovo, Toshiba, Amazon, Gigabyte, Insignia, Schmouse, HTE, GE, Jasco, 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 the 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 Key Sweeper which is a USB wall adapter and inside he had a microcontroller and Nordic radio and a GSM radio and he demonstrated sniffing these Microsoft XOR encrypted keystrokes and then sending 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 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's 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 air 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 to find 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 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 to find radio. And for this it was, you know, passive receive only sniffing. So I was using GNU radio and a software to find 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 act in on the order of a millisecond or maybe even microseconds. With the SDR decoder by the time you know you need to send an act 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 and 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 Defconn 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 Defconn. 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 Defconn 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 TMZ 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 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 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 basically one pixel a millisecond somewhere on that order in order to know where on the screen you move 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 attack. So a fun demo but not terribly functional in the wild. So I was getting back from Torcon and the project had more or less run its course. I had built an eight 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 efficient about evaluating them because if I took a week per device that would be kind of insane. So my general strategy was to hone 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 were 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 its 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 white box in the bottom right hand corner there, this is from a radio track device. And I love this. Please use a transceiver in human house only and then children don't to install the transceiver. And it's unclear what exactly they're trying to communicate there but there's a lot of these kind of ingrish that 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. And 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 produce a key stroke 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 key stroke 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 key stroke. One problem here is that even if you disable the keyboard using X input the magic sys request keys still work. And so if you spam a bunch of random key stroke 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 Semic Nuctor 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 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 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 have 8051 microcontrollers built in and AES co-processors. So with the AES co-processor they can do the AES computation but 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 FI 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 hacking and automatic retransmit. So from a firmware standpoint you basically say I want to send these bytes to this address, use this act time out 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 hacking and automatic retransmit. And then they vary in terms of what frequencies they operate on and the actual links and format of the payloads. But because the physical layer is the same that means the 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 and 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 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 in 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. They're 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 Shockburst 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 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 lot of the 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 signed address. So they have this scheme where you can contact the dongle by its address so 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 out of 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 applies with an act. The dongle is always in a mostly received mode so it receives packets from a device and they will only transmit when it's sending an act. This means that the dongle can't actively reach out and talk to a keyboard or mouse. So they use this act payload scheme. 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 act payloads to send that data back to the mouse or keyboard. And here's an example of act payloads. In green we have some keep alive packets followed by some acts. Then in yellow we have an act 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 they use dynamic keep alive to manage the battery battery consumption and responsiveness. So the idea is that you have these keep alive going back and forth between the mouse and the dongle. You have short keep alive intervals when you're actively using the mouse so it's responsive. And you have a longer keep alive intervals when the mouse is idle to manage better battery life. So here we have a keep alive example. We have in blue some mouse moving packets. Then we have some 110 millisecond interval keep alive in green. After five seconds of that it steps off to these 1.2 second keep alive intervals and it will step off further until the device is idle. Pairing is pretty straightforward with logitech devices. You have this logitech 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 its 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 mouse movement, mouse click, keystroke whatever. Now when you turn on a mouse or a keyboard it first tries to ping its 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 watertech 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 affecting these watertech 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 affects the Dell KM714 set which is unifying under the hood. But 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 the dongle is listening on. So if you can overhear mouse movement and get the address of a 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 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 notify Logitech of these vulnerabilities in November. Disclose them publicly in February. Logitech released a fix in February for the force 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 your clean install of windows, it's fixed. But if you install the Logitech set point software on that same machine, the attack starts working again and this kind of blew my mind. So we notify Logitech of these bypasses in April and last week they released a 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 vector 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 AC intervals, 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 in their laptop bag, it's turned on, it's beaconing for it's dongle, an attacker can reply to those beacons and actually program a macro into the mouse when it's just in the sky's laptop bag, it's turned on, it's just in the sky'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 notify 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 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 had the 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 finding this was literally a ten minute process of watching this packet, changing it to a different key other than the windows key and injecting arbitrary key 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. 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 send 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 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 OS X and it also only applies if you're using a mouse that was purchased independently of a set. So you have a keyboard and mouse set that's still vulnerable in all versions of windows. If you're using a windows server that's still vulnerable but if you're using client versions of 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 has 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 setting 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 receded. 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, a rather fixed piece of data then 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 cipher text. You XOR your data with that cipher text 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, essentially 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 the 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 cipher text. That means the actual cipher text goes over the air with the counter. And so you can actually just XOR that cipher text 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 I 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 Ultra Slim 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 and Lenovo are both working on a fix. Dell fixed this by changing to a different protocol in 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 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 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 level 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, no encryption, operates on a single channel. We have the Signia Transceiver and a Toshiba keyboard and mouse set. This is another simple GFSK protocol, frequency hopping, but again, no encryption. Now we have this GE JASCO keyboard. Now GE has the brand on the keyboard but it's actually made by this company called JASCO who licenses a trademark from GE. I have no idea what the transceiver actually is in this thing except that it's 500 kHz GFSK and no encryption. So all of these are vulnerable to keystroke sniffing and keystroke injection. So here's the list of devices we have are the Mozart devices. We have devices from Anchor, EagleTech, HP, and Signia, Kensington, RadioShack, Shmouse and HDE. All the vendors were notified in November or rather in April except for Shmouse 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 dongles. Then we have the non-Mozart devices. This is the GE JASCO keyboard. There is a gigabyte keyboard that has an unencrypted Nordic chip in it 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 are constantly beaconing to the keyboards. So they're sending these synchronization packets every 8 or 16 milliseconds. And the keyboard when turned 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 receive 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, at least the model that I have tested is unencrypted. And then GEJASCO 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 hardware 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 jaconi also makes the Dell KM632. The Amazon and Dell keyboards have the same encrypted keystroke injection vulnerability so it's feasible that other jaconi devices might as well. Then we have the Radio Shack wireless keyboard and the OEM equivalent on the right. And so the point here is you have all these OEMs 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 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 in 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 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 will classify mouse or keyboard or trackpad or touchpad for Logitech and Microsoft devices 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 with a regular Logitech dongle which I'll plug 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 force pairing and this allows us to force pair a new device with this Logitech dongle even though it's not in pairing mode. So we'll run that and we'll see a new device pop up momentarily here. And the thing is right now this is showing up as a mouse. There's actually a number of device types we can have it show up as. So go do another demo here be number two. And now we have a keyboard. But there are more device types yet. 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 I'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. And if you'd like to see 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 flash 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 cheap Chinese copies of the Nordic chip? It should. I haven't tried it with any of the Chinese copies, but as long as they're compatible with the Nordic chips, then it should be fine. First of all, thank you very much. Very interesting. Thank you. I was wondering if you happened to check the Bluetooth side controllers, keyboard devices. Yeah, I'm sorry. I wasn't able to hear you. Okay. I said that thank you very much. It was very interesting. Basically all our offices are compromised now. I was wondering if you happened to check the Bluetooth devices. I haven't looked at Bluetooth devices. I've specifically been looking at proprietary protocols. Thank you very much. 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. 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. Why aren't the Bluetooth mouths or peripherals vulnerable? 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 wondering about how many of percentage-wise of these type 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. All right. Thank you very much. You mentioned pairing devices during the forced pairing. You would use the existing address of a previous device. Will that old device keep working? Yeah, so what happens is the old device keeps working and then it just generates a new address for the new device. All right, cool. Thanks. I was just wondering why no Macs were involved in this testing. Is there any implementation or is there reason why? So the Keystroke Induction Vulnerabilities do work on Apple computers for these devices, but I haven't looked at any of the Apple hardware for the Apple keyboards and mice. Okay, thank you. Okay, well, thank you, guys. All right, and so I think we're going to go out to the hall for passing out some dongles here, so let me just show you.