Cookie Authentication = Dangerous

September, 17, 2012 Branden Spikes

This new SSL vulnerability, which affects only people using Chrome on websites using SSL encryption compression, could lead to people getting their online accounts hacked.  How big of a target is this, you ask?  Well, I would wager it's pretty much the majority of all Google Apps and FaceBook users, for example.  It's not a small audience at all.  In fact, I'm vulnerable too.

In case you're wondering, the Spikes service would not help here.  The problem is on the server side, so it's those website hosts that need to address this by disabling SSL compression (if enabled) until the threat is resolved.  

But the real problem here is that some of us are too complacent with cookie-based authentication schemes.  I mean, I *love* it when I can just open my browser and go to Google and like magic, everything's logged in and seemingly secure.  But today we learn a lesson about cookie authentication.  Sure, it's great, but there needs to be a 2nd form of authentication along with it, like maybe your source IP or something.  *goes checking Google & facebook authentication settings*

Branden Spikes, CEO CTO and Founder, Spikes Security

Scott Martin - September 18 2012

Actually, I believe that the Spikes service can, indeed, prevent this particular vulnerability from affecting our customers! Read on for more...

There are several good analyses of the SSL compression vulnerability and related CRIME/BEAST exploits on the web but all seem to reach the same two conclusions: the issue did not affect or has been fixed in the current versions of all the major browsers (I normally insert my usual Information Security plug to keep your sh!+ updated at this point), and the vulnerability can also be prevented by turning off compression on the hosting web servers. As is typical of most exploits - it takes both components working together to present the flaw. In this case, both the client and the web servers must be able to support the functions of the exploit (SSL compression). Less than one month ago, Apache (the most common web server out there) just released a new version (2.4.3) which has the option to easily disable the SSL compression - the underlying component of this exploit. The previous version doesn't have this configuration option available. Perhaps the Apache team knew that the "Beast" was bound to rise again!

While it's unreasonable to get the estimated potentially vulnerable 42.8% of all web servers (holy crap!) updated to prevent the issue, the Spikes solution would immediately mitigate the problem as our clients' communications are directly to the Spikes servers. As such, Spikes can ensure that our servers have the appropriate mitigation in place - protecting the "customer to Spikes" communications! Combined this with our use of the current/updated browsing solutions to protect the "Spikes to Internet" side of the communication and our customers remain 100% protected from having their confidential data (i.e. cookie information) revealed in their online communications.

As for the lesson being learned that current cookie authentication practice is still a time-bomb waiting to happen... when in doubt, verify. If a user suddenly comes to a website requesting a new session from a new IP, or even a just an unusual TTL, with a cookie authenticator would you be upset if the site asked you to revalidate through the normal channels just to be sure? I, for one, would appreciate the concern for my security.

References:
iSec Partners - http://isecpartners.com/blog/2012/9/14/details-on-the-crime-attack.html
ThreatPost.com - https://threatpost.com/enus/blogs/new-attack-uses-ssltls-information-leak-hijack-https-sessions-090512
Apache.org - http://httpd.apache.org/docs/2.4/mod/mod
ssl.html#sslcompression


Branden Spikes - September 21 2012

Indeed, it would help to have our proactively maintained and secured solution to offset the risk of a situation like this. However, with this particular issue even the most up-to-date and patched user would have a few days of vulnerability while the 0-day is being discovered and remediated. So, not 100 percent protected, but maybe 99.99999 percent protected ;)


Keep informed.