The keylogger is a type of privacy breaching malicious software that intercepts the user activity and retrieves data entered by the user. This data could be used by third parties for various illegitimate purposes. Of more danger are the user-space keyloggers which do not require special permission to be deployed on a system. Recently, I read the paper, “NoisyKey: Tolerating Keyloggers via Keystrokes Hiding” that was written by Prof. Bruno Crispo and Mr. Stefano Ortolani. The paper was presented at USENIX security conference – HotSec’12 . You can find it here.
This blog post is a brief summary of what I understood of the paper.
Aim of the paper :
Currently there are a number of techniques that can be deployed to detect the presence of malicious software like the key loggers and to prevent their execution on a system. But this paper, as the name suggests, discusses how the presence of a keylogger can be tolerated.
Idea proposed :
The keystrokes that are entered by the user, travel through an event channel that transfers the keystrokes to intended application. Normally, it is this event channel that the keylogger intercepts to gain the input that has been entered by the user. In simple words, this paper proposes the idea of injecting dummy keystrokes or noise into this channel and confusing the keylogger to believe that the dummy keystrokes are the original user input. Now the original user input will be transferred only to the actual targeted application. To list down, there are two parts to the solution implementation.
- Introducing appropriate dummy keystrokes into the channel in synchronization with the user input.
- Removing the dummy keystrokes from the event channel before they reach the actual application.
Components of the solution :
The solution has itself been implemented in a library named silencer.dll. The following are the four components of the solution implemented :
- Noise factory : As the name denote, this is component that creates the dummy keystrokes or the noise.
- Injector thread : This component takes the noise that has been generated by the noise generator and introduces it into the event channel.
- Normalizer : The normalizer plays the role of shaping the noise that is injected into the channel. It is the intermediate component between the noise factory and the injector thread. As the paper mentions, this is important so that the keylogger does not come to know that it is receiving dummy data. For example, take the case where a user is needed to enter an only digits containing key or pin. The keylogger would be expecting digits. In such a case, it is the role of the normalizer to introduce only “context-aware” noise, as the paper puts it across. It produces context-aware noise by analyzing the past keystrokes.
- Silencer : This is the library in which the solution has been implemented. It is the duty of the silencer to work in synchronization with the injector thread.
The workflow has been explained with Windows operating system in mind. The noise factory has a set of dummy keystrokes ready with it, which are transferred to the Normalizer. The normalizer makes sure that the noise is correct with respect to the current context of the event that is getting intercepted. Now when the user enters data, keystrokes travel through the event channel. As soon as the user inputs a keystroke, the process – csrss.exe gets alerted. It is the duty of this process to transfer the correct user input to the destination application. Another application that gets alerted is the silencer thread. The noise is then passed to the injector thread that introduces the noise into the channel. The injector thread notifies the silencer thread about the injection of noise. The silencer removes the dummy keystrokes before they reach the intended application.
This way, it is made sure, only the targeted application receives the user input and not any other application, be a keylogger or any other piece of malicious software.
Other sources :
You can listen to the presentation of the paper here.