The bellLog

The press on vulnerabilities

2010-05-11T12:57:00.000+02:00

Someone discovered a vulnerability in a Drupal module. He wrote up an advisory on it and the tech press got hold of it. There's no indication of how much PR went into getting the press to pay attention, so we'll hold off the "narcissistic vulnerability pimp" label for the moment. What the hell, let's examine the case for some good, old fashioned, unproductive name calling.

The advisory doesn't give a timestamp, but the Drupal bug report certainly looks like it was copied from the advisory text. It seems to be par for the course for our XSS specialist though. There's a whole list of advisories down the right margin of his site, and on every one I checked the dates for the blog post and the bug submission matched. So far so good. The writeups are awfully stilted, and posting under your own control rather than with the relevant project does come across as a publicity stunt. But so far, so good.

There is one thing that's new about this advisory though - it's got a CVE number. The Common Vulnerabilities and Exposures (CVE) project is funded by the US federal government (currently in the form of the National Cyber Security Division of the U.S. Department of Homeland Security) with the aim of ensuring common identifiers for vulnerabilities and exposures rather than having researchers and vendors issuing a confusing hodgepodge of names and numbers. The CVE number gives another clue or two (ain't timeline analysis wonderful?). A researcher applies for a CVE number, which he can then use in communications regarding the vulnerability. The CVE entry for this vulnerability lists the application date as the 27th of April, 13 days before the announcement and the submission of the bug to the development team.

One possible cause for the delay is hinted at in the vendor response section of the advisory. It boils down to the Drupal security team not believing that the problem requires a security advisory - in this particular case because the bug is in a release candidate module. It isn't the first time this has happened to him though, and previous bug reports would appear to have been made before trying to get a response from the Drupal security team.

All very puzzling, but this is drifting dangerously close to me just being an arsehole because I can't reconcile the alleged pimp's actions with my views on responsible disclosure. The real point of this post what happened after the report.

At some point after the advisory is published and the big report posted Dan Goodin from The Register gets hold of the story. He does some digging and posts this article on the matter later in the day. The Register are generally good about security reporting, one of the few voices not contributing to the FUD snowball effect. In this case it didn't work as well as normal though.

The article took an interesting angle on the problem, commenting on the recent White House release of code depending on the vulnerable module. That they did not find this vulnerability does raise some interesting questions about the thousands of eyes theory on open source software security. Where it all fell apart was in describing the range of systems rendered vulnerable, and that this probably didn't include whitehouse.gov. That the vulnerability could only be exploited by users who already had some level of admin privileges was mentioned, and a Drupal security team developer was quoted as saying that the situation which could be exploited was very rare (in his private capacity of course).

A little bit more detail on the "very uncommon" would have gone a long way to clarifying the situation. I'm certainly not trying to pick on greggles here, he does fabulous work on securing Drupal. I'm not even so sure that Dan did anything wrong here. Something just fell through the cracks. That something comes in three parts:

What is the default state of the privileges required to exploit this vulnerability? Vulnerabilities in things that are turned on by default are a lot more serious. It's common to point out when default configurations are affected, and it should be pointed out when they aren't. In this specific case the permission required is only available to the site super-admin by default, quite an important limitation on the vulnerable population I would think. The vulnerability is also specific to allowing users who can manage blocks to escalate their privileges, it doesn't create any new opportunities for abuse by the super admin.
Under what conditions would these defaults have been changed? Obviously only relevant if the default state isn't vulnerable. Blocks are core to a site's layout and information architecture, so core that they may well be set up once and really not regarded as manageable content. Delegating the authority to manage them is therefore highly unlikely.
Is there a specific installation in question here/How does this affect the specific installation in question here? This will often be impossible to answer definitively. The White House site does look like the blocks are quite fixed though. So it looks like the block admin privilege would not need to have been delegated.

Software companies have PR departments to deal with this sort of thing. Most OSS projects don't. So developers or implementers end up fielding the questions. These tend to be people of technical bent, opposed to spin even if they were able to do it. Answering these questions, even if they aren't asked, doesn't come close to being spin but it will help to keep the reporting reasonable. It would be nice if they were being asked in the first place though ...

HTTP Session Damagement

2010-02-03T21:21:00.000+02:00

I recently began discussions with a potential client who has a an aversion to frameworks. Which got me thinking about session management. Which got me thinking about authentication, session management and the relationship between the two in a lot more detail than I have in a long while.

A user session (as opposed to an application session) is a state of authentication. Since HTTP is stateless this raises the problem of authentication being persisted in some way. Considering the close relationship bewteen the two issues it's not surprising that they share a common overriding security concern - reusability of compromised information. For authentication it's the username and for session management it's the session identifier. It's a fat load of good to an attacker to capture a credential that only be used once, and has already been used.

In an environment without transport layer security these compromises generally involve capturing data off the wire or out of the air. (Don't even get me started on the worrying state of wireless LAN security). And SSLing everything just isn't a solution. It makes a mess of caching, and you're faced with a choice of a big bill from a CA or endless grief with people freaking out over self-signed certificates. Preventing authentication credentials being comporomised this way means not passing them in clear over the wire or the air.

Avoiding sending the password over the wire is quite easy. The techblogosphere is full of sample code and discussions on it. Some of these examples do the job quite well - what is passed over the wire can't be used to derive the password, and it can't be used to replay the login it was captured from. Even these have a piles of comments about the solution not being secure, going on about man-in-the-middle attacks, the need to use TLS and a PKI to secure everything and so on. I have the horrible feeling that some of these commenters think they are taking steps towards making the world a more secure place. Most just take pleasure in beating the poster down.

They are all missing the point though - the leaking of password information in the clear and the replay of logins are separate problem domains from ensuring total secrecy of the content and structure of a web interaction. It may be naive, but I really don't think that the creators of these samples believe themselves to have created an ultimately secure tool. It's just secure enough for their problem domain. There are some great ways to secure communications, but - and this is the bit that some people seem to have trouble with - the time, effort and cost involved in implementing them is not always justified. It is not a case of "If you aren't doing it properly then why even bother" either. The world doesn't consist of TLS with client certificates and RSA keyfobs for authentication for the stuff that matters and password authentication transmitted in the clear for what doesn't with no middle ground. Even if protecting the confidentiality - or even integrity - of login data for a joke site may not be that important for the site itself, protecting the passwords may be the publicly responsible thing to do. Many surveys, including a recent survey on banking password security indicate that passwords are widely reused by the general user community.

As fond as I am of bashing the general user community for all sorts of things, it would be unreasonable to expect them to just stop doing this. The proliferation of sites requiring registration, and therefore authentication, for no reason other than harvesting details is part of the problem here. So are arbitrary limits on the maximum length of passwords and characters used in passwords. Password authentication is a major problem in security usability. With the exception of arbitrary restrictions the solutions to this problem are largely human, not technical - leaving developers singularly unsuited to addressing them. The problem of password leakage can be addressed technically, so we should be doing what we can about it. As we should be doing what we can technically about session hijacking.

The session hijacking problem starts with session state and application state being handled together. Browser cookies are quite fine for storing identifiers for application state, like the last ten items viewed in an online catalog. Even if session identifiers are produced carefully and aren't predictable it's still possible to capture them out of the air. If the guy at the next table in the coffee shop is able to see what you've been looking at in a catalog it's not necessarily a disaster. If he's able to read all your webmail and send mails as you it's rather more of a problem. Who is logged in - authentication state - is regarded as just another piece of application state by many web systems. So if an attacker can steal a session by guessing or capturing the identifier it comes with authentication included.

Preventing reuse of the session identifier sounds like a good answer. The problem with this is that since the attacker can see everything that the legitimate client sees on the network, he is able to predict the next identifier - unless the server and the client share a secret. The server and the client already do share a secret - the password (or a hash or key derived from it). Looked at from a slightly different angle effectively (unpredictably) hopping the session identifier would verify the client's knowledge of the password with each request. Persisting this information client side has its own set of challenges. A Javascript solution would be fraught with troubles. Firstly it introduces yet another way for the data to be captured. Whichever clever trick you're using the get the browser to let you pass the data around may also get closed off by the next browser update specifically because of the possibilities for compromise it creates.

There is a mechanism which allows you to check the client's knowledge of the password at every transaction, and it's built into most browsers an web servers. It's called HTTP Digest Authentication. There is a discussion of the browser and server support in a recent paper delightfully titled "Weaning the Web off of session cookies".

HTTP digest authentication provides some cool possibilities, and some of the restrictions can be worked round. Instead of waiting until I had the whole prof of concept coded, commented and cleaned up before posting I'm posting this bit now and committing to following up. The number of posts which have ended up in eternal draft since the last one I published nearly a year ago is frankly embarrassing. Maybe the partwork approach get me to get thoughts completed and documented, which is what I'm blogging for after all. It's not like I really expect a much of a readership (until my GreatIdea™ sneaks up on me).

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.