1 00:00:01,740 --> 00:00:03,840 - Well, hi everyone again. 2 00:00:03,840 --> 00:00:05,100 And welcome to this talk, 3 00:00:05,100 --> 00:00:06,840 which is about one vulnerability 4 00:00:06,840 --> 00:00:09,510 that we have found in Microsoft Windows, 5 00:00:09,510 --> 00:00:14,510 that allows an attacker to inject key strokes, 6 00:00:14,938 --> 00:00:19,938 impersonating, previously paired, the legitimate keyboard. 7 00:00:22,050 --> 00:00:25,740 But before going farther in the presentation, 8 00:00:25,740 --> 00:00:29,160 let us try to get your attention 9 00:00:29,160 --> 00:00:31,980 and put the cart before the horses, 10 00:00:31,980 --> 00:00:36,690 and show you this very, very accelerated version 11 00:00:36,690 --> 00:00:40,200 of our demo video. 12 00:00:40,200 --> 00:00:42,660 And please pay attention because it's gonna get, 13 00:00:42,660 --> 00:00:43,660 it's gonna be quick. 14 00:00:44,762 --> 00:00:46,080 This is the scenario. 15 00:00:46,080 --> 00:00:48,780 This is the legitimate keyboard going disconnected. 16 00:00:48,780 --> 00:00:50,790 Then this is the attacker launching the attack. 17 00:00:50,790 --> 00:00:53,070 And then as soon as the attacker launches the attack, 18 00:00:53,070 --> 00:00:56,220 the fake device is going to be present in this space. 19 00:00:56,220 --> 00:00:59,070 And then the Windows box connects to the fake device 20 00:00:59,070 --> 00:01:00,873 and the keys get injected. 21 00:01:02,105 --> 00:01:05,105 (audience applauds) 22 00:01:08,430 --> 00:01:11,160 We hope that everything is clear for everyone, 23 00:01:11,160 --> 00:01:12,420 but if it is not, 24 00:01:12,420 --> 00:01:14,983 we have the rest of the talk to try to explain it to you. 25 00:01:14,983 --> 00:01:16,469 (audience chuckles) 26 00:01:16,469 --> 00:01:18,570 So please be with us. 27 00:01:18,570 --> 00:01:23,163 And hopefully we explain it right to you. 28 00:01:25,830 --> 00:01:29,700 - Hello everyone. Now I try to explain the video again, 29 00:01:29,700 --> 00:01:33,480 but this time, slowly. 30 00:01:33,480 --> 00:01:36,487 So the first thing we need to know is: 31 00:01:36,487 --> 00:01:38,760 Who are the participants in the video? 32 00:01:38,760 --> 00:01:41,050 And we have a Windows PC here, 33 00:01:41,050 --> 00:01:42,720 Bluetooth Low Energy keyboard, 34 00:01:42,720 --> 00:01:46,170 and the attacker that are using Linux PC 35 00:01:46,170 --> 00:01:48,300 with a special dongle. 36 00:01:48,300 --> 00:01:49,800 Before the video starts, 37 00:01:49,800 --> 00:01:51,390 a Bluetooth Low Energy keyboard 38 00:01:51,390 --> 00:01:56,334 and the Windows PC perform the Bluetooth pairing 39 00:01:56,334 --> 00:02:01,334 in order to establish an encrypted channel 40 00:02:01,740 --> 00:02:03,810 and all the data that are, 41 00:02:03,810 --> 00:02:06,123 they are communicating, are encrypted. 42 00:02:07,797 --> 00:02:11,050 So every time that the Bluetooth Low Energy keyboard 43 00:02:12,270 --> 00:02:14,433 re-connects with the Windows PC, 44 00:02:15,510 --> 00:02:19,920 the encryption channel, encrypted channel, is established 45 00:02:19,920 --> 00:02:23,313 and all the data will be encrypted. 46 00:02:24,990 --> 00:02:27,600 As the Bluetooth Low Energy keyboard is 47 00:02:27,600 --> 00:02:31,560 a low-energy device, after a few period, 48 00:02:31,560 --> 00:02:33,984 after a little period of time, 49 00:02:33,984 --> 00:02:38,130 the keyboard disconnects in order to save some energy 50 00:02:38,130 --> 00:02:40,620 and it is in this moment when an attacker 51 00:02:40,620 --> 00:02:44,310 could impersonate the Bluetooth Low Energy keyboard 52 00:02:44,310 --> 00:02:48,690 and send some key strokes, some not encrypted key strokes. 53 00:02:48,690 --> 00:02:50,760 But how is this possible? 54 00:02:50,760 --> 00:02:54,867 Because, we said before that the Windows PC 55 00:02:54,867 --> 00:02:58,830 and the keyboard establish an encryption channel 56 00:02:58,830 --> 00:03:01,209 every time that it re-connects, 57 00:03:01,209 --> 00:03:06,209 we send not encrypted data and are accepted by the Window, 58 00:03:06,630 --> 00:03:10,987 by the Windows. So that's what this story is about. 59 00:03:10,987 --> 00:03:14,010 And let's start from the beginning. 60 00:03:14,010 --> 00:03:15,900 He is José, and I'm Fernando. 61 00:03:15,900 --> 00:03:17,370 We are security researchers. 62 00:03:17,370 --> 00:03:19,500 We like to play with security 63 00:03:19,500 --> 00:03:21,300 and with communication protocols, 64 00:03:21,300 --> 00:03:23,580 we also climb and ride motor bikes, 65 00:03:23,580 --> 00:03:26,730 as you could see in the photo, in our spare time. 66 00:03:26,730 --> 00:03:30,090 We come from Spain and work in Layakk. 67 00:03:30,090 --> 00:03:33,009 And what we saw in this talk, 68 00:03:33,009 --> 00:03:36,341 we start with a brief description 69 00:03:36,341 --> 00:03:39,090 of Bluetooth Low Energy concepts. 70 00:03:39,090 --> 00:03:41,560 Some concepts only in order to 71 00:03:43,680 --> 00:03:46,023 understand better the vulnerability. 72 00:03:46,860 --> 00:03:51,420 Now, then we detail how this attack is possible. 73 00:03:51,420 --> 00:03:55,650 And what parts of the specs, of the Bluetooth specs 74 00:03:55,650 --> 00:04:00,000 and Windows allow this attack. 75 00:04:00,000 --> 00:04:03,060 Then we show you two approaches of how we try 76 00:04:03,060 --> 00:04:05,310 to exploit this vulnerability, 77 00:04:05,310 --> 00:04:06,810 and the first one doesn't work. 78 00:04:06,810 --> 00:04:10,233 And the second approach is the current exploit. 79 00:04:11,564 --> 00:04:13,890 We continue with the proof of concepts, 80 00:04:13,890 --> 00:04:16,271 showing all the hardware and software that we need 81 00:04:16,271 --> 00:04:21,271 to perform the attack and some demos and conclude this talk, 82 00:04:23,400 --> 00:04:25,680 showing some data about the vulnerability disclosure, 83 00:04:25,680 --> 00:04:30,210 some related publications and reference that help us to find 84 00:04:30,210 --> 00:04:31,043 and display this vulnerability. 85 00:04:31,043 --> 00:04:33,486 (mouse clicks) 86 00:04:34,320 --> 00:04:35,640 - As you will see during the talk, 87 00:04:35,640 --> 00:04:38,430 the attack is extremely simple, 88 00:04:38,430 --> 00:04:41,130 but we think that it's important 89 00:04:41,130 --> 00:04:44,042 to introduce some Bluetooth Low Energy concepts 90 00:04:44,042 --> 00:04:47,070 that help to understand the attack, 91 00:04:47,070 --> 00:04:48,450 especially if you're not familiar 92 00:04:48,450 --> 00:04:49,890 with the Bluetooth protocols. 93 00:04:49,890 --> 00:04:51,270 And the first one of these concept 94 00:04:51,270 --> 00:04:52,980 is this concept of pairing. 95 00:04:52,980 --> 00:04:54,870 When two Bluetooth devices want 96 00:04:54,870 --> 00:04:57,660 to protect their communications, 97 00:04:57,660 --> 00:05:01,920 they must finish this pairing procedure as they call it. 98 00:05:01,920 --> 00:05:05,760 The objective of this procedure is to establish a key, 99 00:05:05,760 --> 00:05:07,350 which is called the Long Term Key. 100 00:05:07,350 --> 00:05:09,930 That will be used, by the way, 101 00:05:09,930 --> 00:05:12,480 this is only performed the first time they connect, 102 00:05:12,480 --> 00:05:15,750 and then they keep this long, long term key 103 00:05:15,750 --> 00:05:17,400 and they use it every time that they want, 104 00:05:17,400 --> 00:05:19,200 they want to connect to each other again, 105 00:05:19,200 --> 00:05:20,670 to derive a session key. 106 00:05:20,670 --> 00:05:21,810 That is the key that is going to 107 00:05:21,810 --> 00:05:23,670 protect this particular connection. 108 00:05:23,670 --> 00:05:26,130 We are not talking about the different pairing schemes 109 00:05:26,130 --> 00:05:27,300 or association models, 110 00:05:27,300 --> 00:05:28,890 because they're not relevant for the attack. 111 00:05:28,890 --> 00:05:31,893 We just left them here for your reference. 112 00:05:33,030 --> 00:05:36,210 But we do want to talk about another concept, 113 00:05:36,210 --> 00:05:38,883 about Bluetooth Low Energy protocols. 114 00:05:39,829 --> 00:05:43,110 Is that the layers, 115 00:05:43,110 --> 00:05:46,320 the layer set is split into two parts. 116 00:05:46,320 --> 00:05:51,090 The host part, which holds the upper part of the protocol, 117 00:05:51,090 --> 00:05:53,220 which contains the LTK protocol. 118 00:05:53,220 --> 00:05:57,600 Also the ATT protocol that manages and shows 119 00:05:57,600 --> 00:06:00,990 and interacts with the attributes of every device. 120 00:06:00,990 --> 00:06:03,930 This upper part talks with the application layer, 121 00:06:03,930 --> 00:06:05,910 which is above it. In our case, 122 00:06:05,910 --> 00:06:08,010 the application layer will be the HID, 123 00:06:08,010 --> 00:06:09,930 the Human Interface Device, 124 00:06:09,930 --> 00:06:13,980 which is because we are attacking a keyboard. 125 00:06:13,980 --> 00:06:17,040 And the lower part of the protocol layers 126 00:06:17,040 --> 00:06:18,600 are called the controller one. 127 00:06:18,600 --> 00:06:21,990 And you will find several different configurations of that. 128 00:06:21,990 --> 00:06:24,030 For example, in the keyboard case, 129 00:06:24,030 --> 00:06:26,520 you'll find that the host and the controller are both 130 00:06:26,520 --> 00:06:28,620 implemented in the keyboard. But for example, 131 00:06:28,620 --> 00:06:31,957 if we are talking about a windows box or a Linux box, 132 00:06:31,957 --> 00:06:35,940 the host is implemented in the operating system. 133 00:06:35,940 --> 00:06:37,320 For example, you have Linux, 134 00:06:37,320 --> 00:06:39,778 the host is the blue set implementation of that. 135 00:06:39,778 --> 00:06:43,020 And the controller is implemented in the firmware 136 00:06:43,020 --> 00:06:44,400 of the device that you're using, 137 00:06:44,400 --> 00:06:46,860 either an embedded device or cheap set 138 00:06:46,860 --> 00:06:49,389 or an external dongle. 139 00:06:49,389 --> 00:06:51,300 This firmware implements the controller. 140 00:06:51,300 --> 00:06:53,820 The communication between these two parts 141 00:06:53,820 --> 00:06:55,950 is very straightly forward 142 00:06:55,950 --> 00:06:59,040 called Host to Controller Interface, HCI, 143 00:06:59,040 --> 00:07:03,660 and the host sends information to the controller 144 00:07:03,660 --> 00:07:08,010 by one thing, that is called commands. 145 00:07:08,010 --> 00:07:10,680 And the controller sends the host events. 146 00:07:10,680 --> 00:07:12,750 That is just a question of names, 147 00:07:12,750 --> 00:07:14,250 but one of the important things, 148 00:07:14,250 --> 00:07:16,740 or one of the things that we want to emphasize here, 149 00:07:16,740 --> 00:07:19,663 is that encryption happens at the link layer. 150 00:07:19,663 --> 00:07:23,820 So the host part doesn't do anything about encryption 151 00:07:23,820 --> 00:07:26,160 except maybe, no, not maybe, 152 00:07:26,160 --> 00:07:29,220 except just managing the state of the encryption 153 00:07:29,220 --> 00:07:30,858 and calculating the Long Term Key. And that's all. 154 00:07:30,858 --> 00:07:34,110 And whenever the link layer needs the Long Term Key 155 00:07:34,110 --> 00:07:35,670 to calculate the session key, 156 00:07:35,670 --> 00:07:37,529 then the host part provides this long-term key. 157 00:07:37,529 --> 00:07:40,320 So this is a very important concept, 158 00:07:40,320 --> 00:07:42,720 and you will see why during our presentation, 159 00:07:42,720 --> 00:07:46,020 because it's very directly related with the attack. 160 00:07:46,020 --> 00:07:49,410 And we have still one more concept to introduce to you 161 00:07:49,410 --> 00:07:50,430 before explaining the attack, 162 00:07:50,430 --> 00:07:54,300 which is, let's imagine this is scenario where 163 00:07:54,300 --> 00:07:57,428 we have the master device and we are using here, 164 00:07:57,428 --> 00:08:01,080 the Bluetooth file that used specification terminology. 165 00:08:01,080 --> 00:08:02,310 In our case, in our scenario, 166 00:08:02,310 --> 00:08:05,190 the master device is the Windows machine. 167 00:08:05,190 --> 00:08:06,957 And we have the slave device in our scenario, 168 00:08:06,957 --> 00:08:10,680 the slave device, is a Bluetooth Low Energy keyboard. 169 00:08:10,680 --> 00:08:12,810 And we have the situation here. 170 00:08:12,810 --> 00:08:14,850 The start point is the situation where 171 00:08:14,850 --> 00:08:17,580 these two devices have previously paired, 172 00:08:17,580 --> 00:08:19,890 completed the pairing procedure that I told you before. 173 00:08:19,890 --> 00:08:21,840 So they both have the Long Term Key associated 174 00:08:21,840 --> 00:08:25,380 with this connection, and they want to reconnect. 175 00:08:25,380 --> 00:08:27,178 They want to create a new connection. 176 00:08:27,178 --> 00:08:29,460 And we are going to see right now, 177 00:08:29,460 --> 00:08:32,580 what happens here and how does it work? 178 00:08:32,580 --> 00:08:36,330 So the host part of the master instructs 179 00:08:36,330 --> 00:08:37,890 the link layer to create a connection. 180 00:08:37,890 --> 00:08:40,110 It just provokes in the link layer 181 00:08:40,110 --> 00:08:42,330 that the link layer starts listening 182 00:08:42,330 --> 00:08:46,890 for the slave to appear in the air. And more particularly, 183 00:08:46,890 --> 00:08:49,701 to advertising messages from this slave. 184 00:08:49,701 --> 00:08:51,450 The slave is sleeping right now, 185 00:08:51,450 --> 00:08:54,570 because he went to sleep to save energy. 186 00:08:54,570 --> 00:08:58,200 And he restarts whenever the user presses a key. 187 00:08:58,200 --> 00:09:01,230 And then it provokes that the host informs or instructs 188 00:09:01,230 --> 00:09:03,862 the link layer to start advertising himself 189 00:09:03,862 --> 00:09:07,560 with this command set, advertising enabled. 190 00:09:07,560 --> 00:09:11,732 And then eventually one of these advertising messages 191 00:09:11,732 --> 00:09:14,610 gets to the link layer of the master. 192 00:09:14,610 --> 00:09:17,853 And then the master answers back with a connect indication, 193 00:09:18,990 --> 00:09:21,720 link layer message to the link layer of the slave. 194 00:09:21,720 --> 00:09:25,470 Please see that this, everything happens at the link layer. 195 00:09:25,470 --> 00:09:27,360 So the host is only participating 196 00:09:27,360 --> 00:09:30,489 in the controlling part of the state of protocol. 197 00:09:30,489 --> 00:09:32,940 At this point of the protocol, 198 00:09:32,940 --> 00:09:34,571 the connection has been created 199 00:09:34,571 --> 00:09:37,579 and both link layer inform their correspondent, 200 00:09:37,579 --> 00:09:40,950 a host part, that the connection has been created. 201 00:09:40,950 --> 00:09:43,380 The connection is created, but it's not encrypted. 202 00:09:43,380 --> 00:09:46,560 Not encrypted yet. This is what is going to happen now. 203 00:09:46,560 --> 00:09:48,720 The master that holds the long term key knows 204 00:09:48,720 --> 00:09:50,370 that this connection should be encrypted. 205 00:09:50,370 --> 00:09:53,516 So as soon as the connection is created, it should, 206 00:09:53,516 --> 00:09:57,540 and it usually does, it instructs the link layer 207 00:09:57,540 --> 00:09:59,010 to start encryption. 208 00:09:59,010 --> 00:10:02,700 Then at this point, the link layer calculates its part, 209 00:10:02,700 --> 00:10:05,280 the master part of two random values, 210 00:10:05,280 --> 00:10:07,710 The SKD, which is the Session Key Diversifier 211 00:10:07,710 --> 00:10:09,570 and analyzation vector. 212 00:10:09,570 --> 00:10:12,293 This to, this part is sent to the slave, 213 00:10:12,293 --> 00:10:13,140 to the link layer of the slave, 214 00:10:13,140 --> 00:10:15,450 with the encryption request PDU. 215 00:10:15,450 --> 00:10:19,080 And the slave calculates is part of these values. 216 00:10:19,080 --> 00:10:21,570 And send back it with the encryption response PDU 217 00:10:21,570 --> 00:10:23,523 to the link layer of the master. 218 00:10:24,570 --> 00:10:29,010 If you think there is one thing left is that 219 00:10:29,010 --> 00:10:31,650 the slave does not have the long term key. 220 00:10:31,650 --> 00:10:33,360 The master, the link layer of the master, 221 00:10:33,360 --> 00:10:35,691 do have the long term key because it has been provided 222 00:10:35,691 --> 00:10:38,250 with the enabled encryption command. 223 00:10:38,250 --> 00:10:39,600 But the slave doesn't have that. 224 00:10:39,600 --> 00:10:42,000 So it has to ask for it. 225 00:10:42,000 --> 00:10:45,000 And if the slave has, if the host of the slave 226 00:10:45,000 --> 00:10:46,799 has the Long Term Key, which is the case, 227 00:10:46,799 --> 00:10:49,560 it will answer back with the Long Term Key. 228 00:10:49,560 --> 00:10:50,393 At this point, 229 00:10:50,393 --> 00:10:53,940 both devices can calculate the Session Key Diversifier 230 00:10:53,940 --> 00:10:57,480 because they have both parts and the analyzation vector, 231 00:10:57,480 --> 00:11:02,480 which I just remind you that these are random numbers, okay, 232 00:11:02,880 --> 00:11:05,250 and they both can calculate the session key 233 00:11:05,250 --> 00:11:08,640 that is going to protect this particular connection. 234 00:11:08,640 --> 00:11:10,740 The session key is calculated by encrypting 235 00:11:10,740 --> 00:11:14,160 the Session Key Diversifier, using as encryption key, 236 00:11:14,160 --> 00:11:16,680 the long-term key and as an initialization vector, 237 00:11:16,680 --> 00:11:19,230 they calculated initialization vector. 238 00:11:19,230 --> 00:11:22,470 So at this point, both have calculated the session key. 239 00:11:22,470 --> 00:11:26,420 And the only thing that left to finish the encryption, 240 00:11:26,420 --> 00:11:27,720 to the start encryption procedure, 241 00:11:27,720 --> 00:11:31,680 let's say that, is to let's say, 242 00:11:31,680 --> 00:11:35,760 agree on the point in time where the encryption starts. 243 00:11:35,760 --> 00:11:38,250 And this is made with this kind of handshake. 244 00:11:38,250 --> 00:11:40,863 We, you say that, 245 00:11:42,360 --> 00:11:44,820 that starts with a start encryption request command, 246 00:11:44,820 --> 00:11:48,330 sent not encrypted by the link layer, and then, sorry, 247 00:11:48,330 --> 00:11:49,890 by the link layer of the slave, 248 00:11:49,890 --> 00:11:51,540 then the link layer of the master 249 00:11:51,540 --> 00:11:53,850 answers back with a standard encryption response. 250 00:11:53,850 --> 00:11:55,890 And this message is already been 251 00:11:55,890 --> 00:11:58,890 encrypted with the session key. Okay? 252 00:11:58,890 --> 00:12:01,080 So, if the slave receives this message 253 00:12:01,080 --> 00:12:03,391 and it is able to decrypt it, 254 00:12:03,391 --> 00:12:06,450 then it's, so to speak, kind of 255 00:12:06,450 --> 00:12:08,970 authentication of this master. 256 00:12:08,970 --> 00:12:11,292 And it does exactly the same thing, 257 00:12:11,292 --> 00:12:13,320 encrypt this encryption response command 258 00:12:13,320 --> 00:12:17,280 with this just calculated section key. 259 00:12:17,280 --> 00:12:19,950 And so both are, let's say authenticated, 260 00:12:19,950 --> 00:12:24,480 and the connection is encrypted, is protected. 261 00:12:24,480 --> 00:12:26,100 At this point, it's very important. 262 00:12:26,100 --> 00:12:27,510 And this is very, very important 263 00:12:27,510 --> 00:12:28,770 for the attack that we are explaining here, 264 00:12:28,770 --> 00:12:30,960 is that at this point, the link layer 265 00:12:30,960 --> 00:12:34,233 informs the host that the encryption has started. 266 00:12:35,430 --> 00:12:37,590 And it's at this point that encryption has started, 267 00:12:37,590 --> 00:12:38,523 and not before. 268 00:12:40,140 --> 00:12:43,440 And you will understand just in a couple of slides, 269 00:12:43,440 --> 00:12:46,167 that's why I'm emphasizing this. 270 00:12:46,167 --> 00:12:49,800 Every next, or every subsequent PDUs 271 00:12:49,800 --> 00:12:51,300 will be encrypted from now on, 272 00:12:51,300 --> 00:12:53,910 for this particular connection. 273 00:12:53,910 --> 00:12:57,420 So we've seen these three or four concepts 274 00:12:57,420 --> 00:12:58,830 of about Bluetooth. 275 00:12:58,830 --> 00:13:00,630 And now we are going to explain 276 00:13:00,630 --> 00:13:02,541 how it is possible to inject this 277 00:13:02,541 --> 00:13:05,250 with all these contexts that we have explained. 278 00:13:05,250 --> 00:13:09,677 So, what makes the attack possible? 279 00:13:09,677 --> 00:13:12,930 In fact, there are two things that make the attack possible. 280 00:13:12,930 --> 00:13:14,649 The first thing is one thing that, 281 00:13:14,649 --> 00:13:18,870 we don't call it a vulnerability. 282 00:13:18,870 --> 00:13:21,600 It's something that is present in explicitly defined 283 00:13:21,600 --> 00:13:24,180 in the specification, in the Bluetooth standard. 284 00:13:24,180 --> 00:13:27,510 And it's the fact that when the slave, sorry, 285 00:13:27,510 --> 00:13:30,980 when slave device receives the encryption request, PDU, 286 00:13:30,980 --> 00:13:33,570 it is explicitly allowed to send, 287 00:13:33,570 --> 00:13:37,290 any remaining PDUs that he has to send to the master. 288 00:13:37,290 --> 00:13:39,423 And he has in his queues in a non-encrypted, 289 00:13:39,423 --> 00:13:42,510 in a not encrypted way. It's explicitly allowed. 290 00:13:42,510 --> 00:13:45,180 And I can show you the part of the standard 291 00:13:45,180 --> 00:13:48,840 where this is written, written down. 292 00:13:48,840 --> 00:13:52,440 This is from our point of view, this is not a vulnerability. 293 00:13:52,440 --> 00:13:55,920 It's just something that is there to allow the slave to 294 00:13:55,920 --> 00:13:59,610 empty its queues, before continuing to send in encrypted, 295 00:13:59,610 --> 00:14:03,003 encrypted PDUs, or encrypted data. 296 00:14:03,960 --> 00:14:05,490 But the second one, the second thing 297 00:14:05,490 --> 00:14:07,650 that allows the attack, this is the vulnerability. 298 00:14:07,650 --> 00:14:12,030 Sorry, before that, what I wanted to say 299 00:14:12,030 --> 00:14:16,260 in this slide, is that this characteristic 300 00:14:16,260 --> 00:14:18,900 that I just explained, creates 301 00:14:18,900 --> 00:14:22,170 a window of opportunity for an attacker, 302 00:14:22,170 --> 00:14:24,720 trying to impersonate this slave device. 303 00:14:24,720 --> 00:14:29,720 Where he can send data through the connection, 304 00:14:30,000 --> 00:14:33,600 through the Bluetooth connection and the master, sorry, 305 00:14:33,600 --> 00:14:38,070 the link layer of the master will accept this PDU. 306 00:14:38,070 --> 00:14:40,560 These PDUs. Will accept this data, 307 00:14:40,560 --> 00:14:42,480 and it's the responsibility of the upper part 308 00:14:42,480 --> 00:14:47,010 of the protocol to consider that this data is valid or not. 309 00:14:47,010 --> 00:14:49,410 And this is precisely the second thing 310 00:14:49,410 --> 00:14:51,840 that allows the attack, which is the vulnerability. 311 00:14:51,840 --> 00:14:53,635 It seems that Microsoft Windows 312 00:14:53,635 --> 00:14:56,520 does not wait for this event, which is 313 00:14:56,520 --> 00:14:59,610 the encryption change event, does not wait for this event, 314 00:14:59,610 --> 00:15:04,413 to consider that any PDU coming from the slave, it's legit. 315 00:15:05,430 --> 00:15:08,910 So it seems that it considers that encryption has started 316 00:15:08,910 --> 00:15:10,967 as soon as the host part of the master 317 00:15:10,967 --> 00:15:13,293 orders the encryption to start. 318 00:15:14,160 --> 00:15:15,660 Which is not the case. You have to wait 319 00:15:15,660 --> 00:15:18,630 until receiving this encryption change event. 320 00:15:18,630 --> 00:15:23,040 So this allows us to try to impersonate the slave 321 00:15:23,040 --> 00:15:26,160 up to this point and send all these unencrypted PDUs 322 00:15:26,160 --> 00:15:28,170 without actually knowing the Long Term Key, 323 00:15:28,170 --> 00:15:30,390 which will be needed to really 324 00:15:30,390 --> 00:15:32,970 complete this procedure of starting encryption. 325 00:15:32,970 --> 00:15:34,830 And this is the thing that allow the attack. 326 00:15:34,830 --> 00:15:37,013 This is the two things that allow the attack. 327 00:15:39,510 --> 00:15:42,180 - Okay. Now we will explain 328 00:15:42,180 --> 00:15:45,060 the two approaches that we follow 329 00:15:45,060 --> 00:15:48,330 in order to try to exploit this vulnerability. 330 00:15:48,330 --> 00:15:50,200 As I said before, the first one 331 00:15:51,103 --> 00:15:53,013 is working at the host level. 332 00:15:54,210 --> 00:15:58,290 Work with the host level has a very big problem 333 00:15:58,290 --> 00:16:02,820 that we don't decide when the message are really sent. 334 00:16:02,820 --> 00:16:05,640 We only tell the controller part to 335 00:16:05,640 --> 00:16:09,813 send some data to, some high level data, 336 00:16:09,813 --> 00:16:14,813 but we doesn't decide where exactly this data is sent. 337 00:16:16,770 --> 00:16:20,910 We are trying to put some PDUs 338 00:16:20,910 --> 00:16:23,970 between the encryption request and encryption response, 339 00:16:23,970 --> 00:16:28,770 and we couldn't decide where the PDUs 340 00:16:28,770 --> 00:16:33,679 we try to send are exactly put. 341 00:16:33,679 --> 00:16:37,650 And to implement this approach, 342 00:16:37,650 --> 00:16:40,410 We use an HCI adapter, a common HCI adapter, 343 00:16:40,410 --> 00:16:43,080 with the only particularity that 344 00:16:43,080 --> 00:16:45,750 it allows to change the VD address 345 00:16:45,750 --> 00:16:49,037 in order to impersonate the Bluetooth keyboard 346 00:16:49,037 --> 00:16:51,210 and use the Mirage framework. 347 00:16:51,210 --> 00:16:54,639 The Mirage framework is, among other things, 348 00:16:54,639 --> 00:16:57,300 allows among other things, to hook some parts 349 00:16:57,300 --> 00:16:59,070 of the communication, and change 350 00:16:59,070 --> 00:17:02,520 the normal flow of this communication. 351 00:17:02,520 --> 00:17:07,520 And we use it to intercept the connection event. 352 00:17:08,550 --> 00:17:12,450 And after this event, we start to send keystrokes 353 00:17:12,450 --> 00:17:15,213 and doesn't send anything else. 354 00:17:17,517 --> 00:17:22,517 As I'd said that, we doesn't decide 355 00:17:24,044 --> 00:17:29,044 where the message are effectively sent. 356 00:17:29,520 --> 00:17:31,620 We need some tries to succeed, 357 00:17:31,620 --> 00:17:33,953 and put some of these key strokes 358 00:17:33,953 --> 00:17:36,870 between the encryption request and encryption response. 359 00:17:36,870 --> 00:17:40,680 And now we will show you some captured in the air. 360 00:17:40,680 --> 00:17:45,070 We just sniffle to capture this message, 361 00:17:47,249 --> 00:17:50,100 that is a Bluetooth, low energy sniffer. 362 00:17:50,100 --> 00:17:54,747 In the left side, you could see the, hm, la direction? 363 00:17:54,747 --> 00:17:55,680 - La direction. 364 00:17:55,680 --> 00:17:57,330 - The direction of the communication, 365 00:17:57,330 --> 00:17:59,670 master to slave or a slave to master. 366 00:17:59,670 --> 00:18:03,240 And as I say, the connect request 367 00:18:03,240 --> 00:18:06,210 is sent by the master and received by the slave. 368 00:18:06,210 --> 00:18:10,680 And just after that, we start sending key strokes, 369 00:18:10,680 --> 00:18:14,700 but you can see that there are some link layer message 370 00:18:14,700 --> 00:18:16,803 that we have not control, and are sent. 371 00:18:18,780 --> 00:18:20,790 And then the normal flow of the communication 372 00:18:20,790 --> 00:18:22,380 on the start-an-encryption request 373 00:18:22,380 --> 00:18:26,493 is received by the fake slave, by the slave. 374 00:18:27,464 --> 00:18:32,464 And the slave is trying to send more key strokes. 375 00:18:34,290 --> 00:18:37,650 Then the controller part of the fake slave 376 00:18:37,650 --> 00:18:41,400 respond automatically with an encryption response 377 00:18:41,400 --> 00:18:43,053 and ask for the Long Term Key. 378 00:18:44,100 --> 00:18:45,900 As we haven't got the Long Term Key, 379 00:18:45,900 --> 00:18:49,800 the key missing is sent back to the controller 380 00:18:49,800 --> 00:18:54,800 and it is translated to link layer indication. 381 00:18:55,260 --> 00:18:57,360 Once master received this message, 382 00:18:57,360 --> 00:19:00,060 it closed the connection immediately, 383 00:19:00,060 --> 00:19:05,060 because the encryption channel could not be established. 384 00:19:05,910 --> 00:19:10,910 And our fake slave, continue trying to send some keystrokes. 385 00:19:11,947 --> 00:19:16,860 The most important thing in these slides 386 00:19:16,860 --> 00:19:18,780 is to understand that we are trying 387 00:19:18,780 --> 00:19:21,300 to send a lot of key strokes between 388 00:19:21,300 --> 00:19:23,220 encryption request and encryption response. 389 00:19:23,220 --> 00:19:26,310 And as we have good control about 390 00:19:26,310 --> 00:19:31,200 when the H level that is sent, 391 00:19:31,200 --> 00:19:34,350 we can decide that these key strokes hit 392 00:19:34,350 --> 00:19:36,660 between encryption requests and encryption response. 393 00:19:36,660 --> 00:19:41,660 There are only one notification message that hit there, 394 00:19:41,852 --> 00:19:45,960 and it means that there are only one key stroke that are 395 00:19:45,960 --> 00:19:50,430 effectively injected and processed by the master. 396 00:19:50,430 --> 00:19:53,109 So we realized that if we want to 397 00:19:53,109 --> 00:19:56,130 exploit this vulnerability, 398 00:19:56,130 --> 00:19:59,490 we should go down and develop something 399 00:19:59,490 --> 00:20:02,163 that works in the controller level. 400 00:20:03,930 --> 00:20:05,760 - And this is what we did. 401 00:20:05,760 --> 00:20:08,100 And this is the actually implementation of the attack. 402 00:20:08,100 --> 00:20:10,500 We implemented the attack at the link layer level, 403 00:20:10,500 --> 00:20:13,713 at the controller level. In order to do that, we use this, 404 00:20:14,760 --> 00:20:16,380 let me say that's fantastic framework, 405 00:20:16,380 --> 00:20:18,090 which is called the Zephyr. 406 00:20:18,090 --> 00:20:21,390 It's completely, from top to bottom, 407 00:20:21,390 --> 00:20:23,310 open-source implementation of the Bluetooth 408 00:20:23,310 --> 00:20:25,080 Low-energy protocol stack. 409 00:20:25,080 --> 00:20:27,630 So this, you can compile that, 410 00:20:27,630 --> 00:20:29,460 and create a firmware that can run in one 411 00:20:29,460 --> 00:20:34,273 of these dongles, which is a Nordic RF, 50 52 H40. 412 00:20:34,273 --> 00:20:39,273 That has part no very, very, very few costs. 413 00:20:40,020 --> 00:20:41,970 It's very small cost. 414 00:20:41,970 --> 00:20:45,600 And when we implement this and at the link layer, 415 00:20:45,600 --> 00:20:48,900 what we can do is to control where these keystrokes 416 00:20:48,900 --> 00:20:51,998 that we want to send can fall into the protocol state. 417 00:20:51,998 --> 00:20:56,998 So we can control that all, we can allow the protocol 418 00:20:58,110 --> 00:21:00,930 at the link layer to reach this point, 419 00:21:00,930 --> 00:21:04,200 and then we can freeze the protocol and send 420 00:21:04,200 --> 00:21:05,490 all the keystrokes that we want to send, 421 00:21:05,490 --> 00:21:07,710 as if is there is no tomorrow. 422 00:21:07,710 --> 00:21:08,543 And then just wait 423 00:21:08,543 --> 00:21:12,540 for the master to terminate the connection. 424 00:21:12,540 --> 00:21:13,890 The master will terminate the connection, 425 00:21:13,890 --> 00:21:14,907 because he's actually waiting for 426 00:21:14,907 --> 00:21:17,730 the encryption response command, PDU, sorry. 427 00:21:17,730 --> 00:21:19,830 And this, this will never arrive, 428 00:21:19,830 --> 00:21:21,540 because we are not going to send it. 429 00:21:21,540 --> 00:21:23,640 So at timeout will expire here. 430 00:21:23,640 --> 00:21:26,670 And after this timeout expires, the master sense, 431 00:21:26,670 --> 00:21:28,170 the terminating indication PDU, 432 00:21:28,170 --> 00:21:29,610 just dropping the connection. 433 00:21:29,610 --> 00:21:31,710 But at this point, all the keystrokes that we have sent 434 00:21:31,710 --> 00:21:34,770 have been already accepted by the master. 435 00:21:34,770 --> 00:21:36,870 And we can see that in air capture, 436 00:21:36,870 --> 00:21:39,390 like I'm going to show you right now. 437 00:21:39,390 --> 00:21:41,457 In this air capture, you can see that 438 00:21:41,457 --> 00:21:43,440 the connect request comes and then 439 00:21:43,440 --> 00:21:46,170 all the subsequent normal link layer messages 440 00:21:46,170 --> 00:21:51,170 that let's say, advance in the state of the connection, 441 00:21:52,576 --> 00:21:55,943 which, objective is eventually to encrypt it. 442 00:21:55,943 --> 00:22:00,252 But as soon as we received the encryption request PDU, 443 00:22:00,252 --> 00:22:04,027 what we do is to freeze the link layer in the fake slave. 444 00:22:04,027 --> 00:22:05,929 And then instead of continuing 445 00:22:05,929 --> 00:22:07,950 the normal functioning of the link layer, 446 00:22:07,950 --> 00:22:10,320 that will be to send encryption response, 447 00:22:10,320 --> 00:22:14,220 to ask for the long term key, to our host part, 448 00:22:14,220 --> 00:22:16,440 et cetera, et cetera, we just don't do that. 449 00:22:16,440 --> 00:22:19,173 And instead of that, we send all the key strokes 450 00:22:19,173 --> 00:22:22,800 that we want to send. As you can see here. 451 00:22:22,800 --> 00:22:26,559 And we send all of them, and when eventually 452 00:22:26,559 --> 00:22:28,830 what we send all of them, and then 453 00:22:28,830 --> 00:22:30,180 we just stop sending things. 454 00:22:30,180 --> 00:22:32,640 We just wait for the master to drop the connection, 455 00:22:32,640 --> 00:22:34,940 but all these keys have already been accepted. 456 00:22:40,260 --> 00:22:42,450 - Now we have an exploit that allow us 457 00:22:42,450 --> 00:22:47,240 to inject some keystrokes into the master, 458 00:22:48,796 --> 00:22:53,430 but we want to try to increment the number of keystrokes 459 00:22:53,430 --> 00:22:56,820 that we can inject in one connection. 460 00:22:56,820 --> 00:22:59,441 So we try to send a lot of keystrokes 461 00:22:59,441 --> 00:23:04,441 with no waiting time, but this cause a problem, 462 00:23:04,680 --> 00:23:06,809 because at the beginning of the communication, 463 00:23:06,809 --> 00:23:10,140 if we try to send a lot of keystrokes, 464 00:23:10,140 --> 00:23:12,990 some of these message are lost 465 00:23:12,990 --> 00:23:16,020 or aren't processed by the master. 466 00:23:16,020 --> 00:23:19,740 So we implement this exponential increment of waiting time. 467 00:23:19,740 --> 00:23:23,310 That starts waiting four seconds. 468 00:23:23,310 --> 00:23:26,940 That is a lot of time, but it works. 469 00:23:26,940 --> 00:23:30,840 And then every time that a keystroke is sent, 470 00:23:30,840 --> 00:23:32,957 divide this waiting time by two 471 00:23:32,957 --> 00:23:35,850 until you reach 20 milliseconds. 472 00:23:35,850 --> 00:23:39,689 This implementation allow us to inject 473 00:23:39,689 --> 00:23:42,690 more than 13,000 key strokes 474 00:23:42,690 --> 00:23:44,480 in one connection of 30 seconds. 475 00:23:44,480 --> 00:23:47,703 And we have a demo at the end of the talk. 476 00:23:49,173 --> 00:23:54,173 We implement other upgrades in order to make easy 477 00:23:55,140 --> 00:24:00,140 the, the configuration of the dongle. 478 00:24:01,429 --> 00:24:05,490 We implement these HCI vendor comments 479 00:24:05,490 --> 00:24:08,760 to program the dongle with some 480 00:24:08,760 --> 00:24:11,910 special characteristics of each device 481 00:24:11,910 --> 00:24:16,910 and what key strokes we want to send in every connection 482 00:24:18,600 --> 00:24:21,450 without having to recompile SEFA 483 00:24:21,450 --> 00:24:23,650 every time that we want to change something. 484 00:24:24,690 --> 00:24:29,690 We include an HCI comment to program the handle, 485 00:24:30,000 --> 00:24:33,751 the record size and the operation type. 486 00:24:33,751 --> 00:24:37,380 And to clear the list of the keystrokes that will be sent, 487 00:24:37,380 --> 00:24:42,330 and the add some keystroke to add a keystroke, 488 00:24:42,330 --> 00:24:45,004 to be sent when the connection is established. 489 00:24:45,004 --> 00:24:49,571 We also implement some specialized actions. 490 00:24:49,571 --> 00:24:54,450 For example, this is the action to sleep. 491 00:24:54,450 --> 00:24:56,580 We can tell the dongle to sleep. 492 00:24:56,580 --> 00:24:59,793 Some milliseconds between two keystrokes are sent. 493 00:25:00,852 --> 00:25:04,516 In this case, it's sleeping 500 milliseconds. 494 00:25:04,516 --> 00:25:09,516 And we implement another option. That was the rule forever. 495 00:25:10,110 --> 00:25:14,222 That is, we think that is only for testing proposed. 496 00:25:14,222 --> 00:25:15,722 To, and it allows us to repeat 497 00:25:19,230 --> 00:25:21,120 the list of keystrokes in a loop 498 00:25:21,120 --> 00:25:25,002 until the connection is closed by the master. 499 00:25:25,002 --> 00:25:27,180 (mouse clicks) 500 00:25:27,180 --> 00:25:32,180 So now, let's see what we need to perform the attack. 501 00:25:32,430 --> 00:25:37,430 And we need the Nordic dongle. That cost about $30. 502 00:25:37,530 --> 00:25:40,533 It's a Bluetooth, low-energy dongle. 503 00:25:41,772 --> 00:25:46,290 We also need, the or modified Zephyr firmware, 504 00:25:46,290 --> 00:25:48,557 that you can find it in our GitHub. 505 00:25:49,693 --> 00:25:53,190 I don't know it, is it published now? Yeah? (laughs) 506 00:25:53,190 --> 00:25:54,707 You can find it in our GitHub. 507 00:25:56,220 --> 00:25:58,380 With these two things, you can program the dongle, 508 00:25:58,380 --> 00:26:03,060 but it is quite hard because you need to use the HCI tool 509 00:26:03,060 --> 00:26:07,260 and put the bites there manually. 510 00:26:07,260 --> 00:26:11,100 And we develop some extra tools that help us 511 00:26:11,100 --> 00:26:16,023 to program the dongle in a more user, user-friendly way. 512 00:26:16,977 --> 00:26:21,810 Okay. Before we can perform the attack, 513 00:26:21,810 --> 00:26:23,880 we need to know some characteristics 514 00:26:23,880 --> 00:26:25,590 about the Bluetooth Low Energy keyboard 515 00:26:25,590 --> 00:26:27,390 that we want to impersonate. 516 00:26:27,390 --> 00:26:32,390 And basically we need to know how these specific keyboards 517 00:26:32,490 --> 00:26:37,490 send the report data to the master, and the Mac address 518 00:26:40,410 --> 00:26:43,601 of the real keyboard that we want to impersonate. 519 00:26:43,601 --> 00:26:45,630 (mouse clicks) 520 00:26:45,630 --> 00:26:50,299 The first data that we need could be extracted using 521 00:26:50,299 --> 00:26:54,330 Replica, analyzing the communications. 522 00:26:54,330 --> 00:26:58,770 It's very easy because you press a key 523 00:26:58,770 --> 00:27:02,490 on a real, legitimate keyboard. 524 00:27:02,490 --> 00:27:06,309 You could see on Wireshark, that it's sending a report 525 00:27:06,309 --> 00:27:09,750 using a specific handle, in this case, 526 00:27:09,750 --> 00:27:14,750 is the 13 with specific structure that has 11 bytes 527 00:27:15,354 --> 00:27:18,210 and the operation type, or opp code, 528 00:27:18,210 --> 00:27:21,897 that is under notification and (indistinct) notification. 529 00:27:21,897 --> 00:27:25,260 And to get Mac address, we could listen in the air, 530 00:27:25,260 --> 00:27:30,260 the real keyboard, and we use separate modes. 531 00:27:32,880 --> 00:27:37,293 The first mode was when the keyboard isn't paired yet. 532 00:27:38,967 --> 00:27:43,967 And before, when the keyboard enters in the pairing mode, 533 00:27:44,730 --> 00:27:48,570 it starts sending advertising indications 534 00:27:48,570 --> 00:27:51,030 like this, that has the appearance. 535 00:27:51,030 --> 00:27:53,970 That is the, a keyboard and the company. 536 00:27:53,970 --> 00:27:56,283 In this case, we use a Microsoft keyboard, 537 00:27:57,240 --> 00:28:00,240 and it include, this message include the VD address, 538 00:28:00,240 --> 00:28:05,160 or the Mac address during this month. 539 00:28:05,160 --> 00:28:07,470 It also send a scan response that includes 540 00:28:07,470 --> 00:28:11,913 the full device name and the advertising address. 541 00:28:13,710 --> 00:28:17,650 But it is not realistic that the attacker 542 00:28:17,650 --> 00:28:22,650 were always, when the pairing is performing. 543 00:28:24,270 --> 00:28:28,743 So there are another way to get the Mac address, and it's 544 00:28:28,743 --> 00:28:32,846 when the keyboard is re-connecting to the Windows PC. 545 00:28:32,846 --> 00:28:36,870 And it's this kind of message that are advertising 546 00:28:36,870 --> 00:28:39,900 that indication, that includes the BD others 547 00:28:39,900 --> 00:28:44,373 of the keyboard and the Mac address of the PC. 548 00:28:46,080 --> 00:28:48,750 Once we have all this information, 549 00:28:48,750 --> 00:28:50,733 we could write the configuration file 550 00:28:50,733 --> 00:28:53,790 that we need to run the tech. 551 00:28:53,790 --> 00:28:55,890 And it includes the report handle, 552 00:28:55,890 --> 00:28:58,680 the report size and the operation type 553 00:28:58,680 --> 00:29:01,773 that we collect before analyzing our replica. 554 00:29:02,700 --> 00:29:06,240 And the last attribute on the configuration file 555 00:29:06,240 --> 00:29:09,630 was the types of script, that are the characters 556 00:29:09,630 --> 00:29:13,707 that we want to send to the victim. 557 00:29:13,707 --> 00:29:16,599 We could include in this characters, 558 00:29:16,599 --> 00:29:19,770 some special characters like: left Windows, 559 00:29:19,770 --> 00:29:21,870 or enter, using braces. 560 00:29:21,870 --> 00:29:25,421 And we could send two keys pressed together, 561 00:29:25,421 --> 00:29:30,421 like left Windows plus R that are on the first example. 562 00:29:31,080 --> 00:29:33,630 In this case, for example, is to open 563 00:29:33,630 --> 00:29:36,300 the room dialogue of Windows, the shortcut, 564 00:29:36,300 --> 00:29:38,130 to open the room dialogue. 565 00:29:38,130 --> 00:29:41,490 And we also use the special actions 566 00:29:41,490 --> 00:29:46,361 using the common name, common name and arguments. 567 00:29:46,361 --> 00:29:49,976 This example of types of script 568 00:29:49,976 --> 00:29:54,976 opens the run dialogue of Windows, right? 569 00:29:55,320 --> 00:30:00,320 Power shell, press enter, and then sleep for five, 570 00:30:00,686 --> 00:30:03,990 500 milliseconds and then open a card, 571 00:30:03,990 --> 00:30:07,173 that is a common proof of concept. 572 00:30:08,850 --> 00:30:13,202 Once we have this configuration file written, 573 00:30:13,202 --> 00:30:17,760 we could call the KB injection pile that only needs 574 00:30:17,760 --> 00:30:22,460 the HCI where the dongle is identified, 575 00:30:25,410 --> 00:30:28,673 the video address of the keyboard that we want to 576 00:30:28,673 --> 00:30:32,070 impersonate. And the confirmation file. 577 00:30:32,070 --> 00:30:34,440 We add two more options. 578 00:30:34,440 --> 00:30:38,723 That is the rule forever that I before send in a loop, 579 00:30:40,260 --> 00:30:43,590 the keystrokes that we want to inject, 580 00:30:43,590 --> 00:30:47,160 and no act that prints common HCI comments 581 00:30:47,160 --> 00:30:48,050 instead of running it directly. 582 00:30:48,050 --> 00:30:50,717 (mouse clicks) 583 00:30:52,320 --> 00:30:54,720 - And we are approaching the end of our talk. 584 00:30:54,720 --> 00:30:57,690 This is demo time again, but this time at, 585 00:30:57,690 --> 00:30:59,804 let's say the real time pace, 586 00:30:59,804 --> 00:31:03,407 this is the actual demo of the attack. 587 00:31:03,407 --> 00:31:05,940 This is the scenario that you can find here, the victim, 588 00:31:05,940 --> 00:31:09,570 the legitimate keyboard and the attacker, the Linux PC 589 00:31:09,570 --> 00:31:13,440 that is connected to this dongle here. 590 00:31:13,440 --> 00:31:16,320 And what we can see here is that the legitimate user 591 00:31:16,320 --> 00:31:20,928 is just typing its work onto to the Windows machine, 592 00:31:20,928 --> 00:31:25,230 just typing his regular work, as we can see right now. 593 00:31:25,230 --> 00:31:28,020 And eventually what is going to happen 594 00:31:28,020 --> 00:31:31,456 is that this regular user will stop, 595 00:31:31,456 --> 00:31:35,520 stop typing because he wants a coffee or whatever. 596 00:31:35,520 --> 00:31:38,070 And at this point in time, 597 00:31:38,070 --> 00:31:40,263 this inactivity period is going to start. 598 00:31:42,030 --> 00:31:43,860 Now, we are going to see that 599 00:31:43,860 --> 00:31:46,680 while this inactivity period is counting, 600 00:31:46,680 --> 00:31:49,320 the attacker launches his attack 601 00:31:49,320 --> 00:31:51,600 and it launches using all the techniques 602 00:31:51,600 --> 00:31:53,257 that we have explained to you. 603 00:31:53,257 --> 00:31:55,560 The important thing here is that 604 00:31:55,560 --> 00:31:58,840 the attacker does doesn't have to synchronize himself 605 00:31:58,840 --> 00:32:00,540 to the point in time where the 606 00:32:00,540 --> 00:32:03,480 legitimate keyboard is going to be disconnected. 607 00:32:03,480 --> 00:32:07,170 He doesn't need to do that because as soon as he launches 608 00:32:07,170 --> 00:32:09,930 the attack, the fake device will start advertising. 609 00:32:09,930 --> 00:32:12,870 And this advertising messages will be just ignored by the 610 00:32:12,870 --> 00:32:15,480 Windows machine, because the Windows machine is just still 611 00:32:15,480 --> 00:32:17,460 connected to the legitimate keyboard. 612 00:32:17,460 --> 00:32:20,190 So the attacker can launch the attack 613 00:32:20,190 --> 00:32:23,940 and just wait for the legitimate keyboard to disconnect, 614 00:32:23,940 --> 00:32:27,265 which is what we are doing right now with fast forward. 615 00:32:27,265 --> 00:32:29,340 We are fast forwarding time, just to reach the point where 616 00:32:29,340 --> 00:32:31,680 the legitimate keyboard is going to be disconnected, 617 00:32:31,680 --> 00:32:34,590 to save energy. As we have explained before. 618 00:32:34,590 --> 00:32:38,370 Which in this case, for this keyboard was about 10 minutes. 619 00:32:38,370 --> 00:32:39,450 And, as we can see right now, 620 00:32:39,450 --> 00:32:41,220 the keyboard is going to be disconnected. 621 00:32:41,220 --> 00:32:44,460 We can see here in the control panel window. 622 00:32:44,460 --> 00:32:45,900 And at this point, the Windows machine, 623 00:32:45,900 --> 00:32:48,570 acting as a master, will try to create a new connection. 624 00:32:48,570 --> 00:32:51,270 Will try to reconnect or create a new connection, 625 00:32:51,270 --> 00:32:54,060 to be activated as soon as the keyboard appears again. 626 00:32:54,060 --> 00:32:55,920 But the keyboard that is going to appear 627 00:32:55,920 --> 00:32:57,210 is not the legitimate one, 628 00:32:57,210 --> 00:32:59,585 is our keyboard, that we are trying to, 629 00:32:59,585 --> 00:33:02,430 we are impersonating the legitimate keyboard. 630 00:33:02,430 --> 00:33:04,470 And all these key strokes have been injected. 631 00:33:04,470 --> 00:33:05,610 As you can see. 632 00:33:05,610 --> 00:33:07,680 In this case, we've launched a power shell, 633 00:33:07,680 --> 00:33:11,760 and we've just written a downloader 634 00:33:11,760 --> 00:33:13,140 that downloads this malware. 635 00:33:13,140 --> 00:33:15,270 That just for the proof of concept, 636 00:33:15,270 --> 00:33:18,485 just shows this image. And that's all, 637 00:33:18,485 --> 00:33:21,652 (audience applauding) 638 00:33:27,330 --> 00:33:29,670 Thanks a lot. By the way (laughs) 639 00:33:29,670 --> 00:33:32,700 we have this other demo to show you, 640 00:33:32,700 --> 00:33:36,997 that this attack not only works for keyboards, it all, 641 00:33:39,210 --> 00:33:44,210 it also work for other, HID devices like a mouse. 642 00:33:44,220 --> 00:33:45,720 In this case, we've, 643 00:33:45,720 --> 00:33:47,820 we've just recorded the proof of concept. 644 00:33:47,820 --> 00:33:51,238 The principles of the attack are exactly the same. 645 00:33:51,238 --> 00:33:54,120 The only thing that changes is that the format of the PDUs 646 00:33:54,120 --> 00:33:56,070 that we're sending contained a different data 647 00:33:56,070 --> 00:33:58,080 because the HID format of the mouse 648 00:33:58,080 --> 00:33:59,190 is different from the keyboard. 649 00:33:59,190 --> 00:34:02,040 But other than that, the principles are exactly the same. 650 00:34:02,040 --> 00:34:05,103 As you can see, the keyboard gets disconnected 651 00:34:05,103 --> 00:34:10,103 and then, the fake mouse will, 652 00:34:11,556 --> 00:34:14,520 the Windows box will connect to the fake mouse, 653 00:34:14,520 --> 00:34:17,910 just as it did for the fake keyboard. 654 00:34:17,910 --> 00:34:21,540 And we program some movements on some clicks of the mouse, 655 00:34:21,540 --> 00:34:26,540 just to show this square in on the Paint program of Windows. 656 00:34:27,000 --> 00:34:29,100 And we have left another demo for you, 657 00:34:29,100 --> 00:34:31,470 is the one that shows how many key strokes 658 00:34:31,470 --> 00:34:34,890 we are able to produce in only one connection, 659 00:34:34,890 --> 00:34:37,350 in only one shot. And this is the demo. 660 00:34:37,350 --> 00:34:39,270 I'm going to let it run at real time, 661 00:34:39,270 --> 00:34:43,050 because even if it lasts for a few seconds, 662 00:34:43,050 --> 00:34:47,790 we wanted you to see the real time of the attack. 663 00:34:47,790 --> 00:34:49,347 So at this point in time, 664 00:34:49,347 --> 00:34:52,533 the attacker has launched the attack. And as you can see, 665 00:34:52,533 --> 00:34:56,458 keystrokes start coming and they keep coming, 666 00:34:56,458 --> 00:35:01,110 coming up to the point that the master, 667 00:35:01,110 --> 00:35:04,350 which in this case is the Windows machine, 668 00:35:04,350 --> 00:35:06,750 will disconnect it, will drop the connection, 669 00:35:06,750 --> 00:35:08,790 using the terminate indication command. 670 00:35:08,790 --> 00:35:11,160 As you can see, this is real time. 671 00:35:11,160 --> 00:35:14,370 This is all the keys that we can send 672 00:35:14,370 --> 00:35:16,685 to the master in only one connection. 673 00:35:16,685 --> 00:35:19,200 In this case, we are sending it to the, 674 00:35:19,200 --> 00:35:22,350 just to the note pad, just to illustrate 675 00:35:22,350 --> 00:35:26,640 that this is just a proof of concept, but just to count 676 00:35:26,640 --> 00:35:29,610 how many key strokes we are able to inject. 677 00:35:29,610 --> 00:35:31,890 And at the end, as you can see here, 678 00:35:31,890 --> 00:35:35,970 more than 13,000 keys have been injected. 679 00:35:35,970 --> 00:35:38,130 And we think that this is more than enough 680 00:35:38,130 --> 00:35:42,270 to write some downloader or even some power cell malware 681 00:35:42,270 --> 00:35:45,783 or whatever. So the impact is that way. 682 00:35:48,360 --> 00:35:50,820 And finally, we did the vulnerability disclosure 683 00:35:50,820 --> 00:35:53,490 with Microsoft. They, in February, this year, 684 00:35:53,490 --> 00:35:56,310 they immediately acknowledged the bug, 685 00:35:56,310 --> 00:35:59,280 and the bug is already solved. 686 00:35:59,280 --> 00:36:03,273 The patch has been issued. So please patch your systems. 687 00:36:04,580 --> 00:36:06,878 And if you want to play with it, 688 00:36:06,878 --> 00:36:08,910 we have made this publication. 689 00:36:08,910 --> 00:36:11,850 We have, I mean, you have this talk. 690 00:36:11,850 --> 00:36:13,920 If you want to review the attack, 691 00:36:13,920 --> 00:36:16,080 or to understand the attack, or to play with it. 692 00:36:16,080 --> 00:36:18,390 And if this talk is not enough, 693 00:36:18,390 --> 00:36:21,000 because our English is not very good looking, 694 00:36:21,000 --> 00:36:23,100 then we have tried to write down 695 00:36:23,100 --> 00:36:25,360 all the things here in our post, in our blog. 696 00:36:25,360 --> 00:36:28,500 And we also have all the tools 697 00:36:28,500 --> 00:36:31,323 and our modified firmware in our GitHub page. 698 00:36:32,280 --> 00:36:34,500 And we left here some reference for you, 699 00:36:34,500 --> 00:36:37,080 the reference for the tools that we have used for make the 700 00:36:37,080 --> 00:36:40,680 captures, the Zephyr project and other things, 701 00:36:40,680 --> 00:36:45,090 and also the references to the specifications 702 00:36:45,090 --> 00:36:46,560 and some previous words that we have read. 703 00:36:46,560 --> 00:36:49,080 They're not directly related with our work 704 00:36:49,080 --> 00:36:51,870 because they're quite different, but we have read them. 705 00:36:51,870 --> 00:36:56,190 So we left here also for your reference, 706 00:36:56,190 --> 00:36:58,860 and that will be all from our part. 707 00:36:58,860 --> 00:37:01,080 And we thank you very much for your attention. 708 00:37:01,080 --> 00:37:02,700 If you have any question, we will be around 709 00:37:02,700 --> 00:37:03,766 and we'll have more (indistinct) 710 00:37:03,766 --> 00:37:05,235 (audience applauding) 711 00:37:05,235 --> 00:37:06,068 Okay.