00:00:00.200-->00:00:05.706 >>All right. So, please join me in welcoming Marc Newlin. This is Mousejack: Injecting 00:00:05.706-->00:00:10.711 Keystrokes into Wireless Mice. [applause and cheering] >>Well thank you guys for braving the 00:00:18.151-->00:00:24.124 lions to come out and see me talk. My name is Marc Newlin and I work as a security researcher 00:00:24.124-->00:00:28.629 at Bastille Networks and so I spend a lot of time working with software defined radios and 00:00:28.629-->00:00:33.200 thinking about the security of wireless devices. Before I joined Bastille I got into 00:00:33.200-->00:00:38.939 software defined radio by way of a couple of DARPA challenges. So in 2011 I competed in the DARPA 00:00:38.939-->00:00:42.543 Shredder Challenge which was this competition to figure out how to reassemble a shredded 00:00:42.543-->00:00:46.680 document and I ended up doing pretty well on that, I finished that in third place out of the 00:00:46.680-->00:00:51.952 9000 or so teams and I decided after that that I would sign up for any future DARPA challenges 00:00:51.952-->00:00:57.291 that seemed, you know, feasible to do in my spare time. So in 2013 DARPA announced the 00:00:57.291-->00:01:01.061 Spectrum Challenge which was their first software defined radio competition and I signed 00:01:01.061-->00:01:06.033 up despite not knowing what SDR was and there was a three week period between signing up and 00:01:06.033-->00:01:10.103 the start of the qualifying round. And so I managed to learn just enough to qualify as a 00:01:10.103-->00:01:14.174 finalist and I had the great distinction of being the only solo finalist team and I was 00:01:14.174-->00:01:18.545 also the only finalist who hadn't gone to college. Then at Bastille I've been responsible 00:01:18.545-->00:01:22.983 for the Mousejack and Keysniffer vulnerabilities which is why I'm up here today. So I'm going to 00:01:22.983-->00:01:27.554 start with some background on the project, get into the vulnerabilities, do some demos 00:01:27.554-->00:01:33.727 and then have some time for some questions. So the scope of this talk is 16 vulnerabilities I've 00:01:33.727-->00:01:38.865 identified in non-bluetooth, wireless keyboards and mice. These are proprietary protocols, 00:01:38.865-->00:01:44.137 with devices from 16 different vendors, 4 different families of transceivers and they are mostly 00:01:44.137-->00:01:48.041 keystroke injection vulnerabilities and most of the devices cannot be patched just 00:01:48.041-->00:01:54.881 due to hardware limitations. On the keystroke injection side we have 3 basic scenarios we have 00:01:54.881-->00:02:00.487 unencrypted keystrokes which we are sending to a USB dongle for a mouse or USB dongle for a 00:02:00.487-->00:02:05.392 keyboard. And then in some cases we can actually generate our own encrypted keystrokes without 00:02:05.392-->00:02:10.497 knowledge of the AES key and inject those into the USB dongle of the keyboard. Then we have a 00:02:10.497-->00:02:15.402 number of unencrypted keyboards, and for these we can sniff in cleartext all the keystrokes a 00:02:15.402-->00:02:20.073 user is typing and also inject keystrokes into those. Then we have a forced pairing 00:02:20.073-->00:02:24.778 vulnerability affecting certain Logitech devices. We have a malicious macro programming 00:02:24.778-->00:02:29.783 vulnerability and for this an attacker can program a keystroke macro into somebody's mouse to 00:02:29.783-->00:02:33.286 trigger the next time they hit a certain button. And then we have some denial of service 00:02:33.286-->00:02:39.326 vulnerabilities affecting a few Lenovo devices. And you might think that these vulnerabilities 00:02:39.326-->00:02:43.997 are specific to these, you know, second tier, more obscure vendors but it turns out that 00:02:43.997-->00:02:48.969 really a lot of primary vendors in this market sell vulnerable devices. So everybody on this 00:02:48.969-->00:02:53.640 list has at least one keystroke injection vulnerability and many have keystroke sniffing and 00:02:53.640-->00:02:57.044 other vulnerabilities as well and I'm going to read the list just because it's really fun to 00:02:57.044-->00:03:02.416 say: So we have Logitech, HP, Microsoft, Dell, Anker, Lenovo, Toshiba, Amazon, Gigabyte, 00:03:02.416-->00:03:07.521 Insignia, ShhhMouse, HDE, GE/Jasco, Radioshack, EagleTec and Kensington. And so it's 00:03:07.521-->00:03:13.960 really a industry-wide problem. So before I continue I wanna highlight some prior research in 00:03:13.960-->00:03:19.299 this space. In 2010 Thorsten Schröder and Max Moser discovered that the XOR 00:03:19.299-->00:03:23.804 encryption used on certain Microsoft wireless keyboards was weak. And what the discovered is 00:03:23.804-->00:03:28.475 that the address of the keyboard was XORed with the payload and that was the encryption. So they 00:03:28.475-->00:03:32.512 custom-fabricated a device to sniff keystrokes from these Microsoft wireless keyboards. 00:03:32.512-->00:03:38.085 But it was kinda a high barrier to entry because it was custom hardware. So in 2011 Travis 00:03:38.085-->00:03:42.322 Goodspeed discovered this kinda puedo-promiscuous mode that you could use on these common Nordic 00:03:42.322-->00:03:46.827 semiconductor radios and using that he was able to demonstrate the same type of keystroke 00:03:46.827-->00:03:51.965 sniffing using commodity hardware. Then last year Samy Kamkar built this device called 00:03:51.965-->00:03:57.170 KeySweeper. Which is a USB wall adapter and inside he had a microcontroller, a Nordic radio 00:03:57.170-->00:04:01.641 and a GSM radio and he demonstrated sniffing these Microsoft XOR encrypted 00:04:01.641-->00:04:08.081 keystrokes and then sending them back over a GSM backhaul. So, on a high level you might think 00:04:08.081-->00:04:12.252 that a mouse and a keyboard when you're using it is communicating directly with your computer but 00:04:12.252-->00:04:17.257 really there are two steps to the communication process. First your mouse or keyboard sends a 00:04:20.393-->00:04:24.898 radio packet to your USB dongle , this is in response to you moving the mouse, clicking the 00:04:24.898-->00:04:29.035 mouse or typing on the keyboard and the mouse and keyboard has no idea that there is a 00:04:29.035-->00:04:34.808 computer, all it knows is it is sending this data to a radio inside that USB dongle. Then the 00:04:34.808-->00:04:39.513 other side of the link is the USB dongle plugged into the computer. The USB dongle 00:04:39.513-->00:04:44.451 receives these radio packets from the mouse or keyboard, determines what they mean and 00:04:44.451-->00:04:49.556 generate USB human interface device packets which it sends over USB to the host computer. 00:04:49.556-->00:04:54.728 And the the host computer does not know that the source of the keystrokes or mouse movement was 00:04:54.728-->00:04:59.900 a wireless device. So the keystroke injection vulnerabilities and forced 00:04:59.900-->00:05:05.138 pairing vulnerabilities take advantage of that second side of the link and send radio packets 00:05:05.138-->00:05:09.643 directly to a victim's USB dongle and from the computer's standpoint, because it cannot 00:05:09.643-->00:05:15.081 distinguish between malicious packets and legitimate packets that the user typed the USB 00:05:15.081-->00:05:21.021 dongle has no way to filter these out. For the keystroke injection, or sniffing side 00:05:21.021-->00:05:25.959 rather, it's looking at the other side of the link when you're typing on an unencrypted 00:05:25.959-->00:05:30.864 wireless keyboard it's sending these keystroke packets to your USB dongle. But because they are 00:05:30.864-->00:05:35.035 unencrypted packets an attacker can simply decode those going over the air and see everything 00:05:35.035-->00:05:41.141 you are typing. So when I started this project it wasn't a vulnerability research project 00:05:41.141-->00:05:45.011 and I wasn't yet on the research team at work. I had done a lot of protocol decoder 00:05:45.011-->00:05:49.449 implementations for software defined radios for known protocols up until this point 00:05:49.449-->00:05:53.386 but I really wanted to see what the process was like to figure how an unknown or undocumented 00:05:53.386-->00:05:59.459 protocol works and for me the clear choice was the Logitech mouse I was using at the time. 00:05:59.459-->00:06:02.963 And so I started doing some research to see if Logitech had published any data on how their 00:06:02.963-->00:06:08.201 wireless mice communicate and I came across this quote from a whitepaper in 2009 when they say 00:06:08.201-->00:06:12.706 sensing displacements of the mouse would not provide any useful information to a hacker 00:06:12.706-->00:06:16.810 the mouse reports are not encrypted. And this is a reasonable statement because all 00:06:16.810-->00:06:20.947 you can do is listen to the direction of somebodies mouse movement and the timing of their 00:06:20.947-->00:06:24.985 clicks, that doesn't really leak a lot of data but because they used the word hacker in there I 00:06:24.985-->00:06:28.989 decided I was going to find some vulnerabilities and so I started thinking about this from more of 00:06:28.989-->00:06:34.160 a security standpoint. So I did the initial research using this Logitech mouse and a software 00:06:34.160-->00:06:40.400 defined radio and for this it was, you know, passive, receive only sniffing. So I was using 00:06:40.400-->00:06:44.604 GNURadio and a software defined radio decoder to decode the packets going over the air 00:06:44.604-->00:06:48.308 between the mouse and dongle so I could see what the mouse was transmitting and what the dongle 00:06:48.308-->00:06:52.545 was transmitting and this allowed me, because it was unencrypted, to figure out the 00:06:52.545-->00:06:55.982 payload structure that the mouse was using and to start to get an idea as to how this protocol 00:06:55.982-->00:07:00.053 behaves. The problem is you couldn't to a transceiver very well with this because of timing 00:07:00.053-->00:07:04.824 constraints. So, for example, you want to spoof a dongle you need to be able to receive a 00:07:04.824-->00:07:09.896 packet from a mouse and then reply to that with an ACK in, on the order of a - you know - 00:07:09.896-->00:07:14.868 milliseconds or maybe even microseconds with the SDR decoder by the time you know you 00:07:14.868-->00:07:19.673 need to send an ACK, that timeout has elapsed so I needed more of a specialised setup. 00:07:22.609-->00:07:25.979 And, conveniently at the time, this was last July, I was getting ready for Burning Man 00:07:25.979-->00:07:30.917 last year and for Burning Man I built this giant LED-covered top hat and the only think I could 00:07:30.917-->00:07:35.221 thing to do with this top hat was to make a wireless NES controller for it and it turns 00:07:35.221-->00:07:40.093 out I put the same type of radio, a Nordic semiconductor chip, in the NES controller as 00:07:40.093-->00:07:44.230 Logitech uses in their wireless keyboards and mice. So I'm building this hat and working on 00:07:44.230-->00:07:49.169 the NES controller and I got the NES controller build about a week before DEF CON last year 00:07:49.169-->00:07:52.539 and it occurred to me that I could actually update the firmware on the controller to 00:07:52.539-->00:07:58.712 behave like a Logitech mouse so I set it up up so I could listen for nearby Logitech mice, when 00:07:58.712-->00:08:03.350 it found a mouse it would start spoofing that and I could control that person's mouse with 00:08:03.350-->00:08:07.520 the D-pad for moving the cursor around and then right and left click with the A and B buttons. 00:08:07.520-->00:08:12.525 But the problem was everybody had Logitech mice last year at DEF CON so I would be 00:08:12.525-->00:08:16.863 controlling a mouse but I'd have no idea whose mouse I was talking to so I added this 00:08:16.863-->00:08:21.835 mayhem button and this would generate random movement and click packets and I'd hold that 00:08:21.835-->00:08:25.171 down for a second or two and look around to see who's either screaming at their friends or 00:08:25.171-->00:08:28.942 violently pulling their dongle out and it made it pretty easy to identify the actual mouse I 00:08:28.942-->00:08:33.947 was talking to. [laughter] So, good for trolling but still not practical. [applause] And, then 00:08:39.686-->00:08:43.523 I found my way to the IoT village last year and they were using a Logitech mouse for their 00:08:43.523-->00:08:49.129 presentation clicker and so I wrote this haiku that I think summarises this experience: IoT 00:08:49.129-->00:08:54.067 Village A Logitech mouse clicker Did not like the hacks And as you can see with that Post-It 00:08:54.067-->00:09:00.040 note they politely asked me to stop fucking with them, which I did. So after DEFCON I decided 00:09:00.040-->00:09:04.377 to make things more complicated and so I added this OLED display to the front of the controller 00:09:04.377-->00:09:08.782 and this make it possible to have a visual enumeration of the nearby devices so I could select 00:09:08.782-->00:09:13.319 a specific device and control it at will and then the asterisk next to the channel number 00:09:13.319-->00:09:17.557 indicates activity. So I could correlate this visual activity with somebody moving their mouse 00:09:17.557-->00:09:21.561 and see who's mouse it was and I also wanted to see how much stuff I could fit inside the 00:09:21.561-->00:09:26.566 controller and this got kinda out of hand and ended up with a Teensy and five radios and a 00:09:26.566-->00:09:31.271 lipo battery and charge controller and the OLED display and 32 gigs of SD storage which 00:09:31.271-->00:09:37.577 was, not necessary, but still fun. And so I went to TORcon last year and I gave a talk 00:09:37.577-->00:09:41.548 about this NES controller but the problem was I didn't have any vulnerabilities it was just 00:09:41.548-->00:09:46.019 a neat toy I built. So I implemented this onscreen keyboard attack that you can do 00:09:46.019-->00:09:50.890 with wireless mouse communication and the way this works on Windows 8.1 and 10 00:09:50.890-->00:09:56.196 assuming that a computer is at the default DPI settings you can actually deterministically open 00:09:56.196-->00:10:00.567 the onscreen keyboard and then deterministically put it in this tablet mode. And this mode works 00:10:00.567-->00:10:04.137 so that you can have a thumb on each corner of the screen if you have a touchscreen. But what's 00:10:04.137-->00:10:08.007 nice is that it's anchored to the bottom left and bottom right hand corners of the screen so 00:10:08.007-->00:10:11.711 then you can easily get to those corners (you can just go really far left and really far down) 00:10:11.711-->00:10:15.782 and from there it's a fixed number of pixels up and over to each character and this made it 00:10:15.782-->00:10:21.020 possible to do an actual keystroke injection attack using the onscreen keyboard without 00:10:21.020-->00:10:26.392 any visibility of the screen but it was not practical because you had to go very slow. So cursor 00:10:26.392-->00:10:30.864 acceleration kicks in pretty quick and this means you have to go, basically, one pixel a 00:10:30.864-->00:10:34.968 millisecond or somewhere in that order in order to know where on the screen you've moved the 00:10:34.968-->00:10:39.339 cursor. So it takes a few seconds to type each key so maybe several minutes of moving 00:10:39.339-->00:10:43.543 the mouse around and clicking the onscreen keyboard to execute an attack so, a fun demo but, 00:10:43.543-->00:10:50.216 not terrible, you know, functional in the wild. So I was getting back from TORcon and the 00:10:50.216-->00:10:56.523 project had more or less run its' course. I had built a neat toy, hadn't found any 00:10:56.523-->00:11:00.760 vulnerabilities, gave a talk, learned some stuff about the Logitech protocol. But I really 00:11:00.760-->00:11:05.765 wanted to continue this because I had a gut feeling that there was something to find. So I kept 00:11:05.765-->00:11:10.570 working on this in my spare time and at this point I had a pretty good idea of how this protocol 00:11:10.570-->00:11:16.309 worked the mice aren't encrypted the keyboards are encrypted and so I could see what the mouse 00:11:16.309-->00:11:20.180 was sending over the air and what the USB dongle was sending to the host computer for mouse 00:11:20.180-->00:11:24.684 movement and then I could see the encrypted data the keyboard was sending and the unencrypted 00:11:24.684-->00:11:28.821 data the USB dongle was sending to the host computer and I was able to infer what an 00:11:28.821-->00:11:33.192 unencrypted keyboard packet might look like over the air so I tried sending this and lo and 00:11:33.192-->00:11:37.430 behold it was accepted and this was first vulnerability I had ever found so I got pretty 00:11:37.430-->00:11:42.835 excited and I started collecting wireless mice and keyboards. And I basically just went on Amazon 00:11:42.835-->00:11:47.774 and ordered everything I could find. But the problem was now I had these 50 devices and I had 00:11:47.774-->00:11:51.311 to be very, very efficient about evaluating them because if I tool a week per device that 00:11:51.311-->00:11:57.717 would be kinda insane. So my general strategy was to "pwn all the peripherals" and it turns 00:11:57.717-->00:12:02.622 out that it worked out pretty well. So for each device I would start with some open source 00:12:02.622-->00:12:07.193 intelligence so this would be going to the FCC website and looking up frequency information 00:12:07.193-->00:12:11.297 and modulation schemes and bandwidth, where available. If there were documented 00:12:11.297-->00:12:15.535 transceivers I would look up the spec sheets for those and I would use this data to implement 00:12:15.535-->00:12:20.273 a software defined radio decoder and this would allow me to see the physical layer packets going 00:12:20.273-->00:12:24.577 over the air between the device and its' USB dongle. It wouldn't necessarily tell me what that 00:12:24.577-->00:12:28.114 data meant, if it was encrypted for example, but I could at lease decode the packets going 00:12:28.114-->00:12:33.553 over the air and this, um white box in the bottom right hand corner this is from a radioshack 00:12:33.553-->00:12:38.558 device and I love this "please use transceiver in human house only" and then "children don't 00:12:38.558-->00:12:42.495 to install the transceiver" and it's unclear what, exactly they are trying to communicate there 00:12:42.495-->00:12:46.699 but there's a lot of this kind of Engrish that involved in these FCC docs, so it's somewhat 00:12:46.699-->00:12:52.171 entertaining. So after I would have the SDR decoder I would then try to figure out how the 00:12:52.171-->00:12:57.043 protocol worked. The first step of this was figuring out what the payload formats were. So in 00:12:57.043-->00:13:00.913 the case of an unencrypted device, like a mouse. It's just a matter of clicking different 00:13:00.913-->00:13:05.084 buttons, and seeing what bit and bytes change over the air. In the case of the keyboards, if 00:13:05.084-->00:13:08.855 they are encrypted, you might say there is an incrementing counter here or a sequence 00:13:08.855-->00:13:15.395 number here or that sort of thing. And after I had a basic idea of how the protocol worked 00:13:15.395-->00:13:19.198 I was starting to look for low hanging fruit. And in some cases that would be an unencrypted 00:13:19.198-->00:13:23.002 keyboard and then it's immediately vulnerable to sniffing and injection. There's 00:13:23.002-->00:13:27.640 actually a mouse which sends unencrypted keyboard packets from a mouse, and that was 00:13:27.640-->00:13:32.612 another easy sell. There's some Logitech devices that send raw HID data in that case it was 00:13:32.612-->00:13:36.616 just sending keyboard HID data in that place. And a lot of cases there was some pretty 00:13:36.616-->00:13:42.255 quick vulnerabilities to find. But if if there weren't I'd get into the fuzzing and the basic 00:13:42.255-->00:13:47.226 premise here was to send unexpected data to a USB dongle and see if I could get it to 00:13:47.226-->00:13:52.632 produce a keystroke on the other end and so I used the USBmon kernel module in WireShark to 00:13:52.632-->00:13:57.570 monitor the data going between the USB dongle; and the computer and then I would initially use 00:13:57.570-->00:14:03.443 the NES controller to send packets to the USB dongle. If I got it to produce something that 00:14:03.443-->00:14:07.814 looked like a keystroke I would then look at the last 30 seconds or so of radio packets and work 00:14:07.814-->00:14:12.952 out exactly what I had to send to get it to generate that key stroke. One problem here is that 00:14:12.952-->00:14:16.989 even if you disable the keyboard using x-input the magic sys-request keys still work and 00:14:16.989-->00:14:20.960 so if you spam a bunch of random keystroke packets to your computer it really, really 00:14:20.960-->00:14:24.764 quickly causes a hard reset so I found disabling magic sys-request during this process 00:14:24.764-->00:14:29.769 to be pretty vital. So most of these devices are based on the Nordic semiconductor nRF24L 00:14:32.705-->00:14:37.076 series of transceiver and this is the same chip that I had in the NES controller and it's a 00:14:37.076-->00:14:42.915 pretty popular, low power, 2 point 4 gigahertz transceiver. The have multiple data rates, 00:14:42.915-->00:14:47.420 multiple payload widths, multiple CRC options and then they have a couple of different 00:14:47.420-->00:14:51.457 version of flash memory, or memory rather. So you have some of these transceivers have flash 00:14:51.457-->00:14:55.928 memory which can be written to multiple times. So the firmware writes, once at the factory and 00:14:55.928-->00:15:00.500 then again in the field if needed. You have other variants with have one time programmable 00:15:00.500-->00:15:05.505 memory this can be written once at the factory and not again in the field and a lot of vendors 00:15:05.505-->00:15:10.209 have used these OTP chips which are then not able to be updated in the field so if they have a 00:15:10.209-->00:15:16.849 vulnerability all the devices out there will remain vulnerable. The transceivers, 00:15:16.849-->00:15:22.588 also, have 8051 microcontrollers built into them and AES coprocessors. So with the AES 00:15:22.588-->00:15:28.194 coprocessor they can do the AES computation but what the what, if they implement poor logic 00:15:28.194-->00:15:31.531 around there it still leaves it potentially vulnerable to attack, which a lot of them have 00:15:31.531-->00:15:36.536 done. So there's some basic defined MAC layer functionality these Nordic chips provide, they 00:15:38.571-->00:15:42.708 have this enhanced shockburst packet format which is a variable length format protected 00:15:42.708-->00:15:47.346 by a one or two byte CRC. And then with this they have automatic ACKing and automatic 00:15:47.346-->00:15:53.119 retransmit so, from a firmware standpoint you basically say: "I want to send these bytes to this 00:15:53.119-->00:15:58.124 address use this ACK timeout and retry this many times before failure" and, conveniently all 00:16:00.293-->00:16:03.830 of the vendors that use these Nordic chips have adopted the same configuration of the 00:16:03.830-->00:16:10.436 parameters. So they all use a 2 megabit data rate, a 5 byte address length, a 2 byte CRC and 00:16:10.436-->00:16:14.640 they use the automatic ACKing and automatic retransmit. And then they vary in terms of what 00:16:14.640-->00:16:19.245 frequencies they operate on and the actual length and format of the payloads but because the 00:16:19.245-->00:16:23.182 physical layer is the same that means the fuzzer can be the same and decoder can be the same 00:16:23.182-->00:16:27.386 across all of these devices so all of the Mousejack devices use these chips in this 00:16:27.386-->00:16:34.126 configuration and that's why I was able to crank those out in just a few weeks. So Unifying, 00:16:34.126-->00:16:37.930 by Logitech, I think, is the most interesting of these protocols and the reason is that 00:16:37.930-->00:16:42.602 it has a lot going on. So I'm going to touch on some of the features here. A neat thing is 00:16:42.602-->00:16:48.007 that you can pair any Unifying device to any Unifying dongle so that means if you have a 00:16:48.007-->00:16:54.780 Unifying dongle from 2009 you can pair it to your keyboard form 2016. The dongles support 00:16:54.780-->00:16:59.418 firmware updates but most of the keyboards and mice do not and so this introduces a problem, 00:16:59.418-->00:17:03.656 because you can fix bugs in the dongle but you can't make any protocol changes because you 00:17:03.656-->00:17:08.127 can't update the firmware on most of the devices in the field. They are mostly based on 00:17:08.127-->00:17:12.698 these Nordic chips but then, some higher end Logitech devices use compatible chips from TI. 00:17:12.698-->00:17:17.503 The TI chips have a higher transmit power but are otherwise, over-the-air 00:17:17.503-->00:17:21.941 compatible with Nordic chips. Now the encryption is kinda weird here because you have all 00:17:21.941-->00:17:27.880 of these transceivers support AES but they only use AES for a subset of the keyboard keys so 00:17:27.880-->00:17:31.884 the mice are completely unencrypted. The multimedia keys on the keyboard, so that would 00:17:31.884-->00:17:36.389 be the volume keys and that sort of thing, are unencrypted. And then the regular 104 keys on the 00:17:36.389-->00:17:41.360 keyboard are encrypted. And so what this means is you have a USB dongle which can accept both 00:17:41.360-->00:17:47.166 encrypted and unencrypted keystrokes. There are also some white label Unifying devices so, 00:17:47.166-->00:17:51.804 specifically there is the Dell KM714 set and it has the Dell brand on it but it's really 00:17:51.804-->00:17:58.044 Unifying, under the hood. All of the Logitech packets have the same basic format so you have a 00:17:58.044-->00:18:03.449 5, 10 or 22 byte payload and a 1 byte checksum. And the checksum I don't quite understand because 00:18:03.449-->00:18:07.119 it's already protected by the 2 byte CRC by the enhanced shockburst packet but they've 00:18:07.119-->00:18:12.491 added the checksum on all of their packets for some reason. And then the addressing is based 00:18:12.491-->00:18:16.963 on the serial number of the dongle. So the TI chips and the Nordic chips each have a four 00:18:16.963-->00:18:21.767 byte serial number and this become the upper four bytes of the wireless address and then 00:18:21.767-->00:18:27.873 each device gets its' own, unique index. So the dongle is indexed 0, if you go buy a mouse 00:18:27.873-->00:18:33.145 a the store it's going to be index 7 and as you pair new device the index increments so 00:18:33.145-->00:18:37.483 one interesting feature of this is if you find one device you can quickly enumerate the other 00:18:37.483-->00:18:42.388 256 potential address by pinging them and find the total number of devices that are paired with 00:18:42.388-->00:18:47.626 the dongle. And then they have this kind of quirk with this alternate payload addressing 00:18:47.626-->00:18:53.499 scheme so you have a maximum of 6 devices you can pair with a Logitech dongle but it can only 00:18:53.499-->00:18:59.405 listen to 6 addresses at a time and this is a problem because if you have 6 paired device, plus 00:18:59.405-->00:19:05.044 the device index 0 for the dongle that's 7 total addresses but it can only listen to 6. So 00:19:05.044-->00:19:11.050 if you are that 6th device and the other 6 addresses are in use you can't actually contact the 00:19:11.050-->00:19:15.588 dongle on your assigned address so they have this scheme where you can contact the dongle by 00:19:15.588-->00:19:19.692 its' address, so you send a packet to the dongle at index 0 and say: "hey, I'm here" and 00:19:19.692-->00:19:23.629 then the dongle will start listening on your address but this means that only 5 of those 00:19:23.629-->00:19:30.036 6 devices can be in use at a time. So with normal behaviour you have the keyboard or mouse 00:19:30.036-->00:19:36.042 send a packet to the dongle and the dongle replies with an ACK the dongle is always in a mostly 00:19:36.042-->00:19:40.246 receive mode so it receives packets from a device and then will only transmit when its' 00:19:40.246-->00:19:45.785 sending an ACK this means that a dongle can't actively reach out and talk to a keyboard or mouse 00:19:45.785-->00:19:50.456 so they use this ACK payload scheme. So a keyboard or mouse will send a normal packet to the 00:19:50.456-->00:19:54.493 dongle and then if the dongle needs to do something like query battery level or do an 00:19:54.493-->00:19:59.098 over-the-air firmware update it will use ACK payload to send that data to the mouse or 00:19:59.098-->00:20:04.670 keyboard. And here's an example of ACK payloads. In green we have some keep-alive packets 00:20:04.670-->00:20:08.641 followed by some ACKs and then in yellow we have an ACK with a payload that's requesting some 00:20:08.641-->00:20:15.581 sort of version data, the mouse replies with that version data and it continues as normal. And 00:20:15.581-->00:20:21.787 the use dynamic keep-alives to manage the battery pa-, battery consumption and responsiveness. 00:20:21.787-->00:20:26.425 So the idea is that you have these keep-alives going back and forth between the mouse and the 00:20:26.425-->00:20:30.730 dongle. You have short keep-alive intervals when you're actively using the mouse, so the 00:20:30.730-->00:20:35.701 mouse is responsive and you have longer keep-alive intervals when the mouse is idle to manage 00:20:35.701-->00:20:40.940 better battery life. So here we have a keep-alive example, we have, in blue, some mouse 00:20:40.940-->00:20:46.812 movement packets. Then we have 110 millisecond keep-alives in green. After 5 second of that it 00:20:46.812-->00:20:50.950 steps off to the 1.2 second keep-alive intervals and it will step off further until the 00:20:50.950-->00:20:56.455 device is idle. Pairing is pretty straight forward with Logitech devices. You have the 00:20:56.455-->00:21:00.860 Logitech Unifying software, so as a user you open this up, you hit "pair new device" and this 00:21:00.860-->00:21:05.865 tells the dongle to listen on a fixed pairing address for 30 to 60 seconds. If a pairing request 00:21:08.701-->00:21:12.872 comes in during that 30 to 60 seconds, it will pair with the dongle. During the pairing 00:21:12.872-->00:21:18.077 request however, the mouse or keyboard fully describes itself and its' capabilities. So this 00:21:18.077-->00:21:22.848 includes the name of the device, the model, the type, the serial number... but, importantly, the 00:21:22.848-->00:21:27.853 USB HID capabilities, which are either, mouse movement, mouse click, keystroke, whatever. Now 00:21:30.356-->00:21:35.361 when you turn on a mouse or a keyboard it first tries to ping its' dongle, if that dongle is 00:21:35.361-->00:21:39.899 not in range it immediately tries to pair with any other dongle in pairing mode. So for 00:21:39.899-->00:21:43.769 pairing to happen you have to have a dongle in pairing mode and you have to have your 00:21:43.769-->00:21:48.774 pairing device not in range of its' dongle. So now we can get into some vulnerabilities. And 00:21:51.944-->00:21:56.749 I've omitted some of the specifics and packet formats just due to time constraints but 00:21:56.749-->00:22:03.088 they are all contained in the whitepaper on the CD and I'll be posting them later online. So 00:22:03.088-->00:22:07.560 I'll start with the encrypted protocols where we're sending unencrypted packets. And I call 00:22:07.560-->00:22:11.630 it an encrypted protocol if any part of the protocol is encrypted. So Logitech Unifying, 00:22:11.630-->00:22:14.867 for example, would be encrypted because you have encrypted keyboards despite the 00:22:14.867-->00:22:19.872 unencrypted mice. So we have the unencrypted keystroke injection targeting the wireless address 00:22:23.509-->00:22:26.712 of a keyboard. And this is the first vulnerability I found affecting these Logitech 00:22:26.712-->00:22:32.318 devices. And this works by sending an unencrypted USB HID packet to the RF address of a 00:22:32.318-->00:22:35.521 keyboard, so you are sending this packet directly to the dongle and causing a keystroke 00:22:35.521-->00:22:40.192 to be injected into the host computer. This also affects the Dell KM714 set which is 00:22:40.192-->00:22:46.031 Unifying, under the hood. But the problem is, when people are out and about, they are not 00:22:46.031-->00:22:49.935 likely to have a wireless keyboard with their laptop. However, people will frequently 00:22:49.935-->00:22:55.174 have a mouse with a mouse dongle. So it turns out that, even through pairing is supposed 00:22:55.174-->00:23:00.312 to happen on this fixed pairing address you can also transmit a pairing request to any address 00:23:00.312-->00:23:04.583 the dongle is listening on. So if you can overhear mouse movement and get the address of 00:23:04.583-->00:23:09.255 the mouse you can actually send a pairing request to that address and it will be accepted 00:23:09.255-->00:23:13.058 and you can pair your own keyboard with somebody's dongle and then inject keystrokes into 00:23:13.058-->00:23:18.197 that keyboard that you just paired. And then we have this problem with what if a user sees 00:23:18.197-->00:23:22.534 a new keyboard paired with their computer? So you can take advantage of the fact that the 00:23:22.534-->00:23:26.672 device is fully described during the pairing process and you can actually pair a device that 00:23:26.672-->00:23:32.945 shows up in the Logitech software as a mouse but functionally is a keyboard. So 00:23:32.945-->00:23:36.615 we notified Logitech of these vulnerabilities in November, disclosed them publicly in 00:23:36.615-->00:23:41.820 February. Logitech released a fix in February for the forced pairing vulnerability and a 00:23:41.820-->00:23:45.924 partial fix for the keystroke injection vulnerability. The keystroke injection 00:23:45.924-->00:23:50.095 vulnerability was fixed on clean installs of Windows but it turns out there are few situations 00:23:50.095-->00:23:54.600 where it will still work. So the first is if you are using Linux the keystroke injection 00:23:54.600-->00:23:59.471 vulnerability still works. If you are using OSx, it still works. And my favorite is, if 00:23:59.471-->00:24:03.409 you have a clean install of Windows, it's fixed, but if you install the Logitech Setpoint 00:24:03.409-->00:24:09.048 software on that same machine the attack starts working again and this kinda blew my mind. 00:24:09.048-->00:24:12.785 [laughter] So we notified Logitech of these by-passes in April and last week they 00:24:12.785-->00:24:16.622 released a firmware update which does in fact fix the keystroke injection vulnerability when the 00:24:16.622-->00:24:21.627 Logitech software is installed. Then we get to this Logitech G900 Chaos Spectrum mouse. And 00:24:23.996-->00:24:29.001 this is $150 gaming mouse and it's billed as having "professional grade wireless" 00:24:29.001-->00:24:33.038 and I was really curious what, exactly, "professional grade wireless" meant. So I took it 00:24:33.038-->00:24:37.176 apart and started looking at the protocol and it turns out it's just Unifying with the knobs 00:24:37.176-->00:24:43.248 turned up. So it doesn't support pairing, it has fewer channels and it has shorter ACK intervals 00:24:43.248-->00:24:46.919 but everything about it is identical to Unifying. So the first thing I tried is 00:24:46.919-->00:24:51.924 unencrypted keystroke injection and sure enough that worked. And then we have this Logitech 00:24:51.924-->00:24:57.763 gaming software and you can use this to program keystroke macros into your mouse. So the idea is 00:24:57.763-->00:25:01.900 the data is stored in firmware on the mouse, you press a button on the mouse - that you can 00:25:01.900-->00:25:06.638 define - and it will send keystrokes to your computer. It turns out you can program these 00:25:06.638-->00:25:11.643 macros wirelessly. So a scenario would be: a user has this Logitech G900 mouse in their 00:25:13.679-->00:25:18.984 laptop bag, it's turned on, it's beaconing for its' dongle an attacker can reply to those 00:25:18.984-->00:25:24.423 beacons and actually program a macro into the mouse when it's just in this guy's laptop bag. 00:25:24.423-->00:25:28.494 The victim gets home, presses a button on their mouse and it executes the attack by injecting 00:25:28.494-->00:25:33.966 keystrokes into their computer. We notified Logitech of these vulnerabilities in April, and 00:25:33.966-->00:25:40.873 they release a firmware update to fix the unencrypted keystroke vulnerability last week. Then we 00:25:40.873-->00:25:45.177 have unencrypted keystroke injection targeting wireless mouse dongles outside of the 00:25:45.177-->00:25:51.049 Logitech one. This affects the Amazon Basics wireless mouse, the Dell KM632 wireless mouse, 00:25:51.049-->00:25:56.622 the Lenovo 500 wireless mouse and most Microsoft wireless mice. And this is simply sending 00:25:56.622-->00:26:03.262 unencrypted USB HID data to the dongle belonging to one of these mice. And the Microsoft case 00:26:03.262-->00:26:06.899 was, really interesting, because they have this sculpted, ergonomic mouse. And this has a 00:26:06.899-->00:26:11.170 Windows button on it. It turns out that if you press this Windows button it sends an 00:26:11.170-->00:26:15.174 unencrypted keystroke packet over the air. So finding this was literally a 10 minute 00:26:15.174-->00:26:20.312 process of watching this packet, changing it to a different key - other than the Windows key - and 00:26:20.312-->00:26:24.383 injecting arbitrary keystrokes. And I would have expected that after their XOR encryption 00:26:24.383-->00:26:28.587 debacle that this would have been implemented better because they do incorporate AES 00:26:28.587-->00:26:33.725 encryption on their keyboards now. But this applies to all of their AES encrypted mice, or 00:26:33.725-->00:26:37.663 rather mice from the AES encrypted series as well as mice from the XOR encrypted series. 00:26:39.698-->00:26:45.637 We notified Amazon in November of last year, ah, no responce from them. We notified Dell in 00:26:45.637-->00:26:49.741 November of last year, they don't have the ability to update the firmware on their devices, 00:26:49.741-->00:26:53.912 but they did fix the firmware going forward and sent us a updated unit to test. So 00:26:53.912-->00:26:59.651 existing devices on the market will remain vulnerable but new devices will be fixed. And same 00:26:59.651-->00:27:04.456 story with Lenovo, no firmware updates available but going forward this is fixed. Lenovo 00:27:04.456-->00:27:08.126 also went as far as sending an engineer to our office in Atlanta to see how we did this 00:27:08.126-->00:27:13.131 research so I have, you know, mad props for them. [applause] And then in April, Microsoft 00:27:20.606-->00:27:25.244 released a Windows update that partially addressed this problem. Because it's a Windows 00:27:25.244-->00:27:31.416 update it doesn't apply to Linux or OSx and it also only applies if you're using a mouse that was 00:27:31.416-->00:27:36.488 purchased independently of a set. So if you have a keyboard and mouse set that's still 00:27:36.488-->00:27:41.193 vulnerable on all version of Windows if you're using WIndows Server, that's still vulnerable 00:27:41.193-->00:27:44.997 but if you are using client version of Windows and a mouse that was purchased with just the 00:27:44.997-->00:27:50.736 mouse and the mouse dongle and an updated version of Windows then you're fixed. Also 00:27:50.736-->00:27:57.042 Microsoft does no firmware support on any of their devices. Then we have a denial of service 00:27:57.042-->00:28:00.779 vulnerability affecting certain Lenovo devices. And this is kinda interesting because you 00:28:00.779-->00:28:04.950 have three different products made by three different OEMs but they have a different flavour of 00:28:04.950-->00:28:09.755 this vulnerability. And this works by sending a packet of a given length to a USB dongle. 00:28:09.755-->00:28:14.426 And it doesn't matter what the data is in that packet just the dongle receives a packet of 00:28:14.426-->00:28:20.666 length N and then it crashes until it's reseated. Now we have kind of an interesting case 00:28:20.666-->00:28:25.537 where a lot of vendor have implemented counter-mode AES but done it in such a way that it is 00:28:25.537-->00:28:30.542 vulnerable to an encrypted keystroke attack. So if counter-mode AES you start with 00:28:32.711-->00:28:37.516 a nonce and a counter. The nonce is going to be just a fixed length or rather, fixed piece, 00:28:37.516-->00:28:42.421 uh, of data. And then you have as counter which increments between each packet. You take 00:28:42.421-->00:28:47.459 your nonce and your counter that functions as your, inter- piece initialisation vector for the 00:28:47.459-->00:28:52.397 AES encryption. You encrypt that, you get your ciphertext, you XOR your data with that 00:28:52.397-->00:28:57.402 ciphertext and then that output data is sent, over the air, with the counter. Now, the expected 00:28:59.471-->00:29:05.210 behaviour is that the dongle would not accept the same counter twice so the idea is 00:29:05.210-->00:29:11.350 that you use a diff- essentially a different key between each packet but unfortunately many of 00:29:11.350-->00:29:15.887 these vendors accept the same counter twice. So, on the surface that allows you to do a 00:29:15.887-->00:29:21.093 simple replay attack. But some quirks about how the USB HID packets are formatted makes it 00:29:21.093-->00:29:26.231 possible to actually generate your own packets using this technique. So when you type a 00:29:26.231-->00:29:30.402 key on a keyboard it sends two packets: you have the first one is a keydown packet and then you 00:29:30.402-->00:29:34.573 have a keyup packet and they are going to go in quick succession, usually. So if you are observing 00:29:34.573-->00:29:40.512 this you can usually infer you have a keydown and keyup packet. The keydown packet is going to 00:29:40.512-->00:29:45.550 'tain, contain the scan code of the key you pressed but the keyup packet is all zeros. So 00:29:45.550-->00:29:49.821 what happens is, you are sending all zeros XORed with the ciphertext. That means the 00:29:49.821-->00:29:54.426 actual ciphertext going over the air, with the counter. And so you can actually just XOR that 00:29:54.426-->00:29:58.530 ciphertext with your arbitrary data, send it with that counter and inject your arbitrary 00:29:58.530-->00:30:03.568 injected keystrokes. And what's crazy is that most of these devices, the keyboards rather, 00:30:03.568-->00:30:08.774 reset their counter when you power cycle them. So it's difficult for the vendors who 00:30:08.774-->00:30:12.444 can update their dongle to do any kind of protocol fix because that would break keyboards out 00:30:12.444-->00:30:18.116 there in the field. This affects all of the Logitech Unifying keyboards, including the Dell 00:30:18.116-->00:30:24.923 KM714, the Dell KM632 keyboard, the Lenovo Ultraslim keyboard, Amazon Basics wireless keyboard, 00:30:24.923-->00:30:29.928 as well as the HP Wireless Elite version 2 keyboard. We notified the vendors in April and did the 00:30:34.566-->00:30:40.772 public disclosure last week. Logitech and Lenovo are both working on a fix, Dell fixed 00:30:40.772-->00:30:44.976 this by changing to a different protocol on their keyboard - which I haven't evaluated yet - 00:30:44.976-->00:30:49.715 they sent a keyboard for me to test and it is fact fixed for this specific vulnerability. No 00:30:49.715-->00:30:54.653 response from Amazon and HP was actually part of the November disclosure and did not 00:30:54.653-->00:31:01.326 acknowledge a vulnerability. Now we have the case of completely unencrypted protocols. And this 00:31:01.326-->00:31:05.330 is kinda crazy because you have devices that have come onto the market as recently as last year 00:31:05.330-->00:31:11.303 that have keyboards with zero encryption. We have three different types of transceivers 00:31:11.303-->00:31:16.374 that are common with these keyboards, and they're all, mostly, undocumented. So I was 00:31:16.374-->00:31:19.544 looking these devices and I was expecting that the first part of the process would be figuring 00:31:19.544-->00:31:23.582 out how the physical level works and what their packet formats are but after getting passed 00:31:23.582-->00:31:28.353 that first step it turned out they were just sending cleartext keystroke data. So we have 00:31:28.353-->00:31:30.355 MOSART semiconductor make transceivers in 6 of the vulnerable keyboards and this is 00:31:30.355-->00:31:32.357 just a, a simple GFSK, uh, no encryption, operates on a single channel. We have the Signia 00:31:32.357-->00:31:35.393 transceiver and a Toshiba keyboard and mouse set. This is another simple GFSK protocol 00:31:35.393-->00:31:37.395 with frequency hopping but, again, no encryption. And then we have this GE/Jasco keyboard. 00:31:37.395-->00:31:39.397 Now, GE has their brand on the keyboard but it's actually made by this company called Jasco who 00:31:39.397-->00:31:41.399 licenses the trademark from GE. I have no idea what the transceiver actually is in this 00:31:41.399-->00:31:43.401 thing except that it's 500 megahertz GFSK and no encryption. So all of these are 00:31:43.401-->00:31:45.403 vulnerable to keystroke sniffing and keystroke injection. So here's a list of devices we 00:31:45.403-->00:31:51.309 have: or the MOSART devices. We have devices from Anker, EagleTec, HP, Insignia, 00:31:51.309-->00:31:56.314 Kensington, RadioShack, Shhhmouse and HDE. All the vendors were notified in 00:32:18.970-->00:32:22.707 November, or rather in April, except for Shhhmouse, because they had, apparently no web 00:32:22.707-->00:32:27.779 presence and we were unable to find any contact details. The last two are mice, but they do 00:32:27.779-->00:32:33.385 use transceivers that have keyboard logic in them. So that means with normal operating 00:32:33.385-->00:32:36.988 behaviour they function as mice but you can still inject keystrokes into those dongles. 00:32:39.224-->00:32:43.728 Then we have the non-MOSART devices, this is the GE/Jasco keyboard. There is a Gigabyte 00:32:43.728-->00:32:47.766 keyboard that has an unencrypted Nordic ship in it and then the Toshiba keyboard. Again these 00:32:47.766-->00:32:53.238 are all vulnerable to keystroke sniffing and keystroke injection. Now what's 00:32:53.238-->00:32:56.675 interesting with the MOSART devices is that they are constantly beaconing to the 00:32:56.675-->00:33:02.147 keyboards. So they are sending these synchronization packets every 8 or 16 milliseconds and 00:33:02.147-->00:33:05.717 the keyboard, when you turn it on will look for the synchronisation packets and then 00:33:05.717-->00:33:11.590 lock on that TDMA timing. That means though, an attacker, even if users aren't at their 00:33:11.590-->00:33:16.294 computers can enter a room, or building and quickly survey for all of the computers using these 00:33:16.294-->00:33:20.899 unencrypted keyboards. Now, because all of these keyboards have unique identifiers that 00:33:20.899-->00:33:25.303 same attacker and also record keystrokes from everybody's keyboard if they are using these 00:33:25.303-->00:33:30.308 devices. We received responses from some of these vendors. Anker will be exchanging their 00:33:32.611-->00:33:37.616 vulnerable keyboards for bluetooth devices, due the end of this month. [applause] 00:33:42.721-->00:33:47.092 Kensington claims to have a new AES encrypted keyboard. I have not seen it or tested it . and 00:33:47.092-->00:33:51.563 the FCC docs show no, new keyboards this year. Insignia has told reporters that their 00:33:51.563-->00:33:56.401 keyboards are encrypted however they, at least the model that I have tested, is unencrypted. And 00:33:56.401-->00:34:01.339 then GE/Jasco is not longer producing wireless keyboards or mice and will therefor not be 00:34:05.377-->00:34:09.981 fixing the firmware. [applause] So, one question I've been asked a lot is, if I think there are 00:34:09.981-->00:34:14.619 other devices on the market with these same vulnerabilities, and I think there are because you 00:34:14.619-->00:34:19.591 have a lot of these devices that are white label hardware. So a company will go to an OEM, they 00:34:19.591-->00:34:24.496 will license this OEM's keyboard or mouse and put their brand on it. Ann the assumption is the 00:34:24.496-->00:34:27.799 with this white label hardware comes white label vulnerabilities so I'm going to 00:34:27.799-->00:34:32.804 highlight a few different of an OEM keyboard verse a vendor keyboard. So here we have the HP 00:34:34.906-->00:34:39.444 wireless classic desktop and the OEM equivalent on the right so here we have at least two copies 00:34:39.444-->00:34:45.250 of the same keyboard. Then we have the Amazon Basics wireless keyboard and mouse and then the 00:34:45.250-->00:34:50.121 OEM equivalent on the right. Now this OEM Chicony also makes the Dell KM632. The Amazon and the 00:34:50.121-->00:34:55.126 Dell have the same keystroke injection vulnerability so it's feasible that other Chicony 00:34:57.629-->00:35:03.401 devices might as well. Then we have the RadioShack wireless keyboard and the OEM equivalent 00:35:03.401-->00:35:07.672 on the right. And so the point is you have all of these OEM making this hardware, the vendor 00:35:07.672-->00:35:11.543 may not be aware of how these devices operate or what protocols they use and therefore 00:35:11.543-->00:35:16.281 they may have a lot of vulnerabilities out there that they are unaware of. So for 00:35:16.281-->00:35:21.186 doing these type of attacks I'm a big fan of using these Crazy radio dongles. This is part of 00:35:21.186-->00:35:25.790 the open source quadcopter project called Crazyflie and it has a nordic chip on it and also 00:35:25.790-->00:35:31.162 an amplifier. Using these we have been able to range test injection attacks into the 00:35:31.162-->00:35:37.469 Nordic based devices out to 225 meters away using one of these and a directional antenna. The 00:35:37.469-->00:35:43.108 firmware that comes with these it great but not good for these kinds of purposes so I built 00:35:43.108-->00:35:47.278 some open source firmware that you can flash onto these Crazy radio dongles and use them for 00:35:47.278-->00:35:53.351 generic transmission and reception of wireless packet and that's up on Github. The problem 00:35:53.351-->00:35:57.822 was that after Mousejack came out everybody went and bought these Crazy radio dongles. They 00:35:57.822-->00:36:02.761 got expensive and hard to find. So the Logitech Unifying dongles have the same transceiver but 00:36:05.230-->00:36:09.467 without an amplifier and so I figured out how Logitech does their firmware updates and so 00:36:09.467-->00:36:14.472 now you can flash my firmware directly onto Logitech dongles and it's just running [applause] 00:36:19.778-->00:36:23.281 and so you pull the firmware down, plugin in your Logitech dongle and run "sudo make 00:36:23.281-->00:36:27.552 Logitech install" and it flashes this onto your dongle. And these things are cheap, they are 00:36:27.552-->00:36:31.122 available. They don't have as good of range as the Crazy radio dongles, but they are still 00:36:31.122-->00:36:35.593 effective. Also I have a pocket full of these dongles and if you want one I am more than happy to 00:36:35.593-->00:36:40.598 give you one. Then we have an Android app that I produced that is able to do device detection. 00:36:42.701-->00:36:46.938 So you can plug a Logitech dongle into your Android phone and it will scan an area and 00:36:46.938-->00:36:51.976 classify devices based on the packet format. So classify mouse or keyboard or trackpad, or 00:36:51.976-->00:36:56.881 touchpad for Logitech and Microsoft devices and then identify without classification, 00:36:56.881-->00:37:02.520 other Nordic based devices. We will be releasing this in the very near future. So now we get 00:37:02.520-->00:37:06.725 to do some demos and for the demos this is kinda fun because I will be using using Logitech 00:37:06.725-->00:37:11.730 dongles to execute attacks against other Logitech dongles with this custom firmware. So I 00:37:19.771-->00:37:23.374 have this Logitech M510 mouse here with just the regular Logitech dongle which I will 00:37:23.374-->00:37:28.379 plug into this computer. And then in my other laptop here I have a Logitech dongle which is 00:37:35.553-->00:37:41.292 running my custom firmware, So the first attack I am going to do is this forced pairing and 00:37:41.292-->00:37:46.397 this allows us to force pair a new device with this Logitech dongle even though it's not in 00:37:46.397-->00:37:51.402 pairing mode. So I'll run that and we'll see a new device pop up momentarily here and the 00:38:00.211-->00:38:03.982 thing is, right now, this is showing up as a mouse. There's actually a number of device 00:38:03.982-->00:38:10.488 types we can it show up as so we'll, go do the, go do another demo here. This will be number 00:38:10.488-->00:38:15.493 two. And now we have a keyboard. But there are more device types yet. We can also do a number 00:38:20.098-->00:38:25.103 pad. And then, finally, then a presentation presentor. Now using these devices that we've 00:38:30.475-->00:38:34.412 paired we can now inject keystrokes directly into the addresses that have been 00:38:34.412-->00:38:38.850 populated on the dongle. So not we'll do a keystroke injection attack, targeting that first 00:38:38.850-->00:38:43.021 mouse that was paired. This will bring up an administrative command prompt then add a user 00:38:43.021-->00:38:48.026 on this machine. [applause] And if you'd like to see some more demos, I have some additional 00:39:13.585-->00:39:17.722 ones prepared that I can show you if you find me after the talk. Also I'm very, very happy 00:39:17.722-->00:39:20.925 to give you one of these Logitech dongles flashed with this custom firmware and tell 00:39:20.925-->00:39:25.930 you all about how this works. And now I have some time for questions. Yeah. [inaudible 00:39:33.004-->00:39:38.343 question from audience member] Ah, yeah. So for questions you need to come to this microphone 00:39:38.343-->00:39:43.348 up here. Yeah. >>So you said that the, um, the, um, the dongles got really expensive 00:39:50.321-->00:39:54.893 bec-, because people started buying all of them. Does this firmware work with the, the 00:39:54.893-->00:39:59.497 cheaps, Chinese copies of the, uh, Nordic chip? >>It should. I, I haven't tried it with any of 00:39:59.497-->00:40:03.768 the Chinese copies but, as long as they're compatible with a Nordic chip, then it should be 00:40:03.768-->00:40:08.773 fine. >>Okay >>First of all, thank you very much. It's very interesting... >>Thank you >>... 00:40:11.909-->00:40:18.049 I was wondering if you happened to check the Bluetooth side, um, controllers, ah, keyboard 00:40:18.049-->00:40:21.819 devices? >>Ah, hu, yeah. I'm sorry. Yeah I ah , I'm sorry, ah. I wasn't able to hear you. 00:40:21.819-->00:40:27.125 >>I. Okay. I said the thank you very much it was very interesting. And basically all 00:40:27.125-->00:40:32.797 our offices are compromised now. Uuum. I was wondering if you happened to check the bluetooth 00:40:32.797-->00:40:36.634 devices. >>Uh, I haven't looked at bluetooth devices, I've specifically been looking at 00:40:36.634-->00:40:41.639 proprietary protocols. >>Thank you very much. >>I was curious about the Logitech nano 00:40:44.375-->00:40:47.779 receivers and how they are different and if you've been able to find any exploits and 00:40:47.779-->00:40:51.182 attacks for them. >>I've only looked at one of those and it's a similar protocol, but I 00:40:51.182-->00:40:56.955 haven't explored it for any kind of vulnerabilities. >>Okay, thank you. >>Why doesn't the, 00:40:56.955-->00:41:03.795 why doesn't the bluetooth aah. Why aren't the bluetooth mouse or peripherals vulnerable? >>Um, 00:41:03.795-->00:41:08.132 so these are specific to vendor implementations of these proprietary protocols but I just 00:41:08.132-->00:41:13.137 haven't looked at any bluetooth devices. >>Okay, great. >>[inaudible] >>I was just. I 00:41:15.707-->00:41:20.645 was just wondering about how many of, like percentage-wise, of these type of devices are not 00:41:20.645-->00:41:25.316 patchable at all because of the lack of ability for firmware updates. >>So. Most of the 00:41:25.316-->00:41:29.787 devices cannot be updated. The Logitech Unifying dongles can be, but by and large, everything 00:41:29.787-->00:41:36.094 else cannot be patched. >All right, thank you very much. >>Uh, you mentioned pairing, ah, 00:41:36.094-->00:41:40.298 devices or doing the forced pairing you would use the existing address of the previous 00:41:40.298-->00:41:43.701 devices. Will that old device keep working? After forced pairing? >>Yeah. So what happens 00:41:43.701-->00:41:47.171 is the old device keeps working and then it just generates a new address for the new device. 00:41:47.171-->00:41:52.176 >>All right. Cool. Thanks. >>Yeah. >>[inaudible] >>I was just wondering why no Macs were 00:41:59.050-->00:42:03.187 involved in this testing. Is there... any implementation or de- is there... reason why... 00:42:03.187-->00:42:06.691 >>So the, the keystroke injection vulnerabilities do work on Apple computers for 00:42:06.691-->00:42:09.694 these devices, but I haven't looked at any of the Apple hardware... >>Oh... >>... for 00:42:09.694-->00:42:14.699 the Apple keyboards and mice. >>... oh, okay... >>Yeah. >>... thank you. >>Okay. Well thank 00:42:22.306-->00:42:27.311 you guys. [applause and cheering] All right, I'm sorry. I think we'll have to go out to 00:42:29.981-->00:42:34.085 the hall for the passouts and dongles here so let me just pack up real quick.