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:07,620
which is about one
vulnerability that we have found

4
00:00:07,620 --> 00:00:11,190
in Microsoft Windows
that allows an attacker

5
00:00:11,190 --> 00:00:15,540
to inject keystrokes,

6
00:00:15,540 --> 00:00:20,343
impersonating a previously
paired legitimate keyboard.

7
00:00:22,050 --> 00:00:26,560
But before going farther
in the presentation, let us

8
00:00:27,690 --> 00:00:29,160
try to get your attention

9
00:00:29,160 --> 00:00:34,030
and put the cart before the
horses and show you this

10
00:00:34,920 --> 00:00:39,920
very, very accelerated
version of our demo video.

11
00:00:40,200 --> 00:00:42,030
And please pay attention,

12
00:00:42,030 --> 00:00:43,930
because it's gonna get, it's be quick.

13
00:00:45,090 --> 00:00:46,080
This is the scenario.

14
00:00:46,080 --> 00:00:48,780
This is the legitimate
keyboard going disconnected.

15
00:00:48,780 --> 00:00:50,790
Then this is the attacker
launching the attack.

16
00:00:50,790 --> 00:00:53,070
And then as soon as the
attacker launches the attack,

17
00:00:53,070 --> 00:00:56,220
the fake device is going
to be present in the space.

18
00:00:56,220 --> 00:00:59,070
And then the Windows box
connects to the fake device,

19
00:00:59,070 --> 00:01:00,873
and the keys get injected.

20
00:01:02,429 --> 00:01:05,679
(audience applauding)

21
00:01:08,430 --> 00:01:11,160
We hope that everything
is clear for everyone.

22
00:01:11,160 --> 00:01:13,530
But if it is not, we
have the rest of the talk

23
00:01:13,530 --> 00:01:18,530
to try to explain it to
you, so please be with us.

24
00:01:20,550 --> 00:01:23,163
Hopefully we explain it right to you.

25
00:01:25,830 --> 00:01:26,820
- Hello everyone.

26
00:01:26,820 --> 00:01:31,820
Now I try to explain the video
again, but this time slowly.

27
00:01:33,480 --> 00:01:35,920
So the first thing to know is

28
00:01:36,870 --> 00:01:38,760
who are the participants in the video?

29
00:01:38,760 --> 00:01:41,070
And we have a Windows PC,

30
00:01:41,070 --> 00:01:43,680
a Bluetooth low energy
keyboard, and the attacker

31
00:01:43,680 --> 00:01:48,300
that are using Linux PC
with a special dongle.

32
00:01:48,300 --> 00:01:50,220
Before the video starts,

33
00:01:50,220 --> 00:01:52,960
Bluetooth low energy
keyboard and the Windows PC

34
00:01:54,330 --> 00:01:56,523
perform the Bluetooth pairing,

35
00:01:57,450 --> 00:02:01,740
in order to establish
an encrypted channel.

36
00:02:01,740 --> 00:02:06,123
And all the data that they are
communicating are encrypted.

37
00:02:08,280 --> 00:02:11,050
So every time that the
Bluetooth low energy keyboard

38
00:02:12,270 --> 00:02:14,433
reconnects with the Windows PC,

39
00:02:15,510 --> 00:02:19,920
the encryption channel,
encrypted channel is established,

40
00:02:19,920 --> 00:02:23,313
and all the data will be encrypted.

41
00:02:24,990 --> 00:02:26,779
As the Bluetooth low energy keyboard

42
00:02:26,779 --> 00:02:31,560
is a low energy device,
after a few period,

43
00:02:31,560 --> 00:02:33,333
after a little period of time,

44
00:02:34,290 --> 00:02:38,130
the keyboard disconnects in
order to save some energy.

45
00:02:38,130 --> 00:02:40,620
And it is in this moment when an attacker

46
00:02:40,620 --> 00:02:44,337
could impersonate the
Bluetooth low energy keyboard,

47
00:02:44,337 --> 00:02:46,800
and send some keystrokes,

48
00:02:46,800 --> 00:02:48,690
some not encrypted keystrokes.

49
00:02:48,690 --> 00:02:50,883
But how is this possible?

50
00:02:52,050 --> 00:02:56,200
We said before that the
Windows PC and the keyboard

51
00:02:57,300 --> 00:02:58,830
establish an encryption channel

52
00:02:58,830 --> 00:03:00,723
every time that it reconnects.

53
00:03:02,400 --> 00:03:06,633
We send not encrypted data, and
are accepted by the Windows.

54
00:03:08,670 --> 00:03:10,220
That's what this talk is about.

55
00:03:11,056 --> 00:03:14,010
And let us start from the beginning.

56
00:03:14,010 --> 00:03:17,370
He's Jose, and I'm Fernando.
We are security researchers.

57
00:03:17,370 --> 00:03:19,500
We like to play with security,

58
00:03:19,500 --> 00:03:21,300
and with communication protocols.

59
00:03:21,300 --> 00:03:23,580
We also climb and ride motor bikes,

60
00:03:23,580 --> 00:03:26,730
as you could see in the
photo, in our spare time.

61
00:03:26,730 --> 00:03:29,243
We come from Spain, and work in Lyakk.

62
00:03:30,090 --> 00:03:32,373
And what we saw in this talk,

63
00:03:33,690 --> 00:03:36,690
we start with a brief description

64
00:03:36,690 --> 00:03:39,090
of Bluetooth low energy concepts.

65
00:03:39,090 --> 00:03:41,560
Some concept only in order to

66
00:03:43,680 --> 00:03:46,023
understand better the vulnerability.

67
00:03:47,520 --> 00:03:51,420
Then we detail how this
attack is possible,

68
00:03:51,420 --> 00:03:55,650
and what parts of the specs
of the Bluetooth specs,

69
00:03:55,650 --> 00:04:00,000
and Windows allow this attack.

70
00:04:00,000 --> 00:04:01,830
Then we show you two approaches

71
00:04:01,830 --> 00:04:05,310
of how we try to exploit
this vulnerability.

72
00:04:05,310 --> 00:04:06,810
And the first one doesn't work,

73
00:04:06,810 --> 00:04:10,233
and the second approach
is the current exploit.

74
00:04:11,880 --> 00:04:13,890
We continue with the proof of concepts,

75
00:04:13,890 --> 00:04:16,740
showing all the hardware
and software that we need

76
00:04:16,740 --> 00:04:20,730
to perform the attack, and some demos.

77
00:04:20,730 --> 00:04:23,400
And conclude this talk,

78
00:04:23,400 --> 00:04:25,680
showing some data about the
vulnerability disclosure,

79
00:04:25,680 --> 00:04:28,770
some related publications, and reference

80
00:04:28,770 --> 00:04:31,863
that help us to find and
exploit this vulnerability.

81
00:04:34,320 --> 00:04:35,640
- As you will see during the talk,

82
00:04:35,640 --> 00:04:38,430
the attack is extremely simple.

83
00:04:38,430 --> 00:04:41,910
But we think that it's
important to introduce

84
00:04:41,910 --> 00:04:46,260
some Bluetooth low
energy concepts that help

85
00:04:46,260 --> 00:04:47,580
to understand the attack, especially

86
00:04:47,580 --> 00:04:49,890
if you're not familiar with
the Bluetooth protocols.

87
00:04:49,890 --> 00:04:51,270
And the first one of these concept

88
00:04:51,270 --> 00:04:52,980
is this concept of pairing.

89
00:04:52,980 --> 00:04:56,160
When two Bluetooth devices want to

90
00:04:56,160 --> 00:04:57,660
protect their communications,

91
00:04:57,660 --> 00:05:01,920
they must finish this pairing
procedure as they call it.

92
00:05:01,920 --> 00:05:05,760
The objective of this procedure
is to establish a key,

93
00:05:05,760 --> 00:05:08,523
which is called the long-term
key, that will be used.

94
00:05:09,540 --> 00:05:10,920
By the way, this is only performed

95
00:05:10,920 --> 00:05:12,480
the first time they connect.

96
00:05:12,480 --> 00:05:15,750
And then they keep this long-term key,

97
00:05:15,750 --> 00:05:17,277
and they use it every time they want

98
00:05:17,277 --> 00:05:20,670
to connect each other again
to derive a session key,

99
00:05:20,670 --> 00:05:21,690
that is the key that is going

100
00:05:21,690 --> 00:05:23,670
to protect this particular connection.

101
00:05:23,670 --> 00:05:25,050
We are not talking about the different

102
00:05:25,050 --> 00:05:27,300
pairing schemes, or association models,

103
00:05:27,300 --> 00:05:28,890
because they're not
relevant for the attack.

104
00:05:28,890 --> 00:05:31,893
We just left them here for your reference.

105
00:05:33,030 --> 00:05:36,210
But we do want to talk
about another concept,

106
00:05:36,210 --> 00:05:39,280
about Bluetooth low
energy protocols is that

107
00:05:43,980 --> 00:05:46,320
the layer set is splitted in two parts.

108
00:05:46,320 --> 00:05:51,090
The host part, which holds the
upper part of the protocol,

109
00:05:51,090 --> 00:05:53,288
which contains the L2 CAT protocol,

110
00:05:53,288 --> 00:05:57,600
also the ATT protocol
that manages and shows,

111
00:05:57,600 --> 00:06:00,990
and interacts with the
attributes of every device.

112
00:06:00,990 --> 00:06:03,930
This upper part talks with
the application layer,

113
00:06:03,930 --> 00:06:05,160
which is above it.

114
00:06:05,160 --> 00:06:07,740
In our case, the application layer will be

115
00:06:07,740 --> 00:06:09,930
the HID, the Human Interface Device,

116
00:06:09,930 --> 00:06:13,980
which is because we are
attacking a keyboard.

117
00:06:13,980 --> 00:06:17,040
And the lower part of the protocol layers

118
00:06:17,040 --> 00:06:18,600
are called the controller one.

119
00:06:18,600 --> 00:06:21,990
And you will find several
different configurations of that.

120
00:06:21,990 --> 00:06:24,030
For example, in the keyboard case,

121
00:06:24,030 --> 00:06:26,100
you'll find that the
host and the controller

122
00:06:26,100 --> 00:06:27,990
are both implemented in the keyboard.

123
00:06:27,990 --> 00:06:29,940
But for example, if we are talking about

124
00:06:29,940 --> 00:06:32,310
a Windows box or a Linux box,

125
00:06:32,310 --> 00:06:35,940
the host is implemented
in the operating system.

126
00:06:35,940 --> 00:06:37,320
For example, you have Linux,

127
00:06:37,320 --> 00:06:40,320
the host is the Bluetooth
implementation of that.

128
00:06:40,320 --> 00:06:43,020
And the controller is
implemented in the firmware

129
00:06:43,020 --> 00:06:46,170
of the device that you're using,
either an embedded device,

130
00:06:46,170 --> 00:06:49,740
or chip set, or external dongle.

131
00:06:49,740 --> 00:06:51,300
This firmware implements the controller.

132
00:06:51,300 --> 00:06:53,820
The communication between these two parts

133
00:06:53,820 --> 00:06:55,950
is very straightly forward,

134
00:06:55,950 --> 00:06:58,473
called host to controller interface, HCI.

135
00:07:01,350 --> 00:07:03,660
The host sends information
to the controller

136
00:07:03,660 --> 00:07:08,010
by one thing that is called commands.

137
00:07:08,010 --> 00:07:10,680
And the controller sends the host events.

138
00:07:10,680 --> 00:07:12,750
That is just a question of names.

139
00:07:12,750 --> 00:07:14,250
But one of the important things,

140
00:07:14,250 --> 00:07:17,550
or one of the things that we
want to emphasize here is that

141
00:07:17,550 --> 00:07:20,160
encryption happens at the link layer.

142
00:07:20,160 --> 00:07:22,980
So the host part doesn't do anything

143
00:07:22,980 --> 00:07:25,440
about encryption except maybe.

144
00:07:25,440 --> 00:07:26,273
No, not maybe.

145
00:07:26,273 --> 00:07:29,220
Except just managing the
state of the encryption,

146
00:07:29,220 --> 00:07:31,830
and calculating the long-term
key, and that's all.

147
00:07:31,830 --> 00:07:34,110
And whenever the link layer
needs the long-term key

148
00:07:34,110 --> 00:07:35,670
to calculate the session key,

149
00:07:35,670 --> 00:07:38,460
then the host part provides
this long-term key.

150
00:07:38,460 --> 00:07:40,320
So this is a very important concept,

151
00:07:40,320 --> 00:07:42,720
and you will see why
during our presentation,

152
00:07:42,720 --> 00:07:46,020
because it's very directly
related with the attack.

153
00:07:46,020 --> 00:07:49,410
And we have still one more
concept to introduce to you

154
00:07:49,410 --> 00:07:51,360
before explaining the attack, which is.

155
00:07:52,500 --> 00:07:55,860
Let's imagine this scenario
where we have the master device.

156
00:07:55,860 --> 00:07:57,810
And we are using here the

157
00:07:57,810 --> 00:08:01,080
Bluetooth 5.2 specification terminology.

158
00:08:01,080 --> 00:08:02,310
In our case, in our scenario,

159
00:08:02,310 --> 00:08:05,190
the master device is the Windows machine.

160
00:08:05,190 --> 00:08:06,570
And we have the slave device.

161
00:08:06,570 --> 00:08:07,770
In our scenario, the slave device

162
00:08:07,770 --> 00:08:10,680
is the Bluetooth low energy keyboard.

163
00:08:10,680 --> 00:08:12,810
And we have the situation here.

164
00:08:12,810 --> 00:08:14,850
The start point is the situation where

165
00:08:14,850 --> 00:08:17,580
these two devices have previously paired,

166
00:08:17,580 --> 00:08:19,890
completed the pairing
procedure that I talked before.

167
00:08:19,890 --> 00:08:20,790
So they both have

168
00:08:20,790 --> 00:08:23,520
the long-term key associated
with this connection.

169
00:08:23,520 --> 00:08:25,380
And they want to reconnect.

170
00:08:25,380 --> 00:08:27,181
They want to create a new connection.

171
00:08:27,181 --> 00:08:30,270
And we are going to see
right now what happens here,

172
00:08:30,270 --> 00:08:32,580
and how does it work.

173
00:08:32,580 --> 00:08:35,760
So the master, the host
part of the master,

174
00:08:35,760 --> 00:08:37,890
instructs the link layer
to create that connection.

175
00:08:37,890 --> 00:08:40,110
It just provokes in the link layer

176
00:08:40,110 --> 00:08:43,590
that the link layer starts listening for,

177
00:08:43,590 --> 00:08:45,390
for this slave to appear in the air.

178
00:08:45,390 --> 00:08:46,890
And more particularly,

179
00:08:46,890 --> 00:08:49,353
to advertising messages from this slave.

180
00:08:50,190 --> 00:08:51,450
The slave is sleeping right now,

181
00:08:51,450 --> 00:08:54,570
because he went to sleep to save energy.

182
00:08:54,570 --> 00:08:58,200
And he restarts whenever
the user presses a key.

183
00:08:58,200 --> 00:09:00,420
And then it provokes
that the host informs,

184
00:09:00,420 --> 00:09:04,350
or instructs the link layer
to start advertising himself

185
00:09:04,350 --> 00:09:07,560
with this command set advertising enabled.

186
00:09:07,560 --> 00:09:11,730
And then eventually one of
these advertising messages gets,

187
00:09:13,140 --> 00:09:14,610
gets to the link layer of the master.

188
00:09:14,610 --> 00:09:17,853
And then the master answers
back with a connect indication,

189
00:09:18,990 --> 00:09:21,720
link layer message to the
link layer of the slave.

190
00:09:21,720 --> 00:09:25,470
Please see that this, everything
happens at the link layer.

191
00:09:25,470 --> 00:09:27,360
So the host is only participating

192
00:09:27,360 --> 00:09:30,493
in the controlling part
of the state of protocol.

193
00:09:30,493 --> 00:09:32,940
At this point of the protocol,

194
00:09:32,940 --> 00:09:36,060
the connection has been
created, and the both link layer

195
00:09:36,060 --> 00:09:39,120
inform their correspondent host part

196
00:09:39,120 --> 00:09:40,950
that the connection has been created.

197
00:09:40,950 --> 00:09:43,380
The connection is created,
but it's not encrypted.

198
00:09:43,380 --> 00:09:44,670
Not encrypted yet.

199
00:09:44,670 --> 00:09:46,560
This is what is going to happen now.

200
00:09:46,560 --> 00:09:48,450
The master that holds the long-term key

201
00:09:48,450 --> 00:09:51,240
knows that this connection
should be encrypted.

202
00:09:51,240 --> 00:09:53,070
As soon as the connection is created,

203
00:09:53,070 --> 00:09:55,263
it should, and it usually does,

204
00:09:56,520 --> 00:09:59,010
instructs the link layer
to start encryption.

205
00:09:59,010 --> 00:10:02,700
Then at this point, the link
layer calculates its part,

206
00:10:02,700 --> 00:10:05,280
the master part of two random values,

207
00:10:05,280 --> 00:10:07,710
the SKD, which is the
Session Key Diversifier,

208
00:10:07,710 --> 00:10:09,586
and initialization vector.

209
00:10:09,586 --> 00:10:12,240
This part is sent to the slave,

210
00:10:12,240 --> 00:10:13,590
to the link layer of the slave

211
00:10:13,590 --> 00:10:15,450
with the encryption request PDU.

212
00:10:15,450 --> 00:10:19,080
And the slave calculates
it's part of these values,

213
00:10:19,080 --> 00:10:21,570
and send back it with the
encryption response PDU

214
00:10:21,570 --> 00:10:23,523
to the link layer of the master.

215
00:10:26,386 --> 00:10:28,230
If you think there is one thing left,

216
00:10:28,230 --> 00:10:31,650
is that the slave does not
have the long-term key.

217
00:10:31,650 --> 00:10:33,360
The master, the link layer of the master

218
00:10:33,360 --> 00:10:36,480
do have the long-term key,
because it has been provided

219
00:10:36,480 --> 00:10:38,250
with the enable encryption command.

220
00:10:38,250 --> 00:10:42,000
But the slave doesn't have
that, so it has to ask for it.

221
00:10:42,000 --> 00:10:45,000
And if the slave has,
if the host of the slave

222
00:10:45,000 --> 00:10:47,280
has the long-term key, which is the case,

223
00:10:47,280 --> 00:10:49,603
it will answer back
with the long-term key.

224
00:10:49,603 --> 00:10:52,080
At this point, both devices can calculate

225
00:10:52,080 --> 00:10:53,940
the session key diversifier,

226
00:10:53,940 --> 00:10:56,890
because they have both parts
and the initialization vector.

227
00:10:58,860 --> 00:11:02,880
I just remind you that
these are random numbers.

228
00:11:02,880 --> 00:11:05,250
And they both can
calculate the session key

229
00:11:05,250 --> 00:11:08,640
that is going to protect
this particular connection.

230
00:11:08,640 --> 00:11:10,740
The session key is
calculated by encrypting

231
00:11:10,740 --> 00:11:12,540
the session key diversifier,

232
00:11:12,540 --> 00:11:15,270
using as encryption
key, the long-term key.

233
00:11:15,270 --> 00:11:16,680
And as an initialization vector,

234
00:11:16,680 --> 00:11:19,230
they calculated initialization vector.

235
00:11:19,230 --> 00:11:22,470
So at this point, both have
calculated the session key.

236
00:11:22,470 --> 00:11:26,510
And the only thing that left
to finish the encryption,

237
00:11:26,510 --> 00:11:29,463
to start the encryption
procedure, let's say that, is to,

238
00:11:31,050 --> 00:11:33,540
let's say agree on the point in time

239
00:11:33,540 --> 00:11:35,760
where the encryption starts.

240
00:11:35,760 --> 00:11:38,343
And this is made with
this kind of handshake.

241
00:11:39,900 --> 00:11:40,863
You say that.

242
00:11:42,360 --> 00:11:44,820
That starts with a start
encryption request command,

243
00:11:44,820 --> 00:11:47,970
sent, not encrypted, by
the link layer and then.

244
00:11:47,970 --> 00:11:49,890
Sorry, by the link layer of the slave.

245
00:11:49,890 --> 00:11:51,540
Then the link layer of the master

246
00:11:51,540 --> 00:11:53,850
answers back with a standard
encryption response.

247
00:11:53,850 --> 00:11:55,890
And this message is already be

248
00:11:55,890 --> 00:11:57,440
encrypted with the session key.

249
00:11:58,890 --> 00:12:01,080
So if the slave receives this message,

250
00:12:01,080 --> 00:12:05,310
and it is able to decrypt it, then it's,

251
00:12:05,310 --> 00:12:08,970
so to speak, kind of
authentication of this master.

252
00:12:08,970 --> 00:12:11,190
And it does exactly the same thing.

253
00:12:11,190 --> 00:12:13,320
It encrypts this
encryption response command

254
00:12:13,320 --> 00:12:17,280
with this just calculated session key.

255
00:12:17,280 --> 00:12:20,220
And so both are, let's say, authenticated.

256
00:12:20,220 --> 00:12:24,480
The connection is encrypted, is protected.

257
00:12:24,480 --> 00:12:26,100
At this point, it's very important.

258
00:12:26,100 --> 00:12:27,960
And this is very, very
important for the attack

259
00:12:27,960 --> 00:12:30,330
that we are explaining
here is that at this point,

260
00:12:30,330 --> 00:12:32,580
the link layer informs the host

261
00:12:32,580 --> 00:12:34,233
that the encryption has started.

262
00:12:35,430 --> 00:12:36,420
And it's at this point

263
00:12:36,420 --> 00:12:38,620
that encryption has
started, and not before.

264
00:12:40,140 --> 00:12:43,492
And you will understand,
just in a couple of slides,

265
00:12:43,492 --> 00:12:46,950
why I'm emphasizing this.

266
00:12:46,950 --> 00:12:49,800
Every next, or every subsequent PDU's

267
00:12:49,800 --> 00:12:51,300
will be encrypted from now on,

268
00:12:51,300 --> 00:12:53,910
for this particular connection.

269
00:12:53,910 --> 00:12:58,830
So we've seen these three or
four concepts about Bluetooth.

270
00:12:58,830 --> 00:13:01,350
And now we are going to explain how

271
00:13:01,350 --> 00:13:03,540
it is possible to inject this,

272
00:13:03,540 --> 00:13:05,890
with all these contexts
that we have explained.

273
00:13:08,070 --> 00:13:10,110
What makes the attack possible?

274
00:13:10,110 --> 00:13:12,930
In fact, there are two things
that make the attack possible.

275
00:13:12,930 --> 00:13:15,633
The first thing is one
thing that we don't,

276
00:13:17,460 --> 00:13:18,870
we don't call it vulnerability.

277
00:13:18,870 --> 00:13:21,600
It's something that is
present and explicitly defined

278
00:13:21,600 --> 00:13:24,180
in the specification in
the Bluetooth standard.

279
00:13:24,180 --> 00:13:27,510
And it's the fact that
when the slave. I'm sorry.

280
00:13:27,510 --> 00:13:31,020
When slave device receives
the encryption request PDU,

281
00:13:31,020 --> 00:13:35,682
it is explicitly allowed
to send any remaining PDU's

282
00:13:35,682 --> 00:13:37,290
that he has to send to the master,

283
00:13:37,290 --> 00:13:41,010
and he has in queues
in a not encrypted way.

284
00:13:41,010 --> 00:13:42,510
It's explicitly allowed.

285
00:13:42,510 --> 00:13:45,180
And I can show you the
part of the standard

286
00:13:45,180 --> 00:13:48,753
where this is written down.

287
00:13:49,800 --> 00:13:52,440
From our point of view,
this is not a vulnerability.

288
00:13:52,440 --> 00:13:54,780
It's just something that is there

289
00:13:54,780 --> 00:13:57,120
to allow the slave to empty its queues

290
00:13:57,120 --> 00:13:59,530
before continue to send in encrypted

291
00:14:01,680 --> 00:14:03,003
PDU's or encrypted data.

292
00:14:03,960 --> 00:14:06,210
But the second one, the second
thing that allows the attack,

293
00:14:06,210 --> 00:14:07,650
this is the vulnerability.

294
00:14:07,650 --> 00:14:09,093
Sorry, before that.

295
00:14:11,190 --> 00:14:13,290
What I wanted to say in this slide is that

296
00:14:15,300 --> 00:14:18,270
this characteristic that I just explained

297
00:14:18,270 --> 00:14:22,170
creates a window of
opportunity for an attacker

298
00:14:22,170 --> 00:14:24,750
trying to impersonate this slave device,

299
00:14:24,750 --> 00:14:29,750
where he can send data
through the connection,

300
00:14:30,000 --> 00:14:32,463
through the Bluetooth
connection and the master.

301
00:14:33,300 --> 00:14:38,070
Sorry, the link layer of the
master will accept this PDU.

302
00:14:38,070 --> 00:14:40,560
These PDU's, will accept this data.

303
00:14:40,560 --> 00:14:42,480
And it's the responsibility
of the upper part

304
00:14:42,480 --> 00:14:47,010
of the protocol to consider
that this data is valid or not.

305
00:14:47,010 --> 00:14:49,410
And this is precisely the second thing

306
00:14:49,410 --> 00:14:51,840
that allows the attack,
which is the vulnerability.

307
00:14:51,840 --> 00:14:55,350
It seems that Microsoft
Windows does not wait

308
00:14:55,350 --> 00:14:58,200
for this event, which is
the encryption change event,

309
00:14:58,200 --> 00:15:00,990
does not wait for this
event to consider that

310
00:15:00,990 --> 00:15:04,413
any PDU coming from the slave, it's legit.

311
00:15:05,430 --> 00:15:08,910
So it seems that it considers
that encryption has started

312
00:15:08,910 --> 00:15:11,370
as soon as the host part of the master

313
00:15:11,370 --> 00:15:13,293
orders the encryption to start.

314
00:15:14,160 --> 00:15:15,660
Which is not the case, you have to wait

315
00:15:15,660 --> 00:15:18,630
until receiving this
encryption change event.

316
00:15:18,630 --> 00:15:23,040
So this allows us to try
to impersonate the slave

317
00:15:23,040 --> 00:15:26,160
up to this point, and send
all these unencrypted PDU's

318
00:15:26,160 --> 00:15:28,170
without actually knowing
the long-term key,

319
00:15:28,170 --> 00:15:30,870
which will be needed to really complete

320
00:15:30,870 --> 00:15:32,940
this procedure of start encryption.

321
00:15:32,940 --> 00:15:34,237
And this is the thing
that allow the attack.

322
00:15:34,237 --> 00:15:36,587
These are the two things
that allow the attack.

323
00:15:39,510 --> 00:15:44,160
- Okay, now we will explain
the two approaches that

324
00:15:44,160 --> 00:15:48,330
we follow in order to try to
exploit this vulnerability.

325
00:15:48,330 --> 00:15:53,013
As before, the first one, is
working at the host level.

326
00:15:54,210 --> 00:15:58,500
Work with the host level
has a very big problem,

327
00:15:58,500 --> 00:16:02,820
is that we don't decide when
the message are really sent.

328
00:16:02,820 --> 00:16:05,640
We only tell the controller part to

329
00:16:05,640 --> 00:16:10,440
send some data to some high level data.

330
00:16:10,440 --> 00:16:15,370
But we, doesn't decide where
exactly this data is sent.

331
00:16:16,770 --> 00:16:20,910
We are trying to put some PDUs

332
00:16:20,910 --> 00:16:23,970
between the encryption request
and encryption response.

333
00:16:23,970 --> 00:16:26,980
And we couldn't decide where

334
00:16:28,170 --> 00:16:32,107
the PDU's we try to send are exactly put.

335
00:16:34,140 --> 00:16:37,650
And to implement this approach,

336
00:16:37,650 --> 00:16:40,410
we use an HCI adapter,
a common HCI adapter,

337
00:16:40,410 --> 00:16:43,080
with the only particularity that

338
00:16:43,080 --> 00:16:45,750
it allows to change the BD address

339
00:16:45,750 --> 00:16:48,270
in order to impersonate
the Bluetooth keyboard.

340
00:16:48,270 --> 00:16:51,210
And using the Mirage Framework.

341
00:16:51,210 --> 00:16:56,070
The Mirage Framework
allows, among other things,

342
00:16:56,070 --> 00:16:58,110
to hook some parts of the communication,

343
00:16:58,110 --> 00:17:02,520
and change the normal flow
of this communication.

344
00:17:02,520 --> 00:17:07,520
And we use it to intercept
the connection event.

345
00:17:08,550 --> 00:17:12,450
And after this event, we
start to send keystrokes,

346
00:17:12,450 --> 00:17:15,213
and doesn't send anything else.

347
00:17:18,990 --> 00:17:20,883
As I'd said, that,

348
00:17:23,220 --> 00:17:28,220
we doesn't decide where the
message are effectively sent.

349
00:17:29,520 --> 00:17:31,620
We need some tries to succeed,

350
00:17:31,620 --> 00:17:34,230
and put some of these keystrokes

351
00:17:34,230 --> 00:17:36,870
between the encryption request
and encryption response.

352
00:17:36,870 --> 00:17:40,680
And now we will show you
some capture in the air.

353
00:17:40,680 --> 00:17:45,680
We just sniffle to capture this message

354
00:17:46,350 --> 00:17:50,100
that is a Bluetooth low energy sniffer.

355
00:17:50,100 --> 00:17:52,713
In the left side, you could see the,

356
00:17:55,680 --> 00:17:57,330
the direction of the communication,

357
00:17:57,330 --> 00:17:59,670
master to slave, or the slave to master.

358
00:17:59,670 --> 00:18:03,240
And as I said, the connect request

359
00:18:03,240 --> 00:18:06,210
is sent by the master and
received by the slave.

360
00:18:06,210 --> 00:18:10,537
And just after that, we
start sending keystrokes, but

361
00:18:12,180 --> 00:18:14,700
you can see that there are
some link layer message

362
00:18:14,700 --> 00:18:16,803
that we have not control and are sent.

363
00:18:18,750 --> 00:18:20,790
And then the normal flow
of the communication

364
00:18:20,790 --> 00:18:23,760
on the start an encryption
request is received

365
00:18:23,760 --> 00:18:26,493
by the fake slave, by the slave.

366
00:18:27,774 --> 00:18:32,567
And the slave is trying
to send more keystrokes.

367
00:18:34,290 --> 00:18:37,650
Then the controller part of the fake slave

368
00:18:37,650 --> 00:18:41,400
respond automatically with
an encryption response,

369
00:18:41,400 --> 00:18:43,053
and ask for the long-term key.

370
00:18:44,100 --> 00:18:46,860
As we haven't got the long-term key,

371
00:18:46,860 --> 00:18:49,800
missing is sent back to the controller.

372
00:18:49,800 --> 00:18:54,800
And it is translated to link
layer, reject indication.

373
00:18:55,260 --> 00:18:57,360
Once master received this message,

374
00:18:57,360 --> 00:19:00,060
it closed the connection immediately,

375
00:19:00,060 --> 00:19:05,060
because the encryption channel
could not be established.

376
00:19:05,910 --> 00:19:10,910
And our fake slave continued
trying to send some keystrokes.

377
00:19:13,920 --> 00:19:17,760
The most important thing in
this slides, is to understand

378
00:19:17,760 --> 00:19:20,700
that we are trying to
send a lot of keystrokes

379
00:19:20,700 --> 00:19:23,220
between encryption request
and encryption response.

380
00:19:23,220 --> 00:19:27,367
And as we have control about when the,

381
00:19:28,770 --> 00:19:31,200
the link level data is sent,

382
00:19:31,200 --> 00:19:34,350
we can decide that these keystrokes hit

383
00:19:34,350 --> 00:19:36,660
between encryption requests
and encryption response.

384
00:19:36,660 --> 00:19:41,660
There are only one notification
message that hit there.

385
00:19:41,900 --> 00:19:45,510
And it means that there
are only one keystroke

386
00:19:45,510 --> 00:19:50,430
that are affectively injected
and processed by the master.

387
00:19:50,430 --> 00:19:54,630
So we realized that if we want to exploit

388
00:19:54,630 --> 00:19:57,428
this vulnerability, we should go down

389
00:19:57,428 --> 00:20:02,163
and develop something that
works in the controller level.

390
00:20:03,930 --> 00:20:05,760
- And this is what we did,

391
00:20:05,760 --> 00:20:08,100
and this is the actual
implementation of the attack.

392
00:20:08,100 --> 00:20:09,720
We implemented the attack at

393
00:20:09,720 --> 00:20:11,790
the link layer level,
at the controller level.

394
00:20:11,790 --> 00:20:13,713
In order to do that, we use this,

395
00:20:14,760 --> 00:20:18,090
let me say this fantastic
framework, which is called Zephyr.

396
00:20:18,090 --> 00:20:22,080
It's completely from top
to bottom open source

397
00:20:22,080 --> 00:20:25,020
implementation of the Bluetooth
low energy protocol stack.

398
00:20:25,020 --> 00:20:28,530
So this, you can compile
that and create a firmware

399
00:20:28,530 --> 00:20:30,120
that can run in one of these dongles,

400
00:20:30,120 --> 00:20:33,753
which is a Nordic RF52840.

401
00:20:35,220 --> 00:20:37,443
That has no,

402
00:20:38,430 --> 00:20:40,020
very, very, very few costs.

403
00:20:40,020 --> 00:20:41,223
It's very small cost.

404
00:20:43,795 --> 00:20:45,600
When we implement this
and at the link layer,

405
00:20:45,600 --> 00:20:48,900
what we can do is to control
where these keystrokes

406
00:20:48,900 --> 00:20:52,320
that we want to send can
fall into the protocol state.

407
00:20:52,320 --> 00:20:54,730
So we can control that, we can

408
00:20:56,040 --> 00:21:00,930
allow the protocol at the link
layer to reach this point.

409
00:21:00,930 --> 00:21:03,210
And then we can freeze the protocol,

410
00:21:03,210 --> 00:21:05,740
and send all the keystrokes
that we want to send,

411
00:21:05,740 --> 00:21:09,543
as if there is no tomorrow,
and then just wait for the,

412
00:21:10,950 --> 00:21:12,540
for the master to
terminate the connection.

413
00:21:12,540 --> 00:21:13,890
The master will terminate the connection,

414
00:21:13,890 --> 00:21:14,907
because he's actually waiting for

415
00:21:14,907 --> 00:21:17,730
the encryption response
command, PDU sorry.

416
00:21:17,730 --> 00:21:19,830
And this will never arrive,

417
00:21:19,830 --> 00:21:21,540
because we are not going to send it.

418
00:21:21,540 --> 00:21:23,640
So a timeout will expire here.

419
00:21:23,640 --> 00:21:26,640
And after this timeout
expires, the master sends

420
00:21:26,640 --> 00:21:29,610
the terminate indication PDU,
just dropping the connection.

421
00:21:29,610 --> 00:21:31,710
But at this point, all the
keystrokes that we have sent

422
00:21:31,710 --> 00:21:34,770
have been already accepted by the master.

423
00:21:34,770 --> 00:21:36,870
And we can see that in our capture,

424
00:21:36,870 --> 00:21:39,390
like I'm going to show you right now.

425
00:21:39,390 --> 00:21:41,457
In this air capture, you can see that

426
00:21:41,457 --> 00:21:44,670
the connect request comes
and then all the subsequent

427
00:21:44,670 --> 00:21:49,643
normal link layer messages
that, let's say advance in the

428
00:21:51,510 --> 00:21:53,130
state of the connection,

429
00:21:53,130 --> 00:21:56,280
which objective is
eventually to encrypt it.

430
00:21:56,280 --> 00:22:00,600
But as soon as we received
the encryption request PDU,

431
00:22:00,600 --> 00:22:04,530
what we do is to freeze the
link layer in the fake slave.

432
00:22:04,530 --> 00:22:06,300
And then instead of continuing

433
00:22:06,300 --> 00:22:07,950
the normal functioning of the layer,

434
00:22:07,950 --> 00:22:10,320
that will be to send encryption response,

435
00:22:10,320 --> 00:22:14,220
to ask for the long-term
key to our host part,

436
00:22:14,220 --> 00:22:16,440
et cetera, et cetera,
we just don't do that.

437
00:22:16,440 --> 00:22:18,905
And instead of that, we
send all the keystrokes

438
00:22:18,905 --> 00:22:22,800
that we want to send, as you can see here.

439
00:22:22,800 --> 00:22:24,123
And we sent all of them.

440
00:22:24,960 --> 00:22:27,780
And when, eventually what we,

441
00:22:27,780 --> 00:22:30,180
we send all of them, and then
we just stop sending things.

442
00:22:30,180 --> 00:22:32,453
We just wait for the master
to drop the connection,

443
00:22:32,453 --> 00:22:34,833
but all these keys have
already been accepted.

444
00:22:40,260 --> 00:22:42,960
- Now we have an exploit that allow us to

445
00:22:42,960 --> 00:22:47,960
inject some keystrokes into the master.

446
00:22:49,350 --> 00:22:53,430
But we want to try to increment
the number of keystrokes

447
00:22:53,430 --> 00:22:56,820
that we can inject in one connection.

448
00:22:56,820 --> 00:23:01,820
So we try to send a lot of
keystrokes with no waiting time.

449
00:23:02,640 --> 00:23:04,680
But this cause a problem,

450
00:23:04,680 --> 00:23:07,023
because at the beginning
of the communication,

451
00:23:08,100 --> 00:23:10,140
if we try to send a lot of keystrokes,

452
00:23:10,140 --> 00:23:12,990
some of these message are lost,

453
00:23:12,990 --> 00:23:16,020
or aren't processed by the master.

454
00:23:16,020 --> 00:23:18,540
So we implement this exponential decrement

455
00:23:18,540 --> 00:23:23,310
of waiting team time that
starts waiting four seconds.

456
00:23:23,310 --> 00:23:26,940
That is a lot of time, but it works.

457
00:23:26,940 --> 00:23:30,840
And then every time that
a keystroke is sent,

458
00:23:30,840 --> 00:23:33,330
divide this waiting time by two,

459
00:23:33,330 --> 00:23:35,850
and the limit reach 20 milliseconds.

460
00:23:35,850 --> 00:23:40,620
This implementation allow us to inject

461
00:23:40,620 --> 00:23:44,850
13,000 key strokes in one
connection of 30 seconds.

462
00:23:44,850 --> 00:23:47,703
And we have a demo at the end of the talk.

463
00:23:49,500 --> 00:23:54,500
We implement other upgrades
in order to make easy the

464
00:23:58,770 --> 00:24:00,543
configuration of the dongle.

465
00:24:02,520 --> 00:24:05,490
We implement this HCI vendor comments

466
00:24:05,490 --> 00:24:09,300
to program the dongle with some special,

467
00:24:09,300 --> 00:24:11,910
some characteristics of each device,

468
00:24:11,910 --> 00:24:16,910
and what keystrokes we want
to send in every connection,

469
00:24:18,600 --> 00:24:21,450
without having to recompile Zephyr

470
00:24:21,450 --> 00:24:23,650
every time that we want
to change something.

471
00:24:24,690 --> 00:24:29,690
We include an HCI comment
to program the handle,

472
00:24:30,000 --> 00:24:34,110
the report size, and the operation type,

473
00:24:34,110 --> 00:24:37,380
and to clear the list of the
keystrokes that will be sent,

474
00:24:37,380 --> 00:24:42,330
and add some keystroke to, add a keystroke

475
00:24:42,330 --> 00:24:45,630
to be sent when the
connection is established.

476
00:24:45,630 --> 00:24:49,083
We also implement some
specialized actions.

477
00:24:51,118 --> 00:24:54,480
For example, this is the action to sleep.

478
00:24:54,480 --> 00:24:57,420
We can tell the dongle to
sleep some milliseconds

479
00:24:57,420 --> 00:24:59,793
between two keystrokes are sent.

480
00:25:00,847 --> 00:25:04,860
In this case, it's
sleeping 500 milliseconds.

481
00:25:04,860 --> 00:25:09,860
And we implement another option,
that was the run forever.

482
00:25:10,110 --> 00:25:13,533
That is, we think that is
only for testing purpose.

483
00:25:15,272 --> 00:25:18,283
And it allow us to repeat the
list of keystrokes in a loop

484
00:25:21,120 --> 00:25:25,683
until the connection is
closed by the master.

485
00:25:27,180 --> 00:25:32,180
So now, let's see what we
need to perform the attack.

486
00:25:32,430 --> 00:25:37,430
And we need the Nordic
dongle that cost about $30.

487
00:25:37,530 --> 00:25:40,533
It's a Bluetooth low energy dongle.

488
00:25:42,360 --> 00:25:46,290
We also need the, or
modified Zephyr firmware,

489
00:25:46,290 --> 00:25:48,557
that you can find it in our GitHub.

490
00:25:49,710 --> 00:25:52,067
I don't know, it is it
published now? Yeah?

491
00:25:52,067 --> 00:25:53,190
(chuckles)

492
00:25:53,190 --> 00:25:54,707
You can find it in our GitHub.

493
00:25:56,220 --> 00:25:58,380
With these two things, you
can program the dongle.

494
00:25:58,380 --> 00:26:01,860
But it is quite hard,
because you'll need to use

495
00:26:01,860 --> 00:26:06,860
the HCI tool, and put the bytes manually.

496
00:26:07,260 --> 00:26:11,100
And we develop some
extra tools that help us

497
00:26:11,100 --> 00:26:16,023
to program the dongle in a
more user user-friendly way.

498
00:26:18,660 --> 00:26:21,810
Before we can perform the attack,

499
00:26:21,810 --> 00:26:24,120
we need to know some characteristics about

500
00:26:24,120 --> 00:26:25,590
the Bluetooth low energy keyboard

501
00:26:25,590 --> 00:26:26,990
that we want to impersonate.

502
00:26:28,770 --> 00:26:32,460
Basically we need to know
how this specific keyboard

503
00:26:32,460 --> 00:26:37,460
send the report data to the master,

504
00:26:38,648 --> 00:26:42,810
and the Mac address of the real keyboard

505
00:26:42,810 --> 00:26:44,210
that we want to impersonate.

506
00:26:45,630 --> 00:26:49,920
The first data that we
need could be extracted

507
00:26:49,920 --> 00:26:54,330
using a replica, analyzing
the communications.

508
00:26:54,330 --> 00:26:59,330
It's very easy, because
you press a key on a real,

509
00:27:00,577 --> 00:27:02,552
on a legitimate keyboard.

510
00:27:02,552 --> 00:27:06,227
You could see that it's sending a report,

511
00:27:07,290 --> 00:27:10,980
using a specific handle,
in this case is the 13

512
00:27:10,980 --> 00:27:15,298
with specific structure that has 11 bytes.

513
00:27:15,298 --> 00:27:19,380
And operation type or code
that is in the notification.

514
00:27:19,380 --> 00:27:22,020
And those were the notifications.

515
00:27:22,020 --> 00:27:25,080
And to get the Mac address
we could listen in the air

516
00:27:25,080 --> 00:27:28,263
at the real keyboard.

517
00:27:29,310 --> 00:27:32,880
And we separate the modes.

518
00:27:32,880 --> 00:27:37,597
The first mode was when the
keyboard isn't paired yet.

519
00:27:41,580 --> 00:27:44,730
When the keyboard enters
in the pairing mode,

520
00:27:44,730 --> 00:27:49,470
it starts sending advertising
indications like this,

521
00:27:49,470 --> 00:27:53,130
that has the appearance
that is the keyboard.

522
00:27:53,130 --> 00:27:54,630
And the company in this case,

523
00:27:54,630 --> 00:27:56,283
we use a Microsoft keyboard.

524
00:27:58,800 --> 00:28:01,803
This message include the BD
address, or the Mac address.

525
00:28:02,790 --> 00:28:06,870
During this mode, it also
send a scanned response

526
00:28:06,870 --> 00:28:09,330
that includes the full device name,

527
00:28:09,330 --> 00:28:11,943
and the advertising others.

528
00:28:13,710 --> 00:28:18,690
But it's not realistic that the attacker

529
00:28:18,690 --> 00:28:23,690
were always, when the
pairing is performing.

530
00:28:24,270 --> 00:28:28,350
So there are another way
to get the Mac address,

531
00:28:28,350 --> 00:28:29,880
and it's when the keyboard

532
00:28:29,880 --> 00:28:32,313
is reconnecting to the Windows PC.

533
00:28:33,390 --> 00:28:36,870
And it's this kind of
message that are advertising

534
00:28:36,870 --> 00:28:39,480
that indication, that
includes the BD address

535
00:28:39,480 --> 00:28:44,373
of the keyboard and the
Mac address of the PC.

536
00:28:46,080 --> 00:28:48,750
Once we have all this information,

537
00:28:48,750 --> 00:28:51,030
we could write the configuration file

538
00:28:51,030 --> 00:28:53,790
that we need to run the attack.

539
00:28:53,790 --> 00:28:56,710
And it includes the report handle,

540
00:28:56,710 --> 00:28:58,680
the report size, and the operation type

541
00:28:58,680 --> 00:29:01,773
that we collect before
analyzing our replica.

542
00:29:02,700 --> 00:29:06,240
And the last attribute
on the configuration file

543
00:29:06,240 --> 00:29:09,630
was the text script
that are the characters

544
00:29:09,630 --> 00:29:13,053
that we want to send to the victim.

545
00:29:14,130 --> 00:29:17,460
We could include in these characters

546
00:29:17,460 --> 00:29:19,020
some special characters like

547
00:29:19,020 --> 00:29:21,870
Left Windows or Enter, using braces.

548
00:29:21,870 --> 00:29:25,560
And we could send two
keys pressed together

549
00:29:25,560 --> 00:29:30,560
like Left Windows plus R that
are in the first example.

550
00:29:31,080 --> 00:29:32,760
In this case, for example,

551
00:29:32,760 --> 00:29:35,640
is to open the room dialogue of Windows,

552
00:29:35,640 --> 00:29:38,130
the shortcut to open the room dialogue.

553
00:29:38,130 --> 00:29:41,490
And we also use the special actions,

554
00:29:41,490 --> 00:29:45,813
using the common name and arguments.

555
00:29:47,310 --> 00:29:50,110
This example of text script

556
00:29:51,030 --> 00:29:54,960
opens the run dialogue of Windows,

557
00:29:54,960 --> 00:29:57,630
right PowerShell, press Enter,

558
00:29:57,630 --> 00:30:02,630
and then sleep for 500 milliseconds.

559
00:30:03,180 --> 00:30:07,173
And then open a card that is
a common proof of concept.

560
00:30:08,850 --> 00:30:13,650
Once we have this
configuration file written,

561
00:30:13,650 --> 00:30:16,740
we could call the KB injection pile

562
00:30:16,740 --> 00:30:21,460
that only needs the
HCI where the dongle is

563
00:30:23,640 --> 00:30:26,577
identified the BD address

564
00:30:27,710 --> 00:30:29,757
of the keyboard that
we want to impersonate,

565
00:30:29,757 --> 00:30:32,070
and the confirmation file.

566
00:30:32,070 --> 00:30:34,440
We add two more options,

567
00:30:34,440 --> 00:30:37,603
that is the run forever,
that I said before.

568
00:30:39,213 --> 00:30:43,080
Send in a loop the keystrokes
that we want to inject.

569
00:30:43,080 --> 00:30:47,160
And an act that prints common HCI comments

570
00:30:47,160 --> 00:30:50,373
instead of running directly.

571
00:30:53,280 --> 00:30:54,750
- We are approaching the end of our talk.

572
00:30:54,750 --> 00:30:57,690
This is demo time again, but this time at,

573
00:30:57,690 --> 00:30:59,553
let's say the real time pace.

574
00:31:00,750 --> 00:31:02,630
This is the actual demo of the attack.

575
00:31:02,630 --> 00:31:05,310
This is the scenario
that you can find here,

576
00:31:05,310 --> 00:31:07,740
the victim, the legitimate keyboard,

577
00:31:07,740 --> 00:31:09,570
and the attacker Linux PC

578
00:31:09,570 --> 00:31:13,410
that is connected to this dongle here.

579
00:31:13,410 --> 00:31:16,320
And what we can see here
is that the legitimate user

580
00:31:16,320 --> 00:31:21,270
is just typing his work
onto to the Windows machine.

581
00:31:21,270 --> 00:31:25,230
Just typing his regular work,
as we can see right now.

582
00:31:25,230 --> 00:31:28,020
And eventually what is going to happen,

583
00:31:28,020 --> 00:31:33,020
is that this regular
user will stop typing,

584
00:31:33,330 --> 00:31:35,520
because he wants a coffee or whatever.

585
00:31:35,520 --> 00:31:38,070
And at this point in time,

586
00:31:38,070 --> 00:31:40,263
this inactivity period is going to start.

587
00:31:42,030 --> 00:31:43,860
Now we are going to see that

588
00:31:43,860 --> 00:31:46,680
while this inactivity period is counting,

589
00:31:46,680 --> 00:31:49,320
the attacker launches his attack.

590
00:31:49,320 --> 00:31:51,600
And it launches using all the techniques

591
00:31:51,600 --> 00:31:53,790
that we have explained to you.

592
00:31:53,790 --> 00:31:56,730
The important thing here
is that the attacker

593
00:31:56,730 --> 00:31:59,220
doesn't have to synchronize himself

594
00:31:59,220 --> 00:32:01,860
to the point in time where
the legitimate keyboard

595
00:32:01,860 --> 00:32:03,480
is going to be disconnected.

596
00:32:03,480 --> 00:32:05,230
He doesn't need to do that because

597
00:32:06,330 --> 00:32:07,650
as soon as he launches the attack,

598
00:32:07,650 --> 00:32:09,930
the fake device will start advertising.

599
00:32:09,930 --> 00:32:12,660
And this advertising
messages will be just ignored

600
00:32:12,660 --> 00:32:14,370
by the Windows machine
because the Windows machine

601
00:32:14,370 --> 00:32:17,460
is just still connected to
the legitimate keyboard.

602
00:32:17,460 --> 00:32:20,190
So the attacker can launch the attack,

603
00:32:20,190 --> 00:32:23,940
and just wait for the legitimate
keyboard to disconnect.

604
00:32:23,940 --> 00:32:25,800
Which is what we are doing right now.

605
00:32:25,800 --> 00:32:29,130
We are fast forwarding time
just to reach the point

606
00:32:29,130 --> 00:32:31,680
where the legitimate keyboard
is going to be disconnected

607
00:32:31,680 --> 00:32:34,590
to save energy, as we
have explained before.

608
00:32:34,590 --> 00:32:38,370
Which in this case for this
keyboard, was about 10 minutes.

609
00:32:38,370 --> 00:32:39,450
And as we can see right now,

610
00:32:39,450 --> 00:32:41,220
the keyboard is going to be disconnected.

611
00:32:41,220 --> 00:32:44,460
We can see here in the
control panel window.

612
00:32:44,460 --> 00:32:45,900
And at this point, the Windows machine,

613
00:32:45,900 --> 00:32:48,570
acting as a master will try
to create a new connection,

614
00:32:48,570 --> 00:32:51,270
will try to reconnect or
create a new connection

615
00:32:51,270 --> 00:32:54,060
to be activated as soon as
the keyboard appears again.

616
00:32:54,060 --> 00:32:55,920
But the keyboard that is going to appear

617
00:32:55,920 --> 00:32:57,210
is not the legitimate one,

618
00:32:57,210 --> 00:33:00,030
it's our keyboard that we are trying to,

619
00:33:00,030 --> 00:33:02,430
that we are impersonating
the legitimate keyboard.

620
00:33:02,430 --> 00:33:05,610
And all these keystrokes have
been injected, as you can see.

621
00:33:05,610 --> 00:33:07,680
In this case, we've
launched a power shell,

622
00:33:07,680 --> 00:33:11,760
and we've just written a downloader

623
00:33:11,760 --> 00:33:13,140
that downloads this malware,

624
00:33:13,140 --> 00:33:15,270
that just for the proof of concept,

625
00:33:15,270 --> 00:33:18,771
just shows this image and that's all.

626
00:33:18,771 --> 00:33:21,938
(audience applauding)

627
00:33:27,330 --> 00:33:28,580
Thanks a lot, by the way.

628
00:33:29,670 --> 00:33:33,750
We have this other demo to show you that

629
00:33:33,750 --> 00:33:38,730
this attack not only works for keyboards.

630
00:33:38,730 --> 00:33:43,730
It also work for other
HID devices, like a mouse.

631
00:33:44,220 --> 00:33:48,420
In this case we've just
recorded a proof of concept.

632
00:33:48,420 --> 00:33:51,690
The principles of the
attack are exactly the same.

633
00:33:51,690 --> 00:33:53,040
The only thing that changes is that

634
00:33:53,040 --> 00:33:54,780
the format of the PDU's that we're sending

635
00:33:54,780 --> 00:33:57,570
contained a different data,
because the HID format

636
00:33:57,570 --> 00:33:59,190
of the mouse is different
from the keyboard.

637
00:33:59,190 --> 00:34:02,040
But other than that, the
principles are exactly the same.

638
00:34:02,040 --> 00:34:05,973
As you can see, the keyboard
gets disconnected and then,

639
00:34:08,010 --> 00:34:10,203
and then the fake mouse will,

640
00:34:12,000 --> 00:34:14,520
the Windows box will
connect to the fake mouse

641
00:34:14,520 --> 00:34:17,910
just as it did for the fake keyboard.

642
00:34:17,910 --> 00:34:21,540
And we program some movements
and some clicks of the mouse,

643
00:34:21,540 --> 00:34:26,540
just to show this square on
the Paint program of Windows.

644
00:34:27,000 --> 00:34:30,450
And we have left another demo
for you, is the one that shows

645
00:34:30,450 --> 00:34:33,750
how many keystrokes we are able to produce

646
00:34:33,750 --> 00:34:36,180
in only one connection, in only one shot.

647
00:34:36,180 --> 00:34:37,350
And this is the demo.

648
00:34:37,350 --> 00:34:39,270
I'm going to let it run at real time,

649
00:34:39,270 --> 00:34:43,050
because even if it
lasts for a few seconds,

650
00:34:43,050 --> 00:34:47,790
we wanted you to see the
real time of the attack.

651
00:34:47,790 --> 00:34:50,400
So at this point in time,

652
00:34:50,400 --> 00:34:51,780
the attacker has launched the attack.

653
00:34:51,780 --> 00:34:55,620
And as you can see,
keystrokes start coming.

654
00:34:55,620 --> 00:34:56,670
And they keep coming,

655
00:34:56,670 --> 00:34:58,803
they keep coming up to the point that the,

656
00:35:00,687 --> 00:35:03,400
the master, which in this
case is the Windows machine,

657
00:35:04,350 --> 00:35:06,750
will disconnect, will drop the connection

658
00:35:06,750 --> 00:35:08,790
using the terminate indication command.

659
00:35:08,790 --> 00:35:10,814
As you can see, this is real time.

660
00:35:10,814 --> 00:35:14,370
This is all the keys that we can send

661
00:35:14,370 --> 00:35:16,713
to the master in only one connection.

662
00:35:17,700 --> 00:35:19,200
In this case we are sending it to the,

663
00:35:19,200 --> 00:35:22,350
just to the Notepad, just to illustrate

664
00:35:22,350 --> 00:35:24,900
that this is just a proof of concept.

665
00:35:24,900 --> 00:35:27,600
But just to count how many keystrokes

666
00:35:27,600 --> 00:35:29,610
we are able to inject.

667
00:35:29,610 --> 00:35:31,890
And at the end, as you can see here,

668
00:35:31,890 --> 00:35:35,970
more than 13,000 keys have been injected.

669
00:35:35,970 --> 00:35:38,130
And we think that this is more than enough

670
00:35:38,130 --> 00:35:39,990
to write some downloader,

671
00:35:39,990 --> 00:35:43,230
or even some PowerShell
malware or whatever.

672
00:35:43,230 --> 00:35:45,783
So the impact is that way.

673
00:35:48,360 --> 00:35:51,810
And finally, we did the voluntary
disclosure with Microsoft.

674
00:35:51,810 --> 00:35:53,490
They, in February this year,

675
00:35:53,490 --> 00:35:56,310
they immediately acknowledged the bug.

676
00:35:56,310 --> 00:35:58,942
And the bug is already solved.

677
00:35:58,942 --> 00:36:01,080
The patch has been issued.

678
00:36:01,080 --> 00:36:03,273
So please patch your systems.

679
00:36:04,890 --> 00:36:06,573
And if you want to play with it,

680
00:36:07,650 --> 00:36:10,137
we have made this publication we have.

681
00:36:10,137 --> 00:36:13,920
I mean, you have this talk if
you want to review the attack,

682
00:36:13,920 --> 00:36:16,080
or to understand the
attack, or to play with it.

683
00:36:16,080 --> 00:36:18,390
And if this talk is not enough,

684
00:36:18,390 --> 00:36:21,000
because our English is
not very good looking,

685
00:36:21,000 --> 00:36:23,100
then we have tried to write down

686
00:36:23,100 --> 00:36:25,680
all the things here in
our post, in our blog.

687
00:36:25,680 --> 00:36:28,500
And we also have all the tools

688
00:36:28,500 --> 00:36:31,323
and our modified firmware
in our GitHub page.

689
00:36:32,280 --> 00:36:34,500
And we left here some reference for you,

690
00:36:34,500 --> 00:36:36,270
the reference for the
tools that we have used

691
00:36:36,270 --> 00:36:40,680
for make the captures, the
Zephyr project, and other things,

692
00:36:40,680 --> 00:36:45,090
and also the references
to the specifications,

693
00:36:45,090 --> 00:36:46,560
and some previous work that we have read.

694
00:36:46,560 --> 00:36:49,080
They're not directly
related with our work,

695
00:36:49,080 --> 00:36:50,880
because they're quite different.

696
00:36:50,880 --> 00:36:51,870
But we have read them,

697
00:36:51,870 --> 00:36:56,190
so we left here also for your reference.

698
00:36:56,190 --> 00:36:58,860
And that will be all from our part.

699
00:36:58,860 --> 00:37:01,080
And we thank you very
much for your attention.

700
00:37:01,080 --> 00:37:02,010
If you have any question,

701
00:37:02,010 --> 00:37:04,350
we will be around and we'll have more.

702
00:37:04,350 --> 00:37:06,068
(audience applauding)