Well, hi, everyone, again, and welcome to this talk, which is about one vulnerability
that we have found in Microsoft Windows that allows an attacker to inject keystrokes impersonating
previously per the legitimate keyboard.
But before going further in the presentation, let us try to get your attention and put the
cart before the horses and show you this very, very accelerated version of our demo video.
And please pay attention because it's going to be quick.
This is the scenario.
This is the legitimate keyboard going disconnected.
Then this is the attacker launching.
This is the attacker launching the attack.
And then as soon as the attacker launches the attack, the fake device is going to be
present in the space.
And then the Windows watch connects to the fake device and the keys get injected.
We hope that everything is clear for everyone.
But if it is not, we have the rest of the talk to try to explain it to you.
So please be with us.
And thank you.
And hopefully we explain it right to you.
Hello, everyone.
Now I try to explain the video again, but this time slowly.
So the first thing to know is who are the participants in the video.
And we have a Windows PC, a Bluetooth Low Energy keyboard, and the attacker that are
using a Linux PC with a special dongle.
Before the video starts.
Bluetooth Low Energy Keyboard and the Windows PC perform the Bluetooth pairing in order
to establish an encrypted channel, and all the data that they are communicating are encrypted.
So every time that the Bluetooth Low Energy Keyboard reconnects with the Windows PC, the
encryption channel, the encrypted channel is established.
And all the data will be encrypted.
As the Bluetooth Low Energy Keyboard is a low energy device, after a few period, after
a little period of time, the keyboard disconnects in order to save some energy.
And it's in this moment when an attacker could impersonate the Bluetooth Low Energy
Keyboard and send some keystrokes, some not encrypted keystrokes.
But how is this possible?
We said before that the Windows PC and the keyboard establish an encryption channel every
time that it reconnects.
We send not encrypted data and are accepted by the Windows.
So that's what this talk is about.
Let's start from the beginning.
He's Jose and I'm Fernando.
We are security researchers.
We like to play with security.
And with communication protocols.
We also climb and ride motorbikes as you could see in the photo in our spare time.
We come from Spain and work in LIAC.
And what we saw in this talk, we start with a brief description of Bluetooth Low Energy
concepts.
Some concepts only in order to understand better the vulnerability.
Then we detail how this attack is possible and what parts of the specs of the Bluetooth
specs and Windows allow this attack.
Then we show you two approaches of how we try to exploit this vulnerability.
The first one doesn't work and the second approach is the current exploit.
We continue with a proof of concept.
Showing all the hardware.
And software that we need to perform the attack and some demos and conclude this talk showing
some data about the vulnerability disclosure.
Some related publications and reference that help us to find and exploit this vulnerability.
As you will see during the talk, the attack is extremely simple, but we think that it's
important to introduce some Bluetooth Low Energy concepts.
That help.
That help to understand the attack, especially if you're not familiar with the Bluetooth
protocols.
And the first one of these concepts is this concept of pairing.
When two Bluetooth devices want to protect their communications, they must finish this
pairing procedure, as they call it.
The objective of this procedure is to establish a key, which is called the long-term key,
that will be used every...
By the way, this is only performed the first time they connect.
And then they keep this long-term key.
And then they keep this long-term key.
And then they keep this long-term key.
And they use it every time they want to connect each other again to derive a session key that
is the key that is going to protect this particular connection.
We are not talking about the different pairing schemes or association models because they
are not relevant for the attack.
We just left them here for your reference.
But we do want to talk about another concept, about Bluetooth Low Energy protocols, is that
the layers...
The layer set.
The layer set is split in two parts.
The host part, which holds the upper part of the protocol, which contains the L2CAP protocol,
also the ATT protocol that manages and shows and interacts with the attributes of every
device.
This upper part talks with the application layer, which is above it.
In our case, the application layer would be the HID, the human interface device, which
is because we are attacking a keyboard.
And the lower part of the protocol layers are called the controller one.
And you will find several different configurations of that.
For example, in the keyboard case, you will find that the host and the controller are
both implemented in the keyboard.
But for example, if we are talking about a Windows box or a Linux box, the host is implemented
in the operating system.
For example, if you have Linux, the host is the implementation of that.
And the controller is implemented in the firmware of the device that you are using.
Either an embedded device, or a chipset, or an external dongle, this firmware implements
a controller.
The communication between these two parts is very straightforward, called host to controller
interface, HCI.
And the host sends information to the controller by one thing that is called commands, and
the controller sends the host events.
It is just a question of names.
But the...
One of the important things, or one of the things that we want to emphasize here is that
encryption happens at the link layer.
So the host part doesn't do anything about encryption, except maybe, no, not maybe, except
just managing the state of the encryption and calculating the long-term key.
And that's all.
And whenever the link layer needs the long-term key to calculate the session key, then the
host part provides this long-term key.
So this is a very important concept, and you will see why during our presentation, because
it's very directly related with the attack.
And we have still one more concept to introduce to you before explaining the attack, which
is let's imagine this is a scenario where we have the master device, and we are using
here the Bluetooth 5.2 specification terminology.
In our case, in our scenario, the master device is the Windows machine.
And we have the slave device in our scenario.
The slave device is a Bluetooth low-energy keyboard.
And we have the situation here.
We...
We...
The start point is the situation where these two devices have previously paired, completed
the pairing procedure that I talked before.
So they both have the long-term key associated with this connection.
And they want to reconnect.
They want to create a new connection.
And we are going to see right now what happens here and how does it work.
So the master, the host part of the master instructs the link layer to create a connection.
It just provokes in the link layer that the link layer starts listening.
For the slave to appear in the air.
And more particularly to advertising messages from the slave.
The slave is sleeping right now, because he went to sleep to save energy.
And he restarts whenever the user presses a key.
And then it provokes that the host informs or instructs the link layer
to start advertising himself with these commands of advertising enable.
Then, eventually, these...
One of these advertising messages goes off.
gets to the link layer of the master,
and then the master answers back
with a connect indication link layer message
to the link layer of the slate.
Please see that this, everything happens at the link layer,
so the host is only participating in the controlling part
of the state of protocol.
At this point of the protocol,
the connection has been created,
and both link layer inform their correspondent host part
that the connection has been created.
The connection is created, but it's not encrypted,
not encrypted yet.
This is what is going to happen now.
The master that holds the long-term key
knows that this connection should be encrypted,
so it, as soon as the connection is created,
it should, and it usually does,
it instructs the link layer to start encryption.
Then, at this point, the link layer calculates its part,
the master part, of two random values,
the SKDA, which is the session key diversifier,
and an initialization vector.
These two, these two,
this part is sent to the slave,
to the link layer of the slave,
with encryption request PDU,
and the slave calculates its part of these values,
and send back it with the encryption response PDU
to the link layer of the master.
If you think there is one thing left,
is that the slave does not have the long-term key.
The master, the link layer of the master,
do have the long-term key,
because it has been provided
with the enable encryption command,
but the slave doesn't have that,
so it has to ask for it,
and if the host of the slave has the long-term key,
which is the case,
it will answer back with the long-term key.
At this point, both devices can calculate
the session key diversifier,
because they have both parts,
and the initialization vector,
which I just remind you that these are random numbers,
and they both can calculate the session key
that is going to protect this particular connection.
The session key is calculated by encrypting
the session key diversifier,
using as encryption key the long-term key,
and as initialization vector,
the calculated initialization vector.
So at this point, both have calculated the session key,
and the only thing that's left to finish
the start encryption procedure, let's say that,
is to, let's say, agree on the point in time
where the encryption starts,
and this is made with this kind of handshake,
handshake, handshake, you say that,
that starts with a start encryption request command,
send not encrypted by the link layer,
and then, sorry, by the link layer of the slave,
then the link layer of the master answers back
with a standard encryption response,
and this message is already be encrypted
with the session key, okay?
So if the slave receives this message,
and it is able to decrypt it,
then it's, so to speak, kind of authentication
of this master.
And it does exactly the same thing,
it encrypts this encryption response command
with this just calculated session key.
And so both are, let's say, authenticated
and the connection is encrypted, is protected.
At this point, it's very important,
and this is very, very important
for the attack that we're spending here
is that at this point the link layer informs the host
that the encryption has started.
And it's at this point that encryption has started
and not before.
And you will understand just in a couple of slides
that why I'm emphasizing this.
Every next or every subsequent PD use
will be encrypted from now on
for this particular connection.
So we've seen these three or four concepts about Bluetooth
and now we are going to explain how it is possible
to inject keys with all these context that we have explained.
So what makes the attack possible?
In fact, there are two things that make the attack possible.
The first thing is one thing that we don't call it
a vulnerability.
It's something that is present,
it's explicitly defined in the specification,
in the Bluetooth standard.
And it's the fact that when the slave device receives
the encryption request PDU,
it is explicitly allowed to send any remaining PDUs
that he has to send to the master
and he has in his queues in a non-encrypted,
in a not encrypted way.
It's explicitly allowed.
And I can show you the part of the standard
where this is written down.
This is, from our point of view,
this is not a vulnerability.
It's just something that is there to allow the slave
to empty its queues before continue
to send in encrypted data.
So this is the PDU, or encrypted data.
But the second one, the second thing that allows the attack,
this is the vulnerability.
Sorry, before that, what I wanted to say in this slide
is that this characteristic that I just explained
creates a window of opportunity for an attacker
trying to impersonate the slave device
where he can send data through the connection,
through the Bluetooth connection,
and the master, sorry, the link layer of the master
will accept this PDU.
These PDUs will accept this data.
And it is the responsibility of the upper part
of the protocol to consider that this data is valid or not.
And this is precisely the second thing that allows the attack,
which is the vulnerability.
It seems that Microsoft Windows does not wait for this event,
which is the encryption change event,
does not wait for this event, which is the encryption change event,
to consider that any PDU coming from the slave, it's legit.
So it seems that it considers that encryption has started
as soon as the host part of the master
orders the encryption to start, which is not the case.
You have to wait until receiving
this encryption change event.
So this allows us to try to impersonate the slave
up to this point and send all these unencrypted PDUs
without actually knowing the long-term key
which will be needed to really complete
this procedure of start encryption.
And this is the thing that allow the attack.
These are the two things that allow the attack.
Okay, now we will explain the two approaches
that we follow in order to try to exploit this vulnerability.
As I said before, the first one is working at the host level.
Work with the host level has a very big problem
that is that we don't decide when the message
are really sent, we only tell the controller part
to send some data to some high level data.
But we doesn't decide where exactly this data is sent.
We are trying to put some PDUs between the encryption
request and encryption response and we couldn't decide
where
the PDUs we try to send are exactly as put.
And to implement this approach we use an HCI adapter,
a common HCI adapter with the only particularity
that it allows to change the video address
in order to impersonate the Bluetooth keyboard
and use the Mirage framework.
The Mirage framework is among other things,
allows among other things to hook some parts of the
communication and change the normal flow
of this communication and we use it to intercept
the connection event and after this event,
we start to send keystrokes and doesn't send anything else.
As I said that it doesn't decide where the message
are effectively sent, we need some tries to succeed
and put some of these keystrokes between the encryption
request and encryption response and now we will show you
some capture in the air.
We just sniffled to capture this message that is a
Bluetooth low energy sniffer.
In the left side you could see the...
.
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
slave. And the slave is trying to send more keystrokes. Then the controller part of the
fake slave responds automatically with an encryption response and asks for the
long-term key. As we haven't got the long-term key, the key missing is sent back to the
controller and it is translated to the indication. Once this message is received, it
closed the connection immediately because the encryption channel could not be
established. And our fake slave continued trying to send some keystrokes. The most
important thing in these slides is to understand that we are trying to send
then a lot of keystrokes between encryption request and response and as we have no control
about when the data is sent, we can decide that these keystrokes hit between encryption
request and response. There are only one notification message that hit there and it means that there
are only one keystroke that are effectively injected and processed by the master. So we
realize that if we want to exploit this vulnerability, we should go down and develop something that
works in the controller level.
And this is what we did and this is actually the implementation of the attack. We implemented
the attack at the link layer level, at the controller level. In order to do that, we
used this
let me say that's fantastic framework which is called the Cephar. It's completely from top to
bottom open source implementation of the Bluetooth low energy protocol stack. So this you can compile
that and create a firmware that can run in one of these dongles which is a Nordic RF 5052H40
that has very very very few costs, it's very small cost and when we
implement this at the link layer what we can do is to control where these keystrokes
that we want to send can fall into the protocol state so we can control that. We can
allow the protocol at the link layer to reach this point and then we can freeze the protocol
a
and send all the keystrokes that we want to send,
there is no tomorrow,
and then just wait for the master
to terminate the connection.
The master will terminate the connection
because he's actually waiting
for the encryption response command, PDU, sorry.
And this will never arrive
because we are not going to send it.
So a timeout will expire here,
and after this timeout expires,
the master sends the terminate indication PDU,
just dropping the connection.
But at this point, all the keystrokes that we have sent
have been already accepted by the master.
And we can see that in IR capture,
like I'm going to show you right now.
In this IR capture, you can see
that the connect request comes,
and then all the subsequent normal link layer messages
that, let's say, advance in the state of the connection,
which objective is eventually to encrypt it.
But as soon as we received the encryption request PDU,
what we do is to,
we freeze the link layer in the fake slave.
And then instead of continuing the normal functioning
of the link layer that will be to send encryption response,
to ask for the long-term key to our host part,
et cetera, et cetera,
we just don't do that.
And instead of that,
we send all the keystrokes that we want to send,
as you can see here.
And we send all of them.
And when eventually, we send all of them,
and then we stop sending things.
We just wait for the master,
to drop the connection.
But all these keys have been already been accepted.
Now we have an exploit that allow us
to inject some keystrokes into the master.
But we want to try to increment the number of keystrokes
that we can inject in one connection.
So we try to send a lot of keystrokes
with no waiting time.
But this cause a problem,
because at the beginning of the communication,
if we try to send a lot of keystrokes,
some of these messages are lost,
or aren't processed by the master.
So we implement this exponential decrement of waiting time
that starts waiting four seconds.
That is a lot of time, but it works.
And then, every time that,
a keystroke is sent,
divide this waiting time by two,
until they reach 20 milliseconds.
This implementation allow us to inject
whatever 13,000 keystrokes in one connection
of 30 seconds.
And we have a demo at the end of the talk.
We implement other upgrades,
in order to
make easy the
configuration of theстаvers,
of the dongle. We implement these HCI vendor commands to program the dongle with some characteristics
of each device and what case strokes we want to send in every connection without having
to recompile server every time that we want to change something. We include an HCI command
to program the handle, the report size and operation type and to clear the list of the
keystrokes that will be sent and add a keystroke to be sent when the connection is established.
We also implement some special actions. For example, this is the action to sleep. We can
tell the dongle to sleep some milliseconds between
between two keystrokes are sent. In this case, it's a sleeping 500 milliseconds. And we implement
another option that was the room forever that is ‑‑ we think that is only for testing
purpose to ‑‑ and it allows us to repeat the list of keystrokes in a loop until the
connection is closed by the master. So now, let's see what we need to perform the attack.
And we need the Nordic dongle that costs about 30 dollars. It's a Bluetooth low energy dongle.
We also need our modified software that you can find in our GitHub. I don't know if it
is published now.
You can find it on our GitHub.
With these two things, you can program the dongle, but it's quite hard because you need
to use the HCI tool and put the bytes manually, and we developed some auxiliary tools that
help us to program the dongle in a more user-friendly way.
Before we can perform the attack, we need to know some characteristics about the Bluetooth
Low Energy Keyboard that we want to impersonate, and basically we need to know how this specific
keyboard sends the report data to the master, and the MAC address of the real keyboard that
we want to impersonate.
Okay.
The first data that we need could be extracted using a replica, and analyzing the communications
is very easy because you press a key on a legitimate keyboard.
You could see on Wireshark that it's sending a report using a specific handle, in this
case it's the 13, with a specific structure that has 11 bytes.
And the operation type or opcode that is a notification, and usually it's a notification.
And to get the MAC address, we could listen in the air at the real keyboard, and we separate
two modes.
The first mode was when the keyboard isn't paired yet, and before, when the keyboard
enters in the pairing mode.
It starts sending advertising indications like this, that has the appearance that is
a keyboard, and the company, in this case, which is a Microsoft keyboard, and this message
includes the video address or the MAC address.
During this mode, it also sends a scan response that includes the full device name and the
advertising address.
But it's not a good thing.
It's not realistic that the attacker is where always when the pairing is performing.
So there are other ways to get the MAC address, and it's when the keyboard is reconnecting
to the Windows PC, and it's this kind of message that are advertising direct indication
that includes the video address of the keyboard and the MAC address of the PC.
Thank you.
Once we have all this information, we could write the configuration file that we need
to run the attack, and it includes the report handle, the report size, and the operation
type that we collect before analyzing a replica.
And the last attribute on the configuration file was the text script that are the characters
that we want to send to the victim.
.
.
We could include in these characters some special characters like left windows or enter
using braces, and we could send two keys pressed together like left windows plus R,
that are in the first example.
In this case, for example, it's to open the room dialog of Windows, the shortcut to open
the room dialog.
And we also use the special actions using the command name.
And arguments.
This example of text script opens the run dialog of Windows, write PowerShell, press
enter, and then sleep for 500 milliseconds, and then open a card that is a common proof
of concept.
Once we have this configuration file written.
written we could call the KB injection file that only needs the HCI where the dongle is
Identified
the video address the
Of the keyboard that we want to impersonate and the configuration file
We add two more options that is the room forever that as I said before
Send in a loop the keystrokes that we want to
inject and the NOAC that prints common HCI commands instead of
running directly
We are approaching the end of our talk this is demo time again, but this time at let's say the real-time pace
This is the the actual demo of the attack
This is the scenario that you can you can find here the victim the legitimate keyboard and the attacker Linux PC that is
connected to
To this dongle
Here and what we can see here is that the legitimate user is just typing its work
Onto the to the windows machine
just typing his regular work as we can see right now and
Eventually what is going to happen is that this regular user?
Will it will stop will stop typing?
Because he wants a coffee or whatever and at this point in time this inactivity period is going to start
Now we are going to see that while this inactivity period is counting, the attacker launches
his attack and it launches using all the techniques that we have explained to you.
The important thing here is that the attacker doesn't have to synchronize himself to the
point in time where the legitimate keyboard is going to be disconnected.
He doesn't need to do that because as soon as he launches the attack, the fake device
will start advertising.
And these advertising messages will be just ignored by the Windows machine because the
Windows machine is just still connected to the legitimate keyboard.
So the attacker can launch the attack and just wait for the legitimate keyboard to disconnect,
which is what we are doing right now.
We are fast-forwarding time just to reach the point where the legitimate keyboard is
going to be disconnected to save energy, as we have explained before.
Which in this case, for this keyboard, was about ten minutes.
And as we can see right now, the keyboard is going to be disconnected.
We can see here in the control panel window.
And at this point, the Windows machine acting as a master will try to create a new connection.
It will try to reconnect or create a new connection to be activated as soon as the keyboard appears
again.
But the keyboard that is going to appear is not the legitimate one.
It's our keyboard that we are impersonating the legitimate keyboard.
And all these keystrokes have been injected, as you can see.
In this case, we've launched a PowerShell.
And we've just written a downloader that downloads this malware that just for the proof of concept
just shows this image.
And that's all.
Thanks a lot, by the way.
We have this other demo to show you that this attack not only works for...
For keyboards, it also works for other HID devices like a mouse.
In this case, we've just recorded a proof of concept.
The principles of the attack are exactly the same.
The only thing that changes is that the format of the PDUs that we're sending contain different
data because the HID format of the mouse is different from the keyboard.
But other than that, the principles are exactly the same.
As you can see, the keyboard gets disconnected.
And then...
Okay.
And then the fake mouse will...
The Windows box will connect to the fake mouse just as it did for the fake keyboard.
And we programmed some movements and some clicks of the mouse just to show this square
on the paint program of Windows.
And we have left another demo for you.
It's the one that shows how many keystrokes we are able to produce in only one connection,
in only one shot.
And this is the demo.
I'm going to let it run at real time because even if it lasts for a few seconds, we wanted
you to see the real time of the attack.
So at this point in time, the attacker has launched the attack.
And as you can see, keystrokes start coming.
And they keep coming.
They keep coming up to the point that the master, which in this case is the Windows
machine, will disconnect.
Okay.
And we'll drop the connection using the terminate indication command.
As you can see, this is real time.
This is all the keys that we can send to the master in only one connection.
In this case, we are sending it just to the notepad, just to illustrate that this is just
a proof of concept.
But just to count how many keystrokes we are able to inject.
And at the end, as you can see here, more than 13,000 keys have been...
Injected.
And we think that this is more than enough to write some downloader or even some PowerShell
malware or whatever.
So the impact is that way.
And finally, we did the vulnerability disclosure with Microsoft in February this year.
They immediately acknowledged the bug and the bug is already solved.
The patch has been issued.
So please patch your systems.
Okay.
Okay.
So if you want to play with it, we have made this publication.
You have this talk if you want to review the attack or to understand the attack or to play
with it.
And if this talk is not enough because our English is not very good looking, then we
have tried to write down all the things here in our post in our blog.
And we also have all the tools and our modified firmware in our GitHub page.
And we left here some reference for you.
The reference for the tools that we have used for making the captures, the CFR project,
and other things.
And also the references to the specifications.
And some previous work that we have read, they are not directly related with our work
because they're quite different.
But we have read them.
So we left here for also for your reference.
And that will be all from our part.
And we thank you very much for your attention.
If you have any questions, we will be around and we'll have more.
Have a good one.
Thank you.