Wireless Keystroke Injection via Bluetooth Low Energy
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 85 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/62220 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 3073 / 85
24
28
29
47
51
53
59
60
62
70
72
75
80
84
85
00:00
Vulnerability (computing)PlastikkarteKeyboard shortcutWindowVideoconferencingDemo (music)Revision controlDecision tree learningComputer animation
00:44
Keyboard shortcutSoftware protection dongleGraphics tabletConnected spaceRootMaxima and minimaPhysical systemSigma-algebraMultitier architectureKeyboard shortcutWindowCuboidSpacetimeConnected spaceOperating systemDifferent (Kate Ryan album)Flow separationCartesian coordinate systemEncryptionFirmwareMereologyImplementationLink (knot theory)Configuration spaceTelecommunicationGame controllerVideoconferencingMultiplication signProcedural programmingCommunications protocolAssociative propertySoftware protection dongleAttribute grammarComputer-assisted translationOSI modelSet (mathematics)Object (grammar)Descriptive statisticsComputer hardwareExploit (computer security)Order (biology)Theory of relativitySoftwareVirtual machineLatent heatState of matterInformation securityException handlingPoint (geometry)Moment (mathematics)InformationFood energyVulnerability (computing)Presentation of a groupDigital photographyEvent horizonEndliche ModelltheorieNumbering schemeProof theoryComputer animation
08:30
EncryptionMaxima and minimaRegulärer Ausdruck <Textverarbeitung>Division (mathematics)Menu (computing)Gamma functionLink (knot theory)Vector spaceOSI modelControl flowRandom numberField (computer science)Sheaf (mathematics)MereologyLimit (category theory)MathematicsVulnerability (computing)Convex hullLink (knot theory)Message passingAuthenticationKey (cryptography)EncryptionStandard deviationContext awarenessConnected spaceDependent and independent variablesSlide rulePoint (geometry)MereologyState of matterMultiplication signCorrespondence (mathematics)Vulnerability (computing)Vector spacePrice indexOrder (biology)Procedural programmingEvent horizonMathematicsLevel (video gaming)WindowQueue (abstract data type)CASE <Informatik>Communications protocolWritingRandom number generationLatent heatComputer animation
16:00
Control flowFood energyOSI modelFrame problemInformationCommunications protocolAttribute grammarOpcodeEmailAddress spaceConvex hullMessage passingWorld Wide Web ConsortiumDirection (geometry)CodeAddress spaceEncryptionMessage passingOpen sourceConnected spaceLink (knot theory)Direction (geometry)Level (video gaming)MereologyGame controllerNumberCommunications protocolFunctional (mathematics)Multiplication signDependent and independent variablesCausalityObject (grammar)State of matterNormal (geometry)Stack (abstract data type)ImplementationPrice indexPoint (geometry)FirmwareOrder (biology)Greatest elementKeyboard shortcutFood energyMotion captureHoaxTelecommunicationDataflowHookingSoftware frameworkReading (process)Slide ruleAuthenticationDivisorComputer animation
23:30
GEDCOMCommunications protocolDependent and independent variablesReading (process)Game controllerAlgorithmic information theoryVoltmeterFood energyEmailData typeAddress spaceFlagLatent heatLengthBroadcasting (networking)CAN busCyclic redundancy checkFrame problemOSI modelInformationKeyboard shortcutReal-time operating systemConnected spaceOrder (biology)Limit (category theory)Demo (music)Computer file2 (number)ImplementationConfiguration spaceSoftware protection dongleCharacteristic polynomialDirection (geometry)Loop (music)Multiplication signDivisorAsynchronous Transfer ModePrice indexAddress spaceProof theoryRight angleKeyboard shortcutMessage passingElectronic mailing listWindowAttribute grammarType theoryOperator (mathematics)InjektivitätData structureCASE <Informatik>Traffic reportingPlastikkarteDependent and independent variablesGroup actionParameter (computer programming)Scripting languageFood energyComputer programmingCodeWritingComputer configurationSoftware testingVideoconferencingOpcodeSystem identificationFirmwareComputer animation
31:00
VacuumGamma functionKeyboard shortcutConvex hullEvent horizonSoftware protection dongleView (database)File formatProcess (computing)Keyboard shortcutVirtual machineDemo (music)Medical imagingFrequencyPoint (geometry)Message passingMultiplication signWindowConnected spaceProof theoryCASE <Informatik>Power (physics)Software protection dongleMalwareFood energyComputer animation
33:24
Vulnerability (computing)MereologyReal-time operating systemConnected spaceWindowPoint (geometry)CASE <Informatik>Demo (music)BlogPhysical systemPatch (Unix)Computer programmingSquare numberCuboidWeb pageProof theoryFirmwareKeyboard shortcutFile formatSoftware bugMalwareProjective plane2 (number)Vulnerability (computing)Virtual machineMultiplication signComputer animation
Transcript: English(auto-generated)
00:00
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.
00:22
But before going further in the presentation, let us try to get your attention and put the card before the horses and show you this very, very accelerated version of our demo video.
00:41
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 box connects to the fake device and the keys get injected.
01:09
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.
01:24
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, Bluetooth Low Energy Keyboard, and the attacker that are using a Linux PC
01:46
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
02:05
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.
02:25
The Bluetooth Low Energy Keyboard is a low energy device. After a few periods, 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
02:43
Low Energy Keyboard and send some keystrokes, 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.
03:03
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. I'm Jose, and I'm Fernando. We are security researchers. We like to play with security and with communication protocols.
03:21
We also climb and ride motorbikes, as you could see in the photo in our spare time. We come from Spain and work in kayak. 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.
03:48
Then we detail how this attack is possible and what parts of the Bluetooth specs and the Windows allow this attack.
04:00
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
04:24
the vulnerability disclosure, some related publications and references 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
04:41
important to introduce some Bluetooth Low Energy concepts that help to understand the attack, especially if you are not familiar with the Bluetooth protocols. The first one of this concept is this concept of pairing. When two Bluetooth devices want to protect their communications, they must finish this pairing procedure, as they call it.
05:02
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.
05:24
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 layer set is split in two parts.
05:46
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.
06:01
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. The lower part of the protocol layers are called the controller one. You will find several different configurations of that.
06:22
For example, in the keyboard case, you will find that the host and the controller are both implemented in the keyboard. 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
06:41
is implemented in the firmware of the device that you are using, either an embedded device or chipset or an external dongle. This firmware implements a controller. The communication between these two parts is very straightforward, called host-to-controller interface, HDI.
07:01
The host sends information to the controller by one thing that is called commands, and the controller sends to the host events. It is just a question of names. One of the important things or one of the things that we want to emphasize here is that encryption happens at the link layer.
07:20
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. Whenever the link layer needs the long-term key to calculate the session key, then the host part provides this long-term key. This is a very important concept, and you will see why during our presentation because
07:43
it's very directly related with the attack. 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.
08:01
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. The start point is the situation where these two devices have previously paired, completely the pairing procedure that I talked before, so they both have the long-term key associated
08:22
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. 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
08:44
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
09:01
the link layer to start advertising himself with this command set advertising enable, 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
09:21
layer of the slave. Please see that everything happens at the link layer, so the host is only participating in the controlling part of the state of the protocol. At this point of the protocol, the connection has been created, and both link layers inform their correspondent host part that the connection has been created.
09:41
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 as soon as the connection is created, it should, and it usually does, instructs the link layer to start encryption. Then at this point, the link layer calculates its part, the master part, of two random values,
10:05
the SKD, which is the session key diversifier, and initialization vector. 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 sends back it with the encryption
10:21
response PDU to the link layer of the master. If you think there is one thing left, it's 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
10:45
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
11:02
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 initialization vector, they calculated initialization vector. So at this point, both have calculated the session key.
11:23
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, you say that, that starts with the start encryption
11:44
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
12:06
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.
12:25
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 link layer informs the host that the encryption has started. And it's at this point that encryption has started, and not before.
12:41
And you will understand just in a couple of slides why I'm emphasizing this. Every subsequent PDUs 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
13:01
how it is possible to inject keys with all this 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,
13:24
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 these queues, in a not encrypted way.
13:41
It's explicitly allowed, and I can show you the part of the standard where this is written. 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 sending encrypted PDUs or encrypted data.
14:04
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
14:23
slave device, where he can send data through the connection, through the Bluetooth connection, and the link layer of the master will accept this PDU, these PDUs, will accept this data.
14:41
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.
15:06
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
15:25
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 allows 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
15:47
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 messages are really sent.
16:03
We only tell the controller part to send some data to some high-level data, but we don't decide where exactly this data is sent. We are trying to put some PDUs between the encryption request and encryption response.
16:25
We couldn't decide where the PDUs we try to send are exactly put. To implement this approach, we use an HCI adapter, a common HCI adapter with the only
16:41
particularity that it allows to change the PDUs in order to impersonate the Bluetooth keyboard and use the Mirage framework. The Mirage framework allows, among other things, to hook some parts of the communication and change the normal flow of this communication.
17:04
We use it to intercept the connection event, and after this event, we start to send key strokes and it doesn't send anything else. As I said, we don't decide where the messages are effectively sent.
17:30
We need some tries to succeed and put some of these key strokes between the encryption request and encryption response, and now we will show you some capture in the air.
17:41
We just sniffled to capture this message that is a Bluetooth low-energy sniffer. On the left side, you could see the direction of the communication, master to slave or slave to master.
18:01
As I said, the connect request is sent by the master and received by the slave. Just after that, we start sending key strokes, but you can see that there are some link layer messages that we have not controlled and are sent. Then the normal flow of the communication starts and encryption request is received
18:24
by the fake slave, and the slave is trying to send more key strokes. Then the controller part of the fake slave responds automatically with an encryption
18:41
response and asks for the launcher key. As we haven't got the launcher key, the key missing is sent back to the controller and it is translated to link layer authentication. Once master receives this message, it closes the connection immediately because the encryption
19:03
channel could not be established, and our fake slave continues trying to send some key strokes. The most important thing in these slides is to understand that we are trying to send a lot of key strokes between encryption request and encryption response, and as we haven't
19:25
control about when the level data is sent, we can decide that these key strokes hit between encryption request and encryption response. There are only one notification message that hit there, and it means that there are only
19:45
one key stroke that are effectively injected and processed by the master. We realize that if we want to exploit this vulnerability, we should go down and develop something that works in the controller level.
20:05
This is what we did, and this is 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, this fantastic framework which is called the CIFAR. It's completely, from top to bottom, open source implementation of the Bluetooth low
20:23
energy protocol stack. You can compile that and create a firmware that can run in one of these dongles, which is a Nordic RF52H40 that has very few cost, it's very small cost.
20:44
When we implement this at the link layer, what we can do is to control where these key strokes that we want to send can fall into the protocol state. We can allow the protocol at the link layer to reach this point, and then we can freeze
21:02
the protocol and send all the key strokes that we want to send, if there is no tomorrow, and then just wait for the master to terminate the connection. The master will terminate the connection because he is actually waiting for the encryption response command, PDU, sorry. This will never arrive because we are not going to send it.
21:22
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 key strokes that we have sent have been already accepted by the master. 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
21:45
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 freeze the link
22:03
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 key strokes that we want to send, as you can see here.
22:23
And we send all of them. And eventually, we send all of them, and then we just stop sending things. We just wait for the master to drop the connection. And all these keys have already been accepted.
22:40
Now we have an exploit that allows 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. We try to send a lot of keystrokes with no waiting time.
23:03
But this causes 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 increment of waiting time that starts waiting four seconds.
23:23
That is a lot of time, but it works. And then every time that a keystroke is sent, divide this waiting time by two, and the read reads 20 milliseconds. This implementation allows us to inject more than 13,000 keystrokes in one connection of 30 seconds.
23:45
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.
24:03
We implement these HCI vendor commands to program the dongle with some special characteristics of each device and what keystrokes we want to send in every connection without having to recompile so far every time that we want to change something.
24:25
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 a keystroke to be sent
24:43
when the connection is established. We also implement some specialized actuands. For example, this is the action to sleep. We can tell the dongle to sleep some milliseconds between two keystrokes are sent.
25:01
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 the testing purpose to, and it allow us to repeat the list of keystrokes in a loop
25:21
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.
25:42
We also need our modified Zephyr firmware that you can find it in our GitHub. I don't know, is it published now? Yeah? You can find it in our GitHub. With these two things, you can program the dongle, but it's quite hard because you need
26:01
to use the HCI tool and put the bytes manually. We developed 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
26:25
low energy keyboard that we want to impersonate. 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.
26:46
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 legitimate keyboard, you could see on
27:03
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 a notification.
27:22
To get the MAC address, we could listen in the air at the real keyboard. We separate two modes. The first mode was when the keyboard isn't paired yet.
27:42
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, we use a Microsoft keyboard. This message includes the video address or the MAC address.
28:03
During this mode, it also sends a scan response that includes the full device name and the advertising address, but it's not realistic that the attacker were always when the pairing
28:22
is performing, so there are another way to get the MAC address and it's when the keyboard is reconnecting to the Windows PC. 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.
28:46
Once we have all this information, we could write the configuration file that we need to run the tag and it includes the report handle, the report size and the operation type that we collect before analyzing a replica.
29:03
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
29:20
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, is 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.
29:47
This example of text script opens the run dialogue of Windows, write PowerShell, press enter and then sleep for 500 milliseconds and then open a card that is the common proof
30:06
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 PD address of the keyboard that we want
30:29
to impersonate and the configuration file. We add two more options that is the run forever that as I said before send in a loop the key
30:41
strokes that we want to inject and the noact that prints 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.
31:01
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
31:22
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.
31:42
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.
32:04
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,
32:24
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 10 minutes and as we can see right now the keyboard is going
32:40
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, 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 trying to, that we're impersonating the legitimate keyboard and all these key
33:03
strokes 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.
33:28
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.
33:45
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.
34:02
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 program some movements and some clicks of the mouse just to show this square on the paint program
34:26
of Windows. 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
34:44
you to see the real time of the attack. 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
35:02
case is the Windows machine 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 this is just
35:23
a proof of concept but just to count how many keystrokes we are able to inject. 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
35:43
so the impact is that way. 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.
36:05
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. If this talk is not enough because our English is not very good looking then we have tried
36:22
to write down all the things here in our post in our blog. We also have all the tools and our modified firmware in our GitHub page. We left here some reference for you, the reference for the tools that we have used for making the captures, the Cephire project and other things and also the references to the specifications
36:45
and some previous work that we have read, they are not directly related with our work because they are 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.
37:01
If you have any questions we will be around and we will have more hard work to do.