A search for "keylogger" at threatexpert.com had 184 results, lots of minor variants but still a lot of malware. Many of these appear to download third party keyloggers. Some of the descriptions of capabilities weren't useful in assessing how important keylogging is as a threat at the moment:
Trojan.PWS.Onlinegames.BS is a Trojan that will start itself automatically and steal passwords of onlinegames on the infected machines.
So does it focus its logging activities on inputs into online game client applications, does it steal data from a local password cache, does it sniff traffic to a list of known servers ... ? If ThreatExpert know they're not telling. For all this their reports certainly give more usable information than anything openly available on the AV vendor sites.
Keylogging isn't going to go away. It's a component of mass malware infections and focussed compromises so we may as well try to do something about it. It has also been the topic of recent security research, although that does smell of an excuse to get to play with James Bond toys.
The installation and operation of keyloggers can be prevented or complicated in many different ways. Two practical and one fanciful technical countermeasure deserve some discussion:
- Hook category whitelists Whitelisting is significantly more effective than blacklisting, but application whitelists impose a significant administrative burden on users and system administrators. They also create a golden opportunity for petty power politics and hiding unrelated preferences and opinions behind the banner of security. More than any other excess this abuse of security as an excuse for aggrandisement and a way to avoid justifying decisions damages the possibility of getting security taken seriously by users.
It would be nice to be able to implement whitelisting only for applications that tried to access certain hooks. This would allow the research team to run SPSS without being given the runaround by a lazy or self important sysad (or a lazy and self important one, yet another demonstration of why enumerating badness is a hiding to nothing) while denying attempts to call SetWindowsHookEx() and company by applications that hadn't been approved. The Windows Vista UIPI implementation seems to be moving in this direction, providing some nuance in a situation where the current options have been the user can or the user can't with no middle ground.
Anti-virus In the absence of whitelisting blacklisting provides some sort of protection. The fact that much of the current malware installs a small set of third party keyloggers would appear to make this task easier than the signature arms race against viruses, trojans and worms. These keyloggers may be placed in categories of threat that either aren't scanned under the default settings of the AV application or have been excluded because the categories are broad enough to include applications that system administrators use to make their lives easier or management use to make employee's lives harder. Exempting certain binaries or certain directories under domain admin control rather than ignoring entire categories would avoid throwing the baby out with the bathwater in this case.
Egress control The rewards of theft can generally only be reaped if the goods can be carried away.On an individual machine level application whitelisting for network connectivity is possible, even if it is sometimes annoying to maintain. Protocol whitelisting and server whitelisting for protocols are possible for individual workstations and enterprise networks. The most carefully constructed whitelists may still be able to do nothing about the abuse of legitimate channels. Blacklisting signatures of mails that transfer stolen data out or web servers that receive the data could be done on an enterprise network, ISPs could also implement some measures along these lines but they haven't shown great interest in dealing with security issues.
Individual machines and ISPs and important in any solution to this issue because the majority of incidents happen on mobile or home machines. It's not the few incidents where governments or banks are taken for millions but the thousands of incidents where individuals are taken for thousands that make up the bulk of the value of these crimes. Technical countermeasures are far more likely to be effective in managed environments like ISPs or enterprise networks. Any type of whitelisting in particular is not going to be done with sufficient care by users suffering from modal dialogue fatigue and controls implemented on the infected machines are more likely to be overridden.
If technical countermeasures are of limited use we look to behavioural countermeasures for an answer. Not opening the cutesy ecard links in a misspelled emails from friends or friends, and the mounds of other advice about avoiding infection are not enough of an answer here. Not all infections are the result of carelessness and many people use computers in the home environment which are subject to carelessness that isn't their own. This is not to say that any attempts at behavioural countermeasures are doomed. It may have proved impossible to get users to behave cautiously enough when they're using computers for entertainment or social communication, that doesn't mean that it is impossible to make them behave more cautiously when using services like internet banking. In this vein I would like to propose a keylogger evasion behaviour.
There are a few things that would cause a keylogger to get an inaccurate picture of of what was typed:
Non printing keystrokes Home, end, backspace and the like affect what happens in a screen control before the value gets sent through to processing code. If the information is to be used by a script of sorts these values would need to be interpreted and acted on rather than just regurgitated to a target server or a hashing routine.
Repositioning the cursor by mouse I'm no great pointing device fan, even the cool little red jelly-tot on the ThinkPad is still just a necessary evil. Being able to continue typing from a point that can't be determined from your keystrokes does have potential though.
Selecting characters to overwrite This is not necessarily only a mouse trick, it could also be carried out with Shift and the arrow keys or home or end.
Pasting characters in While the other mouse options are focussed on GUI dialogues this is most applicable to terminal sessions, particularly on *nix boxes where the middle-click paste is quick and easy.
Let's start with a simple password example, a site that remembers usernames but not sessions or unlocking a private key. The password is OhDearSaidPiglet, or once it's been dressed up a bit to have numbers, specials and a lot of length ()hD3arSa1dPiglet. A strong password, but that's no use if someone just reads it off as you type it.
| What you see | What the local program sees | What the logger sees |
|---|---|---|
| Begin typing the password as if it were in brackets and the first o was a 0 | ||
| ***************** | (OhD3arSa1dPiglet | (OhD3arSa1dPiglet |
| Select the second character of the password (the 0) | ||
| ***************** | (OhD3arSa1dPiglet | (OhD3arSa1dPiglet |
| Overwrite the 0 with a ) | ||
| ***************** | ()hD3arSa1dPiglet | (OhD3arSa1dPiglet) |
Yes, it's a bit contrived (the brackets really do make that pattern easy). But the routine is simple enough that you actually could use it every time you unlock your private key or switch privilege levels on a user's computer to install something. For internet banking where there are often three fields - two numeric and one password - your input can be repositioned across all the fields and at any point in them with far less regard for what would still appear to be a well formed output.
Since there isn't all that much information available on how the current mechanisms for stealing passwords work and how the data they gather is used I don't know how effective this sort of approach would be at frustrating them. But a small step towards making attackers' lives more difficult is, as always, a good thing.
