The bellLog

Keylogger Evasion?

2009-03-31T20:44:00.001+02:00

Key loggers were big news in 2006, with arrests in France and South Africa and their use in the largest theft yet attempted from a bank in England. Keyloggers are in the news right now because sentencing has just happened in the English case and the alleged author of the unimaginatively named "Codesoft PW Stealer" was arrested earlier this month. Is this lagged reporting of yesterday's threat, or is the issue of keyloggers still relevant?

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.

Security through obscurity is not quite that simple

2008-09-17T11:48:00.004+02:00

In an ISC diary entry yesterday donald smith (dunno what happened to his capitals) talks about continuing brute force attempts against ssh servers. At the end of the entry he recommends changing the ssh port, and then says

For those of you that think that is simply security via obscurity I would agree with the following caveat forcing the bad guys to scan all 64k ports on a system prior to attacking to find the ssh port adds to the time it takes to compromise systems. It buys system owners time to react potentially preventing compromise. It buys ISPs time to notify compromised customers and it is fairly noisy.

I personally prefer port knocking scripts to an obscure ssh port, but this is also criticised as just another layer of obscurity. The objection to security through obscurity is an information security mantra, a recent blog post by Eugene Spafford even claims some responsibility for pushing it. Two rather different ideas are being combined under this one header though:

You can't break it because you don't know how it works
This is the one that, rightly, generates all the condemnation. No comments page on a Register article on cracked anything is complete, or even started, without slagging whoever it is off over trusting security to obscurity.

This can lead to the claim that passwords, PINs and private keys are just a special case of security through obscurity, comments pages being the fonts of wisdom that they are. This in spite of the fact that the published, peer reviewed mechanisms that the commenters are saying should have been used end up resting on a secret somewhere along the line. So secrecy and obscurity are not the same thing?

The answer is in the paper that's often claimed to contain the first statement that security should not be through obscurity, an 1883 piece on army cryptography (in french) by Auguste Kerckhoffs. It states than in a well designed cryptographic system the mechanism need not be kept secret, only the key. Which makes a clear case with regard to cryptography, but doesn't really solve the issue for many other areas where concepts of mechanism/algorithm and key don't exist. Bruce Schneier has a go at generalising the application of the idea in a piece with the obligatory, annoying references to airline security. I don't know whether he wants to make himself seem more relevant to the paranoid security environment or wants to make the issues more accessible and relevant to the public, but I really wish he'd find another source of bloody analogies and examples.

So we have a concept that started with crytography, applies quite well to cryptography needs to be squashed and stretched a bit to apply elsewhere.

You can't attack a target that you don't know is there
This comes in a couple of flavours, what the ISC post was getting at and what port knocking achieves is camouflaging services. Critiques of port knocking make much of the fact that it effectively exposes a password to anyone who is sniffing the traffic. The fact that it will defeat many automated scans and brute force attempts is given a passing mention. Considering the size and activity levels of botnets (a phenomenon more recent than the critique) this is now a must have, not a negligible benefit.

The huge scale of automated attacks shapes the approach to defence in depth too (while we're touring the hall of information security's sacred cows). Ogres and effective security have layers, like onions - or parfait. Mechanisms like port knocking are the onion sauce on the top of the parfait, they make it look unappealing to the skiddies. Below this we can have the more serious defences but if the automatons and scripts are getting to the layer that we're logging and anaylsing we're going to get overwhelmed and it's going to give serious attackers a lot of noise to hide in. Viewing layered security as dealing with threats of increasing seriousness also reduces risk of defence in depth giving a false sense of security. Obscure ports, port knocking and a whole raft of similar approaches will keep the masses at bay, allowing us to deal with the more focussed attackers. They won't help against the more focussed attackers though.

The more contentious side of this idea relates to vulnerability disclosure, which is what Spafford's post is about. The issue is broader, covering general refusal to fix vulnerabilities in the hope that they won't be found, but it's the interaction between researchers, vendors, malware authors and the public that really gets the emotions going. There's not really much more to be said here: Do vendors need pushing? Probably; Do researchers jump the gun in publicising? Sometimes; Does involving lawyers help anyone? No.

Security through obscurity is a broad concept, camouflage is a useful, natural defence but relying on no-one figuring out that you have weak points is unrealistic.

What can we do with the bloated Firefox?

2008-08-07T14:51:00.002+02:00

Mozilla Labs are inviting world and dog to "get involved and share their ideas and expertise as we collectively explore and design future directions for the Web".The comments section is filling up with all sorts of ideas for a 'richer' experience, some abusive crud, some cretins saying 'just make it work' like it was a new idea and a few people pleading for it to be kept simple.

I'm adding my vote for the keep in simple camp. The one idea I really do like, posted quite early in the comments process, is auto-hiding button bars. I don't think that hiding the address bar would be a great idea, since it and the status bar provide what little visibility security has - but the nav buttons, bookmarks and app menu could probably make way for a bit more vertical space.

My own request has nothing to with the visual or user experience, it's a something for the programmers - I'd like script only cookies. This would allow a JavaScript to access a value that persisted across pages and could be used to identify a user's session independently of whatever was being put on the wire and could therefore be sniffed. With a script only cookie in place protocols like J-PAKE and SRP could start to make a meaningful contribution to protecting against session hijacking by attackers on the wire.

The solutions to attacks from within the browser (XSS and CSRF) are different and any advances in this area would help to make a script only cookie less exploitable. An uniform global access control mechanism in the JavaScript engine, defaulted to deny, may impose an unacceptable overhead but if someone far smarter than I am could pull it off it would be great.The Site Security Policy project looks like a great step forward in this regard (there's also a nice synopsis if you're not in the mood for a lot or reading).

It's not a silver bullet. It does place some level of trust in the browser and is vulnerable to tampering by a man in the middle. But that's in line with the threat it's trying to mitigate, so it's OK. The gross simplification of the threat is: A generally available browser on a user's system can be tricked into lying to one website by the content of another website the user happened to open simultaneously. The idea would mainly be of interest to you as the owner or webmaster of the first site. You don't want to execute requests that you think come from a legitimate, authenticated, user of your site but were actually faked by some malicious script from the site they visited in the next tab over. An attacker running a customised browser that ignored the restrictions would gain only the ability to hijack their own sessions, not very useful. If the restrictions could be turned off in a broad base of browsers remotely then there would be some gain - which is all the more reason for this sort of protection to be baked in rather than in a plugin. The appeal and danger in this sort of attack is that it requires so little access to the browser's traffic and can thus target so many machines - injecting some code into a vulnerable bulletin board or CMS will provide far broader coverage far more easily than constructing man-in-the-middle scenario. Mitigating, or even completely removing, this class of vulnerabilities would not make the net a magically fluffy and friendly place but it would make attackers work harder for their gains - which is all we can realistically hope for.