Is the keyboard an output device?
Research is an integral part of my workflow. I research software, source codes, OS, pieces of iron - everything that my hands reach (well, or the hands of superiors, how lucky it is). But not all studies are carried out by request, sometimes you just do something for the soul (which, in general, our company encourages). This study began with a conversation about encryption, and ended with a DLP bypass and data being moved outside the controlled perimeter.
I really do not like DLP-system. My dislike is based on the marketing strategy of products presenting their solutions in the form of a “silver bullet” that can prevent all data leaks in any company. Can not. In my opinion, DLP really helps in 2 cases - to prevent data leaks due to hand curves (such as sending billing data instead of ali@domain.mail to all@domain.mail) and help to investigate who carried the data (after the fact, ). I was initially confident that a specialist with sufficient knowledge of Windows, for example, would be able to overcome almost any filters. A motivated insider will be able to find such a specialist and learn a few tricks. But it’s pretty boring to check various tricks on specific complexes, so you had to think up how to get around them all at once.
The ideas of crypto-anarchism are close to me, and I love cryptography. Even outside the Internet we are surrounded by so many things that use it - from banal passes and transport tickets to plastic cards with which we pay. I would gladly sign my messages on social networks and instant messengers if it were conveniently done - a separate field for specifying the electronic signature, automatic verification, convenient export of the signature and public keys for external checks. I have no illusions - such changes will never be massive. We must start with yourself. Anyway, it was this curve of dreams about how to bring yourself more problems for the sake of dubious perceptions of security , led to a funny thought - what if thecatapult ... embed encryption in the keyboard?
')
It was thought that you can add a few additional buttons to the keyboard. One, for example, provokes the keyboard to “type” the public key, or, even immediately, a certificate. The other translates the keyboard into encryption mode — the printed text is not transferred to the computer, it is first encrypted, and the already encrypted “is printed on the screen”.
Even considering my great love of scattering rakes on the path that I will have to run in the near future, I understood the unviability of such a keyboard. This awareness came somewhere immediately after the need for a personal 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 controls the state of the LEDs on the keyboard and gives it instructions to light certain LEDs. You can use this channel of information transfer for your own purposes. That is what we will discuss next.
At this stage, I realized that I was no longer interested in doing a cryptographic keyboard. And to realize the attack on the DLP-system, on the contrary, it is very interesting. Goodbye, cryptographic keyboard, hello, information retrieval device.
Transferring information from the computer through blinking LEDs is not a new idea. I even find it difficult to specify the earliest source. For example, the literary method was immortalized in Neil Stevenson's "Cryptonomicon" in 1999. A technical post is on the link dated October 29, 2012. Nevertheless, I followed the path of inventing my own crafts, since the artistic description was not accurate enough, and I found the reference to 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 represent the specified file as a blinking of the LEDs on the keyboard. Difficult - to do something that is represented by the keyboard and catches "messages" from the program.
I decided not to complicate the program, 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 each. The implication was that the future receiver, having received the data that the Scroll Lock was pressed, would save the next 2 bits.
It was necessary to make a receiver. Then one of the Malinki clones came to my aid, namely, nano pi m1. I ordered it in advance - just to play, it coincided here, as the application was found.
As an OS, I used Armbian, which worked pretty well on a piece of 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 successfully introduced himself as a keyboard and correctly emulated button presses. But reading the status of the LEDs did not work. HID-packages arrived, but contained incorrect data. The USB sniffer on the side of a regular computer showed that the packets were flying out the right ones, but what happened to them in the piece of iron is not clear. I spent about a week trying to debug the work of drivers related to usb, but without success. Perhaps if I took the usual raspberry pi then everything would start right away. 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 haven’t conducted checks on the current version.
The main reason that I stopped breaking the piece of iron, the head and the sources of the OS was that I found a solution to my problems. It's funny that it was found on Habré - Pastilde . It's doubly funny that my idea interfered 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 ​​the encryption keyboard. Well, it does not matter ... The guys collected a fee and wrote the firmware. 90% of the work I needed was already done.
Attempts to reach Pastilde were not immediately crowned with success. The director of the Third Pin lost interest in me right after I said that I only needed one fee. And I cannot blame him for this - the piece production is extremely expensive, I was hoping for the presence of at least prototypes. One way or another, but I still got the piece of iron.
I have never dealt with writing firmware for devices, only seen from afar. But I didn’t need to write from scratch - the firmware code was on a githaba. A colleague taught me to assemble it and fill it with a piece of iron (# I’m a programmer, although it will be even more accurate: “How I stopped being a programmer and began to program twice as much”). Then it was easy - I found the code responsible for processing HID packets, and wrote an assembly of bit sequences for writing to internal memory.
And here is the long-awaited moment of checking the basic performance! I managed to “extort” not very long byte sequences with LEDs. During the functional test, several DLP and SZIs that were checked did not see anything interesting in my actions and quietly released data for the perimeter. At this stage, I decided to call this attack Radiance , from the English "radiance", "luminosity".
As soon as the euphoria of successful trials passed, it was time to take statistical measurements.
I was already upset here, because the speed and reliability of my decision 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 carried out this way. It's time to recall the researchers who claim that you can blink the LEDs and remove these blinking photos so that the speed will be more than 1000 bits per second. Even without analog conversions (even though I’m everywhere saying “blinking LED”, only digital data is actually processed) I didn’t see a way to theoretically raise the speed above 10 bytes per second. Moreover, the less I did the time delay between the blinking of the LEDs, the more encoding errors I received - some operating system limitations might have worked and some of the “blinks” would be lost, or maybe the packets would somehow form differently or something else. that option. This is not surprising, but still unpleasant. As a result, I decided to leave the delay at the level of those 5 bytes and calm down on this - an experiment lasting an hour showed that there were no errors at that speed.
But fixing the pause between signals did not mean that I would not fight for speed.
One of the slowing factors I saw was the fact that the transmission of even two bits required several instructions. Imagine that I need to transfer two single bits, and all the LEDs are extinguished at the initial moment. In my coding system, in order to transmit them, you need to light up all 3 keyboard LEDs. It took me three times to call a function that lights the LED, emulating the press of a button on the keyboard. If it were possible to immediately send the status of all the LEDs at a time, then there would be a significant time saving. Moreover, the HID packet transmits the state of not 3 LEDs, but as many as 5. Actually, I could see an increase in speed up to 10 bytes / second - the absence of intermediate LED exposures and the transmission of 5 bits in one package.
But I did not have time to check this optimization. Because he came up with an even stronger one! Looking ahead, I boast that the speed reached 600 bytes per second without encoding errors. It turned out that the state of all LEDs can really be set programmatically by sending HID packets. Why not send a HID packet of your format? 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 when the device is initialized. It specifies the description of the format of communication keyboard with a computer. In general, it indicates that packets of 6 bytes each will leave the keyboard on 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, sending packets not provided for by the descriptor, I simply added to the descriptor an indication that sometimes packets of 32 bytes would arrive on the keyboard. Well, I began to send them. That was enough to achieve the above 600 bytes per second. Potentially, DLP systems could verify that the HID descriptor has changed and detect an attack, but I did not touch the main usb descriptors - from the point of view of all systems, what was the keyboard, this remained - the serial number and other identifiers remained the same.
The new approach pleased not only speed, but also stability: there were no coding errors, you could safely use the keyboard 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 for a year and a half to write this article), at which I showed everyone the operation of the device.
In the same place representatives of some DLP looked at her and it seems even promised to add protection. It will be necessary to check it on occasion.
In conclusion, I want to add some 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, I have already done). It would be possible to attach something wireless to a piece of iron to transmit a signal - WiFi, Bluetooth or even a 3G modem. This would greatly simplify the removal of information.
Another improvement lies in a very special plane - but what if I say that a separate device is not needed at all to conduct such an attack? Neither raspberry, nor Pastilde. We each have a mobile phone. Some even have an Android phone. Which, by the way, is a close relative of the linux OS. I’ll say more, remembering my experiments with nano pi m1, on Android (on the root, of course) there is an opportunity to install a kernel module, which will be represented by a keyboard. A similar module is in the Kali version for mobile phones, so everything is real. Now the attack is almost free and I can’t even imagine how to improve it.
I want to distract from the main topic of the article and get a little hit in conspiracy theories and paranoia. Let's ask ourselves a very simple question - what do we first type on the keyboard after turning on the computer? Someone rarely comes into the UEFI BIOS settings, someone needs to select an operating system from the list, but still most users enter their credentials to log in to the OS. But what if keyboard manufacturers add code to their devices, which will collect statistics about the user, into the firmware? Quite easily, such a keyboard will receive data on how to boot the OS and log in as the user. Potentially, keyboard presses can make significant assumptions about the OS. Relatively speaking, pressing the type ctrl + alt + f1 and frequent pressing caps lock ( oh, irony ) are characteristic of Linux, and win + m, win + d - already in Windows.
Analyzing the time when the computer is turned on, but the keyboard is not used, the device can make assumptions about when the computer is left unattended. Along with this knowledge, everything has already been prepared for the attack - a computer without supervision, if it is locked, then unblock it - the credentials are known, the OS is known - you can choose a suitable payload to be fixed in the system. And even if the attack is noticed, the keyboard is unlikely to be blamed, it’s more likely that everything will be written off as a “virus”. Almost perfect attack.
Written above looks like a completely theoretical speculation. But how long is this practice?
→ UAC Bypass or the story of the three escalations
Explore Windows security mechanisms, bypassing a UAC request.
→ Life without SDL. Winter 2017
While developers everywhere do not use SDL, I will always have a job.
I really do not like DLP-system. My dislike is based on the marketing strategy of products presenting their solutions in the form of a “silver bullet” that can prevent all data leaks in any company. Can not. In my opinion, DLP really helps in 2 cases - to prevent data leaks due to hand curves (such as sending billing data instead of ali@domain.mail to all@domain.mail) and help to investigate who carried the data (after the fact, ). I was initially confident that a specialist with sufficient knowledge of Windows, for example, would be able to overcome almost any filters. A motivated insider will be able to find such a specialist and learn a few tricks. But it’s pretty boring to check various tricks on specific complexes, so you had to think up how to get around them all at once.
The ideas of crypto-anarchism are close to me, and I love cryptography. Even outside the Internet we are surrounded by so many things that use it - from banal passes and transport tickets to plastic cards with which we pay. I would gladly sign my messages on social networks and instant messengers if it were conveniently done - a separate field for specifying the electronic signature, automatic verification, convenient export of the signature and public keys for external checks. I have no illusions - such changes will never be massive. We must start with yourself. Anyway, it was this curve of dreams about how to bring yourself more problems for the sake of dubious perceptions of security , led to a funny thought - what if the
')
It was thought that you can add a few additional buttons to the keyboard. One, for example, provokes the keyboard to “type” the public key, or, even immediately, a certificate. The other translates the keyboard into encryption mode — the printed text is not transferred to the computer, it is first encrypted, and the already encrypted “is printed on the screen”.
Even considering my great love of scattering rakes on the path that I will have to run in the near future, I understood the unviability of such a keyboard. This awareness came somewhere immediately after the need for a personal 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 flash drives;
- a special mode in which the keyboard is recognized not only as a keyboard, but also as, for example, mass storage;
- instructions for the user to enter a special key combination (yeah, let the user type the certificate in base64, I don’t 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 controls the state of the LEDs on the keyboard and gives it instructions to light certain LEDs. You can use this channel of information transfer for your own purposes. That is what we will discuss next.
At this stage, I realized that I was no longer interested in doing a cryptographic keyboard. And to realize the attack on the DLP-system, on the contrary, it is very interesting. Goodbye, cryptographic keyboard, hello, information retrieval device.
We repair what is not broken
Transferring information from the computer through blinking LEDs is not a new idea. I even find it difficult to specify the earliest source. For example, the literary method was immortalized in Neil Stevenson's "Cryptonomicon" in 1999. A technical post is on the link dated October 29, 2012. Nevertheless, I followed the path of inventing my own crafts, since the artistic description was not accurate enough, and I found the reference to 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 represent the specified file as a blinking of the LEDs on the keyboard. Difficult - to do something that is represented by the keyboard and catches "messages" from the program.
I decided not to complicate the program, 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 each. The implication was that the future receiver, having received the data that the Scroll Lock was pressed, would save the next 2 bits.
It was necessary to make a receiver. Then one of the Malinki clones came to my aid, namely, nano pi m1. I ordered it in advance - just to play, it coincided here, as the application was found.
As an OS, I used Armbian, which worked pretty well on a piece of 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 successfully introduced himself as a keyboard and correctly emulated button presses. But reading the status of the LEDs did not work. HID-packages arrived, but contained incorrect data. The USB sniffer on the side of a regular computer showed that the packets were flying out the right ones, but what happened to them in the piece of iron is not clear. I spent about a week trying to debug the work of drivers related to usb, but without success. Perhaps if I took the usual raspberry pi then everything would start right away. 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 haven’t conducted checks on the current version.
The main reason that I stopped breaking the piece of iron, the head and the sources of the OS was that I found a solution to my problems. It's funny that it was found on Habré - Pastilde . It's doubly funny that my idea interfered 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 ​​the encryption keyboard. Well, it does not matter ... The guys collected a fee and wrote the firmware. 90% of the work I needed was already done.
Attempts to reach Pastilde were not immediately crowned with success. The director of the Third Pin lost interest in me right after I said that I only needed one fee. And I cannot blame him for this - the piece production is extremely expensive, I was hoping for the presence of at least prototypes. One way or another, but I still got the piece of iron.
I have never dealt with writing firmware for devices, only seen from afar. But I didn’t need to write from scratch - the firmware code was on a githaba. A colleague taught me to assemble it and fill it with a piece of iron (# I’m a programmer, although it will be even more accurate: “How I stopped being a programmer and began to program twice as much”). Then it was easy - I found the code responsible for processing HID packets, and wrote an assembly of bit sequences for writing to internal memory.
And here is the long-awaited moment of checking the basic performance! I managed to “extort” not very long byte sequences with LEDs. During the functional test, several DLP and SZIs that were checked did not see anything interesting in my actions and quietly released data for the perimeter. At this stage, I decided to call this attack Radiance , from the English "radiance", "luminosity".
Rewarding uncomplicated
As soon as the euphoria of successful trials passed, it was time to take statistical measurements.
I was already upset here, because the speed and reliability of my decision 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 carried out this way. It's time to recall the researchers who claim that you can blink the LEDs and remove these blinking photos so that the speed will be more than 1000 bits per second. Even without analog conversions (even though I’m everywhere saying “blinking LED”, only digital data is actually processed) I didn’t see a way to theoretically raise the speed above 10 bytes per second. Moreover, the less I did the time delay between the blinking of the LEDs, the more encoding errors I received - some operating system limitations might have worked and some of the “blinks” would be lost, or maybe the packets would somehow form differently or something else. that option. This is not surprising, but still unpleasant. As a result, I decided to leave the delay at the level of those 5 bytes and calm down on this - an experiment lasting an hour showed that there were no errors at that speed.
But fixing the pause between signals did not mean that I would not fight for speed.
One of the slowing factors I saw was the fact that the transmission of even two bits required several instructions. Imagine that I need to transfer two single bits, and all the LEDs are extinguished at the initial moment. In my coding system, in order to transmit them, you need to light up all 3 keyboard LEDs. It took me three times to call a function that lights the LED, emulating the press of a button on the keyboard. If it were possible to immediately send the status of all the LEDs at a time, then there would be a significant time saving. Moreover, the HID packet transmits the state of not 3 LEDs, but as many as 5. Actually, I could see an increase in speed up to 10 bytes / second - the absence of intermediate LED exposures and the transmission of 5 bits in one package.
But I did not have time to check this optimization. Because he came up with an even stronger one! Looking ahead, I boast that the speed reached 600 bytes per second without encoding errors. It turned out that the state of all LEDs can really be set programmatically by sending HID packets. Why not send a HID packet of your format? 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 when the device is initialized. It specifies the description of the format of communication keyboard with a computer. In general, it indicates that packets of 6 bytes each will leave the keyboard on 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, sending packets not provided for by the descriptor, I simply added to the descriptor an indication that sometimes packets of 32 bytes would arrive on the keyboard. Well, I began to send them. That was enough to achieve the above 600 bytes per second. Potentially, DLP systems could verify that the HID descriptor has changed and detect an attack, but I did not touch the main usb descriptors - from the point of view of all systems, what was the keyboard, this remained - the serial number and other identifiers remained the same.
The new approach pleased not only speed, but also stability: there were no coding errors, you could safely use the keyboard 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 for a year and a half to write this article), at which I showed everyone the operation of the device.
In the same place representatives of some DLP looked at her and it seems even promised to add protection. It will be necessary to check it on occasion.
In conclusion, I want to add some 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, I have already done). It would be possible to attach something wireless to a piece of iron to transmit a signal - WiFi, Bluetooth or even a 3G modem. This would greatly simplify the removal of information.
Another improvement lies in a very special plane - but what if I say that a separate device is not needed at all to conduct such an attack? Neither raspberry, nor Pastilde. We each have a mobile phone. Some even have an Android phone. Which, by the way, is a close relative of the linux OS. I’ll say more, remembering my experiments with nano pi m1, on Android (on the root, of course) there is an opportunity to install a kernel module, which will be represented by a keyboard. A similar module is in the Kali version for mobile phones, so everything is real. Now the attack is almost free and I can’t even imagine how to improve it.
Scary night
I want to distract from the main topic of the article and get a little hit in conspiracy theories and paranoia. Let's ask ourselves a very simple question - what do we first type on the keyboard after turning on the computer? Someone rarely comes into the UEFI BIOS settings, someone needs to select an operating system from the list, but still most users enter their credentials to log in to the OS. But what if keyboard manufacturers add code to their devices, which will collect statistics about the user, into the firmware? Quite easily, such a keyboard will receive data on how to boot the OS and log in as the user. Potentially, keyboard presses can make significant assumptions about the OS. Relatively speaking, pressing the type ctrl + alt + f1 and frequent pressing caps lock ( oh, irony ) are characteristic of Linux, and win + m, win + d - already in Windows.
Analyzing the time when the computer is turned on, but the keyboard is not used, the device can make assumptions about when the computer is left unattended. Along with this knowledge, everything has already been prepared for the attack - a computer without supervision, if it is locked, then unblock it - the credentials are known, the OS is known - you can choose a suitable payload to be fixed in the system. And even if the attack is noticed, the keyboard is unlikely to be blamed, it’s more likely that everything will be written off as a “virus”. Almost perfect attack.
Written above looks like a completely theoretical speculation. But how long is this practice?
Other blog articles
→ UAC Bypass or the story of the three escalations
Explore Windows security mechanisms, bypassing a UAC request.
→ Life without SDL. Winter 2017
While developers everywhere do not use SDL, I will always have a job.
Source: https://habr.com/ru/post/352868/
All Articles