 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 paired legitimate keyboard. But before going further in the presentation, let us try to get your attention and put the car 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 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 works 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 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 we need 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 encrypted channel is established and all the data will be encrypted. As the Bluetooth low-energy keyboard is a low-energy device, after a little period of time, the keyboard disconnects in order to save some energy. And is in this moment when an attacker could impersonate the Bluetooth low-energy keyboard and send some keystrokes, not encrypted keystrokes. But how is this possible? Because we said before that the Windows PC and the keyboard establish an encryption channel every time that it reconnects. And we send not encrypted data and are accepted by the Windows. So that's what this talk is about. And let's start from the beginning. Here'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 Lyac. And what we saw in this talk, we started 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 proof of concepts 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 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 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're not talking about the different payment schemes or association models because they're 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 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, you have Linux, the host is the blue set implementation of that. And the controller is implemented in the firmware of the device that you are using. Either an embedded device, a chipset or an external dongle. This firmware implements a controller. The communication between these two parts is very straightly forward called host to controller interface, HDI. And the host sends information to the controller by one thing that is called commands. And the controller sends to the host events. It's just a question of names. But 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 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 the Bluetooth low energy keyboard. And we have the situation here. 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 this command set advertising enabled. And then eventually, one of these advertising messages 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 slave. 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 informs 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 esquite, which is the session key diversifier and an initiation vector. This part is sent to the slave, to the link layer of the slave, with the 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 slave has, if the host of the slave has the long-term key, which is the case, it will answer back with a long-term key. At this point, both devices can calculate the session key diversifier because they have both parts and the initiation vector, which I just remind you that these are random numbers, okay? 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 an initialization vector, they calculated initialization vector. So at this point, both have calculated the session key. And the only thing that 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, you say that, that starts with the start encryption request command, send, not encrypted by the linklier, and then, sorry, but the linklier of the slave. Then the linklier of the master answers back with standard encryption response. And this message is already 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 explaining here is that, at this point, the linklier informs the host that the encryption has started. And it's at this point that the 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 PDUs will be encrypted from now on for this particular connection. So we've seen these three or four concepts of about Bluetooth, and now we are going to explain how it is possible to inject keys with all these contexts 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, sorry, 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 the SKUs 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 SKUs before continuing to send encrypted PDUs 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 this slave device where he can send data through the connection, through the Bluetooth connection, and the master, sorry, the linklier of the master will accept this PDU, this PDUs, will accept this data. And it is the responsibility 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 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 encrypted 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 allowed the attack. This is the two things that allowed the attack. Okay, now we will explain the two approaches that we follow in order to try to exploit this vulnerability. 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 high-level data, but we don't decide where exactly the data is sent. We are trying to put some PDUs between the encryption request and the encryption response, and we couldn't decide where the PDUs we try to send are exactly 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 case strokes and doesn't send anything else. As I said, we don'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 the encryption response, and now we will show you some capturing the error. We just sniffled to capture this message that is a Bluetooth low-energy sniffler. In the left side, you could see the direction of the communication, master to slave or slave to master. And as I said, the connect request is sent by the master and received by the slave. And just after that, we start sending keystrokes, but you can see that there are some link liar message that we have not controlled and are sent. And then the normal flow of the communication start and encryption request is received by the fake slave, by the slave. And the slave is trying to send more keystrokes. Then the controller part of the fake slave respond automatically with an encryption response and ask for the longer key. As we haven't got the longer key, the key missing is sent back to the controller, and it is translated to link liar reject indication. Once master received this message, it closed the connection immediately because the encryption channel could not be established. And our fake slave continue trying to send some keystrokes. The most important thing in these slides is to understand that we are trying to send a lot of keystrokes between encryption request and encryption response. And as we have control about when the heat level that is sent, we can decide that these keystrokes hit between encryption request and encryption 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 the actually implementation of the attack. We implemented the attack at the link liar level, at the controller level. In order to do that, we use this, let me say that's fantastic framework which is called the SAFAR. It's completely from top to bottom open source implementation of the Bluetooth low energy protocol stack. So you can compile that and create a framework that can run in one of these dongles, which is a Nordic RF 52H40 that has very, very few costs, very small costs. And when we implement this at the link liar, 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 liar to reach this point. And then we can freeze the protocol 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 air capture, like I'm going to show you right now. In this air capture, you can see that the connect request comes from the master. And then all the subsequent normal link liar 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 freeze the link liar in the fake slave. And then instead of continuing the normal functioning of the link liar that will be to send the 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 what we send all of them, and then we just stop sending things, we just wait for the master to drop the connection. But all these keys have been already being 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 caused a problem because at the begin 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 keystrokes send, divide this waiting time by two, until it reaches 20 milliseconds. This implementation allow us to inject 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 dongle. We implement these HCI vendor commands to program the dongle with some characteristics of each device and what keystrokes 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 the operation type. And to clear the list of the keystrokes that will be sent and add some keystroke to 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 two keystrokes are sent. In this case, it's sleeping 500 milliseconds. And we implement another option that was the room forever that is, we think that is only for testing purpose. And it allow 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 cost about $30. It's a Bluetooth low-energy dongle. We also need our modified server firmware that you can find it in our GitHub. I don't know it. Is it published now? Yeah. You can find it in our GitHub. And with these two things, you can program the dongle, but it is quite hard because you need to use the HCI tool and put the bytes manually. And we develop some auxiliary tools that help us to program the dongle in a more user-friendly way. Okay. 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 send the report data to the master and the MAC address of the real keyboard that we want to impersonate. The first data that we need could be extracted using a replica and analyzing the communications. It's very easy because if you press a key on a real, 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 identification and user identification. 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 paid yet. And before, when the keyboard enters in the paying mode, it starts sending advertising indications like this that has the appearance that is a keyboard and the company, in this case, we use a Microsoft keyboard. And this message includes the video address or the MAC address. During this mode, it also sends a response that includes the full device name and the advertising address. But it's not realistic that the attacker were always when the pairing is performing. So there are another way 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 the identification that includes the video address of the keyboard and the MAC address of the PC. Once we have all this information, we could write the configuration file that we need to run the deck. 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 races. And we could send two keys pressed together like left windows plus R that are the first example. In this case, for example, it's to open the run dialogue of Windows, the shortcut to open the run dialogue. And we also use the special actions using the common name and arguments. This example of the text script opens the run dialogue of Windows, right PowerShell, press enter and then slip for 500 milliseconds and then open a calc that is the common proof of concept. Once we have this configuration file written, we could call the KB injection file that only needs the HCI where the dongle is identified. The video address of the keyboard that we want to impersonate and configuration file. We add two more options that is the room forever that as I told before, send in a loop the keystrokes that we want to inject and no act that prints common HCI commands instead of running it 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 actual demo of the attack. This is the scenario that you can find here, the victim, the legitimate keyboard and the attacker Linux PC that is connected to this dongle here. And what we can see here is that the legitimate user is just typing its work onto 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 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 this 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 forward in 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 10 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, 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 trying to... 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 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 contains a 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 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, will 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 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 download 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. And 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 separate project, and all the things. And also the references to the specifications. And some previous work that we have read, they're not directly related with our work because they're quite different. But we have read them. So we left here 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 question, we will be around and we'll have more how to do it.