Whatever your network and application security, keyloggers can deal a mortal blow to corporate security. Popular with rootkits and trojans, loggers capture keystrokes, revealing passwords, personal information and entire documents before anything can be encrypted or locked down in any other way.
Keyloggers come in two kinds: hardware devices that attach to keyboard cables and are nearly undetectable, and malicious software. It was hardware keyloggers which nearly resulted in a massive breach in the now infamous Sumitomo Mitsui Bank incident.
More common are software loggers, which are distributed in the same way as other malware. These work by grabbing keyboard data, writing it to a file (or sending it to a network destination) before the OS processes it. There are few technologies to tackle them.
LocalSSL claims to do so. The software operates by encrypting keystrokes to stop software keyloggers capturing any valuable data. The software is provided as web components that will secure web pages for e-commerce, and as desktop application software.
We tested the components by building a simple web application, and embedding the LocalSSL code. Installation is simple: just put the files on your web server and update your HTML. When visiting the page, an Internet Explorer browser will attempt to install an ActiveX control with the LocalSSL software, and a Mozilla or similar browser will be offered a Java component. We like this support for non-IE platforms.
There is also a component to block Browser Help Objects, a frequently exploited facility of IE.
The software installs what is effectively a keyboard handler, aping more or less what keyloggers do: grabbing keystrokes at the earliest stage possible, but then encrypting it and sending gibberish through the OS to the browser, where the software decrypts it again, creating a connection through the OS not unlike an SSL-secured web page across the internet, hence the product name.
At first glance, LocalSSL seemed to work well. Keystroke data was encrypted and conventional keyloggers were unable to capture clear-text data. However, we were able to defeat the product by creating a custom USB keylogger operating in a different way.
Keyboards usually use either PS/2 or USB connectors. PS/2 data is easy to manage – the keylogger hooks the hardware interrupt and captures keystrokes before sending the data on as normal. LocalSSL beats the logger by playing the same trick first, intercepting the keystrokes, encrypting them and sending the indecipherable result through the OS to the application.
USB data is more complex, and passes through a series of drivers before applications ever see the keystrokes: incoming USB traffic is handled by a low-level hub driver, then passed to the human interface device (HID) driver, and lastly to a keyboard driver before going into the OS and userspace.
Most commercial keyloggers sit at the HID or keyboard driver level, capturing keystrokes and then sending them on into the unsuspecting OS and applications. So LocalSSL does the same, but by going a step deeper we created a keylogger that defeated it. We rolled our own keylogger using open source USB driver code and filters to parse keystrokes out of the buffer before it reached LocalSSL and the HID driver.
A trojan or rootkit using this approach would defeat LocalSSL in its current form, although we are not aware of any commercial keylogger currently able to do so. BlueGem says it is aware of this weakness, and says that version 3.1 (due for release shortly), targets a much lower level than the HID layer, which should address this.
We had other concerns about the web component. The ActiveX control requires the user to have administrator privileges on their PC, which is generally a bad idea. The security industry is actively campaigning for users to avoid operating with admin rights all the time, with good reason, so we are wary of technologies requiring admin rights for normal web users.
In reality, most consumers do operate with admin rights, and LocalSSL is aimed at public sites (such as banks) where most users will fall into this category.
Another concern is unexpected consequences. Inserting third-party shims at ring0 (the kernel level) can end badly: conflicts with other drivers can cause instability, crashes or unpredictable results, and the user’s activity really should be sandboxed from the OS as best practice anyway. In environments with no way to test whether the software will cause problems on a customer PC (such as a public website), this could be asking for trouble. We had no problems in testing, but that is no guarantee of stability in general use, although the company claims to have millions of users with no reported problems of this kind.
LocalSSL takes a very clever approach to tackle a problem few other companies have an answer for. While we were able to defeat the current version, the upcoming update should tackle that. And while we would not recommend the product for every situation, for some environments it could be just what you need to reduce the threat of keyloggers. Not a silver bullet, but until TCPA-style keyboards with onboard crypto capabilities are readily available, probably the best option around.
