Is the keyboard an output device?
Research is an integral part of my workflow. I’m researching software, source codes, operating systems, glands - everything your hands reach (well, or the hands of superiors, here it’s lucky). But not all studies are carried out by order, sometimes you just do something for the soul (which, our company generally encourages). This study began with a conversation about encryption, and ended with bypassing DLP and moving data beyond a controlled perimeter.
I really dislike DLP systems. My dislike is based on the marketing strategy of the products, representing their solutions in the form of a sort of “silver bullet”, which can prevent all data leaks in any company. Can not. In my opinion, DLP really helps in 2 cases - to prevent data leakage due to crooked hands (such as sending payment data instead of ali@domain.mail to all@domain.mail) and to help investigate who carried the data (after the fact, naturally ) I was initially sure that a specialist with sufficient knowledge of Windows, for example, would be able to overcome almost any filter. A motivated insider will be able to find such a specialist and learn a few tricks. But testing various tricks on specific complexes is quite boring, so you had to figure out how to get around them all at once.
The ideas of cryptanarchism are close to me and I love cryptography. Even outside the Internet we are surrounded by so many things that it uses - from banal passes and transport tickets, to plastic cards with which we pay. I would be happy to sign my messages on social networks and instant messengers, if this were conveniently done - a separate field for indicating electronic signatures, automatic verification, convenient export of signatures and public keys for external checks. I have no illusions - such changes will never be massive. You have to start with yourself. One way or another, it was this curved track of dreams about how to bring yourself more problems for the sake of dubious feelings of security that led to a funny thought - what if thecatapult ... embed encryption in the keyboard?
It was thought that you can add several additional buttons to the keyboard. One, for example, provokes the keyboard to "print" a public key, or, even immediately, a certificate. Another puts the keyboard in encryption mode - the printed text is not transmitted to the computer, it is first encrypted, and the encrypted one is "printed on the screen."
Even taking into account my great love for throwing a rake on the path to be run in the near future, I understood the viability of such a keyboard. This awareness came somewhere right after the need for its own screen for such a keyboard - without it, you can’t look at the text before encryption and edit it too, only blindly.
In addition, the question came to mind: how can a computer transmit information to such a “keyboard”? The solution to this issue is necessary for entering keys and certificates.
There are many options:
One of the fun options is to use blinking LEDs (indicators num lock, caps lock, scroll lock). It is the computer that monitors the status of the LEDs on the keyboard and instructs it to light certain LEDs. You can use this channel for transmitting information for your own purposes. This is what we will talk about later.
At this stage, I realized that I was no longer interested in making a cryptographic keyboard. And to implement an attack on DLP systems, on the contrary, is very interesting. Goodbye, cryptographic keyboard, hello, information extraction device.
Transferring information from a computer through the blinking of LEDs is not a new idea. I am at a loss to point out the earliest source. For example, literally such a method was immortalized in Nept Stevenson's Cryptonomicon in 1999. A technical post is on the link from October 29, 2012. Nevertheless, I took the path of inventing my own craft, because the artistic description was not accurate enough, and I found a link about an idea similar to mine much later than creating ready-made prototypes.
The task is clear and consists of two parts. The simple part is to write a program that will present the given file in the form of blinking keyboard LEDs. The difficult part is to do something that appears as a keyboard and catches “messages” from the program.
I decided not to complicate the program much, and to begin with, make the most straightforward coding method. Num lock and Caps Lock encoded two bits (LED on - 1, off - 0), Scroll Lock served as a save marker, each byte was divided into 4 groups of 2 bits. It was understood that the future receiver, having received data that Scroll Lock was pressed, would save the next 2 bits.
It was up to the receiver. Then one of the Malinka clones came to my aid, namely nano pi m1. I ordered it in advance - just play around, it just so coincided that the application was found.
As the OS, I used Armbian, which worked pretty well on the hardware. The project itself provides fairly simple and convenient scripts for assembling images. I spent a couple of days analyzing how usb gadgets work and testing the HID keyboard gadget that comes with the OS. It was smooth only in mana. m1 introduced itself as a keyboard and correctly emulated button presses. But reading the status of the LEDs did not work. HID packets arrived, but contained incorrect data. The USB sniffer on the side of a regular computer showed that the packets were flying out correctly, but what was happening with them in the piece of iron was already incomprehensible. I spent about a week trying to debug the usb-related drivers, but to no avail. Perhaps, if I took the usual raspberry pi, then everything would start up immediately. Or maybe in Armbian everything is already backed up with crutches and is working now. I’ll clarify that about a year and a half has passed since the experiments and I did not conduct checks on the current version.
The main reason that I stopped breaking the piece of iron, head and OS sources was that I found a solution to my problems. It's funny that it was found on Habré - Pastilda . It is doubly funny that my idea intersected so much with the idea of a hardware password manager. True, I believe that such a manager is doomed to nonexistence to the same extent as the original idea of an encryption keyboard. Well, it doesn’t matter ... The guys collected the board and wrote the firmware. 90% of the work that I needed was already done.
Attempts to get Pastilda did not immediately succeed. The director of the Third Pin lost interest in me right after I said that I needed only one board. And I cannot blame him for this - piece production is extremely expensive, I was hoping for at least prototypes. One way or another, but I still got the piece of iron.
I have never dealt with writing firmware for devices, I only saw it from afar. But I did not need to write from scratch - the firmware code was on the github. A colleague taught me how to assemble it and put it in a piece of iron (# I’m a programmer, though it’ll be even more precise: “How I stopped being a programmer and began to program twice as much”). The rest was simple - I found the code responsible for processing HID packets and wrote a bit sequence assembly for writing to internal memory.
And here is the long-awaited moment of verification of basic operability! I managed to correctly "blink out" not very long byte sequences with LEDs. During a functional check, several DLP and SZI checked did not see anything interesting in my actions and quietly released perimeter data. At this stage, I decided to call this attack Radiance , from English “radiance”, “luminosity”.
Once the euphoria from successful trials has passed, it is time to conduct statistical measurements.
Here I was already upset, because the speed and reliability of my solution was rather mediocre. I intended 5 bytes in 4 seconds, i.e. 1.25 bps
It is very slow. Better than nothing, but only small files, such as documents, can be taken out this way. It's time to remember the researchers who claimthat you can blink LEDs and shoot these blinks with photo equipment so that the speed will be more than 1000 bits per second. Even without analog conversions (although I always say “blink the LED”, only digital data is actually processed), I have not seen a way to theoretically increase the speed above 10 bytes per second. Moreover, the less I delayed the time between flashing LEDs, the more coding errors I received - maybe some limitations of the operating system worked and some of the “blinks” were lost, or maybe packets were somehow formed differently or some other then an option. This is not surprising, but still unpleasant. As a result, I decided to leave the delay at the level of those same 5 bytes and calm down on this - an experiment lasting an hour showed that there were no errors at this speed.
But fixing the pause between the signals did not mean that I would not fight for speed.
One of the slowing factors I saw was the fact that transmitting even two bits required several commands. Imagine that I need to transmit two single bits, and all the LEDs are initially off. In my coding system, to transmit them, I need to light all 3 keyboard LEDs. It took me three times to call a function that lights up the LED, emulating the pressing of a button on the keyboard. If it was possible to immediately send the status of all the LEDs at a time, then a significant time saving would result. Moreover, the status of the HID packet is not 3 LEDs, but as much as 5. Actually, I saw a speed increase of up to 10 bytes / second - the absence of intermediate LEDs and the transfer of 5 bits in one package.
But I did not have time to check this optimization. Because I came up with an even stronger one! Looking ahead, I boast that the speed reached 600 bytes per second without coding errors. It turned out that the status of all the LEDs can indeed be set programmatically by sending HID packets. Why not send your own format HID packet? In fact, everything is not so simple.
There is such a thing - “report descriptor”. This is a special structure that is transmitted by the keyboard during device initialization. It indicates the description of the communication format of the keyboard with the computer. In the general case, it indicates that packets of 6 bytes will go from the keyboard to the computer, and it will receive packets of one byte each, with 3 bits being fixed. In order not to upset the balance of the universe by sending packets that are not provided for by the descriptor, I simply added an indication to the descriptor that sometimes 32 byte packets would arrive at the keyboard. Well, he began to send them. This was enough to achieve the above 600 bytes per second. Potentially, DLP systems could check that the HID descriptor has changed and so detect the attack, but I did not touch the main usb descriptors - from the point of view of all systems, what was the keyboard,
The new approach pleased us not only with speed, but also with stability: there were no coding errors, it was possible to use the keyboard calmly even during data transfer (in the previous method it was also possible, but this was accompanied by special effects).
Then the time came for Zeronights 2016 (yes, I was lazy to write this article for a year and a half), on which I demonstrated to everyone who wanted to work the device.
Representatives of some DLPs looked at her there and seemed to even promise to add protection. It will be necessary, on occasion, to check.
In conclusion, I want to add a few more words about the development of this device, which I will not do (of course I will not, a year and a half has passed - I would like to, have already done it). Something wireless could be attached to a piece of iron for signal transmission - Bethlehem, Bluetooth or even a 3G modem. This would greatly simplify the transfer of information.
Another improvement lies in a completely special plane - but what if I say that to conduct such an attack there is no need for a separate device? Neither raspberry nor Pastilda. We each have a mobile phone. For some, this is even an Android phone. Which, by the way, is a short-term relative of the linux OS. I will say more, recalling my experiments with nano pi m1, on Android (on the root, of course), it is possible to install the kernel module, which will be presented by the keyboard. A similar module is in the Kali version for mobile phones, so everything is real. Now the attack is almost free and I still can’t imagine how to improve it.
I would like to escape from the main topic of the article and get a little hit in conspiracy theory and paranoia. Let's ask ourselves a very simple question - what do we first type on the keyboard after turning on the computer? Someone occasionally goes into the UEFI settings BIOS, someone needs to choose an operating system from the list, but still, most users enter credentials to enter the OS. But what if keyboard manufacturers add a code to their firmware and user statistics to their firmware? Quite easily, such a keyboard will receive data on how to load the OS and log in as a user. Potentially, you can make significant assumptions about the OS by keyboard keystrokes. Relatively speaking, keystrokes like ctrl + alt + f1 and frequent caps locks ( oh, irony) are peculiar to Linux, and win + m, win + d are already Windows.
By analyzing the time when the computer is turned on but the keyboard is not in use, the device can make assumptions about when the computer is left unattended. Together with this knowledge, everything has already been prepared for the attack - the computer is unattended, if it is locked, then unlock - the credentials are known, the OS is known - you can choose the appropriate payload for fixing in the system. And even if the attack is noticed, the keyboard is unlikely to be blamed, it is more likely that everything will be attributed to a “virus”. Almost perfect attack.
The above looks like a completely theoretical fabrication. But how long is it left before such a practice?
→ UAC Bypass, or the story of three escalations.
Exploring Windows security mechanisms bypassing the UAC request.
→ Life without SDL. Winter 2017
Until developers everywhere use SDL, I will always have work.
I really dislike DLP systems. My dislike is based on the marketing strategy of the products, representing their solutions in the form of a sort of “silver bullet”, which can prevent all data leaks in any company. Can not. In my opinion, DLP really helps in 2 cases - to prevent data leakage due to crooked hands (such as sending payment data instead of ali@domain.mail to all@domain.mail) and to help investigate who carried the data (after the fact, naturally ) I was initially sure that a specialist with sufficient knowledge of Windows, for example, would be able to overcome almost any filter. A motivated insider will be able to find such a specialist and learn a few tricks. But testing various tricks on specific complexes is quite boring, so you had to figure out how to get around them all at once.
The ideas of cryptanarchism are close to me and I love cryptography. Even outside the Internet we are surrounded by so many things that it uses - from banal passes and transport tickets, to plastic cards with which we pay. I would be happy to sign my messages on social networks and instant messengers, if this were conveniently done - a separate field for indicating electronic signatures, automatic verification, convenient export of signatures and public keys for external checks. I have no illusions - such changes will never be massive. You have to start with yourself. One way or another, it was this curved track of dreams about how to bring yourself more problems for the sake of dubious feelings of security that led to a funny thought - what if the
It was thought that you can add several additional buttons to the keyboard. One, for example, provokes the keyboard to "print" a public key, or, even immediately, a certificate. Another puts the keyboard in encryption mode - the printed text is not transmitted to the computer, it is first encrypted, and the encrypted one is "printed on the screen."
Even taking into account my great love for throwing a rake on the path to be run in the near future, I understood the viability of such a keyboard. This awareness came somewhere right after the need for its own screen for such a keyboard - without it, you can’t look at the text before encryption and edit it too, only blindly.
In addition, the question came to mind: how can a computer transmit information to such a “keyboard”? The solution to this issue is necessary for entering keys and certificates.
There are many options:
- external usb on the keyboard for a flash drive;
- special mode in which the keyboard is recognized not only as a keyboard, but also as, for example, mass storage;
- instructions to the user to enter a special key combination (yeah, let the user print the certificate in base64, I do not mind) and many other ways.
One of the fun options is to use blinking LEDs (indicators num lock, caps lock, scroll lock). It is the computer that monitors the status of the LEDs on the keyboard and instructs it to light certain LEDs. You can use this channel for transmitting information for your own purposes. This is what we will talk about later.
At this stage, I realized that I was no longer interested in making a cryptographic keyboard. And to implement an attack on DLP systems, on the contrary, is very interesting. Goodbye, cryptographic keyboard, hello, information extraction device.
Repair what is not broken
Transferring information from a computer through the blinking of LEDs is not a new idea. I am at a loss to point out the earliest source. For example, literally such a method was immortalized in Nept Stevenson's Cryptonomicon in 1999. A technical post is on the link from October 29, 2012. Nevertheless, I took the path of inventing my own craft, because the artistic description was not accurate enough, and I found a link about an idea similar to mine much later than creating ready-made prototypes.
The task is clear and consists of two parts. The simple part is to write a program that will present the given file in the form of blinking keyboard LEDs. The difficult part is to do something that appears as a keyboard and catches “messages” from the program.
I decided not to complicate the program much, and to begin with, make the most straightforward coding method. Num lock and Caps Lock encoded two bits (LED on - 1, off - 0), Scroll Lock served as a save marker, each byte was divided into 4 groups of 2 bits. It was understood that the future receiver, having received data that Scroll Lock was pressed, would save the next 2 bits.
It was up to the receiver. Then one of the Malinka clones came to my aid, namely nano pi m1. I ordered it in advance - just play around, it just so coincided that the application was found.
As the OS, I used Armbian, which worked pretty well on the hardware. The project itself provides fairly simple and convenient scripts for assembling images. I spent a couple of days analyzing how usb gadgets work and testing the HID keyboard gadget that comes with the OS. It was smooth only in mana. m1 introduced itself as a keyboard and correctly emulated button presses. But reading the status of the LEDs did not work. HID packets arrived, but contained incorrect data. The USB sniffer on the side of a regular computer showed that the packets were flying out correctly, but what was happening with them in the piece of iron was already incomprehensible. I spent about a week trying to debug the usb-related drivers, but to no avail. Perhaps, if I took the usual raspberry pi, then everything would start up immediately. Or maybe in Armbian everything is already backed up with crutches and is working now. I’ll clarify that about a year and a half has passed since the experiments and I did not conduct checks on the current version.
The main reason that I stopped breaking the piece of iron, head and OS sources was that I found a solution to my problems. It's funny that it was found on Habré - Pastilda . It is doubly funny that my idea intersected so much with the idea of a hardware password manager. True, I believe that such a manager is doomed to nonexistence to the same extent as the original idea of an encryption keyboard. Well, it doesn’t matter ... The guys collected the board and wrote the firmware. 90% of the work that I needed was already done.
Attempts to get Pastilda did not immediately succeed. The director of the Third Pin lost interest in me right after I said that I needed only one board. And I cannot blame him for this - piece production is extremely expensive, I was hoping for at least prototypes. One way or another, but I still got the piece of iron.
I have never dealt with writing firmware for devices, I only saw it from afar. But I did not need to write from scratch - the firmware code was on the github. A colleague taught me how to assemble it and put it in a piece of iron (# I’m a programmer, though it’ll be even more precise: “How I stopped being a programmer and began to program twice as much”). The rest was simple - I found the code responsible for processing HID packets and wrote a bit sequence assembly for writing to internal memory.
And here is the long-awaited moment of verification of basic operability! I managed to correctly "blink out" not very long byte sequences with LEDs. During a functional check, several DLP and SZI checked did not see anything interesting in my actions and quietly released perimeter data. At this stage, I decided to call this attack Radiance , from English “radiance”, “luminosity”.
Awarding of the uninvolved
Once the euphoria from successful trials has passed, it is time to conduct statistical measurements.
Here I was already upset, because the speed and reliability of my solution was rather mediocre. I intended 5 bytes in 4 seconds, i.e. 1.25 bps
It is very slow. Better than nothing, but only small files, such as documents, can be taken out this way. It's time to remember the researchers who claimthat you can blink LEDs and shoot these blinks with photo equipment so that the speed will be more than 1000 bits per second. Even without analog conversions (although I always say “blink the LED”, only digital data is actually processed), I have not seen a way to theoretically increase the speed above 10 bytes per second. Moreover, the less I delayed the time between flashing LEDs, the more coding errors I received - maybe some limitations of the operating system worked and some of the “blinks” were lost, or maybe packets were somehow formed differently or some other then an option. This is not surprising, but still unpleasant. As a result, I decided to leave the delay at the level of those same 5 bytes and calm down on this - an experiment lasting an hour showed that there were no errors at this speed.
But fixing the pause between the signals did not mean that I would not fight for speed.
One of the slowing factors I saw was the fact that transmitting even two bits required several commands. Imagine that I need to transmit two single bits, and all the LEDs are initially off. In my coding system, to transmit them, I need to light all 3 keyboard LEDs. It took me three times to call a function that lights up the LED, emulating the pressing of a button on the keyboard. If it was possible to immediately send the status of all the LEDs at a time, then a significant time saving would result. Moreover, the status of the HID packet is not 3 LEDs, but as much as 5. Actually, I saw a speed increase of up to 10 bytes / second - the absence of intermediate LEDs and the transfer of 5 bits in one package.
But I did not have time to check this optimization. Because I came up with an even stronger one! Looking ahead, I boast that the speed reached 600 bytes per second without coding errors. It turned out that the status of all the LEDs can indeed be set programmatically by sending HID packets. Why not send your own format HID packet? In fact, everything is not so simple.
There is such a thing - “report descriptor”. This is a special structure that is transmitted by the keyboard during device initialization. It indicates the description of the communication format of the keyboard with the computer. In the general case, it indicates that packets of 6 bytes will go from the keyboard to the computer, and it will receive packets of one byte each, with 3 bits being fixed. In order not to upset the balance of the universe by sending packets that are not provided for by the descriptor, I simply added an indication to the descriptor that sometimes 32 byte packets would arrive at the keyboard. Well, he began to send them. This was enough to achieve the above 600 bytes per second. Potentially, DLP systems could check that the HID descriptor has changed and so detect the attack, but I did not touch the main usb descriptors - from the point of view of all systems, what was the keyboard,
The new approach pleased us not only with speed, but also with stability: there were no coding errors, it was possible to use the keyboard calmly even during data transfer (in the previous method it was also possible, but this was accompanied by special effects).
Then the time came for Zeronights 2016 (yes, I was lazy to write this article for a year and a half), on which I demonstrated to everyone who wanted to work the device.
Representatives of some DLPs looked at her there and seemed to even promise to add protection. It will be necessary, on occasion, to check.
In conclusion, I want to add a few more words about the development of this device, which I will not do (of course I will not, a year and a half has passed - I would like to, have already done it). Something wireless could be attached to a piece of iron for signal transmission - Bethlehem, Bluetooth or even a 3G modem. This would greatly simplify the transfer of information.
Another improvement lies in a completely special plane - but what if I say that to conduct such an attack there is no need for a separate device? Neither raspberry nor Pastilda. We each have a mobile phone. For some, this is even an Android phone. Which, by the way, is a short-term relative of the linux OS. I will say more, recalling my experiments with nano pi m1, on Android (on the root, of course), it is possible to install the kernel module, which will be presented by the keyboard. A similar module is in the Kali version for mobile phones, so everything is real. Now the attack is almost free and I still can’t imagine how to improve it.
Night horror
I would like to escape from the main topic of the article and get a little hit in conspiracy theory and paranoia. Let's ask ourselves a very simple question - what do we first type on the keyboard after turning on the computer? Someone occasionally goes into the UEFI settings BIOS, someone needs to choose an operating system from the list, but still, most users enter credentials to enter the OS. But what if keyboard manufacturers add a code to their firmware and user statistics to their firmware? Quite easily, such a keyboard will receive data on how to load the OS and log in as a user. Potentially, you can make significant assumptions about the OS by keyboard keystrokes. Relatively speaking, keystrokes like ctrl + alt + f1 and frequent caps locks ( oh, irony) are peculiar to Linux, and win + m, win + d are already Windows.
By analyzing the time when the computer is turned on but the keyboard is not in use, the device can make assumptions about when the computer is left unattended. Together with this knowledge, everything has already been prepared for the attack - the computer is unattended, if it is locked, then unlock - the credentials are known, the OS is known - you can choose the appropriate payload for fixing in the system. And even if the attack is noticed, the keyboard is unlikely to be blamed, it is more likely that everything will be attributed to a “virus”. Almost perfect attack.
The above looks like a completely theoretical fabrication. But how long is it left before such a practice?
Other blog articles
→ UAC Bypass, or the story of three escalations.
Exploring Windows security mechanisms bypassing the UAC request.
→ Life without SDL. Winter 2017
Until developers everywhere use SDL, I will always have work.