Thursday, September 23, 2010

Check out the Web History link that uses a CSS trick to reveal your history (all on the latest FF).

From the author himself [2]:

evercookie is a javascript API available that produces extremely persistent cookies in a browser. Its goal is to identify a client even after they've removed standard cookies, Flash cookies (Local Shared Objects or LSOs), and others.

evercookie accomplishes this by storing the cookie data in several types of storage mechanisms that are available on the local browser. Additionally, if evercookie has found the user has removed any of the types of cookies in question, it recreates them using each mechanism available.

Specifically, when creating a new cookie, it uses the following storage mechanisms when available:

This is a case of layering several techniques (some known, others new) to create an approach that requires some serious thought to defeat. Much like the MS vulnerability disclosed this week, I think this is more about bringing information to light to promote discussion and progress. As one comment put it, “the bad guys don’t make open source announcements, they keep the code to themselves.”)

Tuesday, September 21, 2010

Microsoft keeps calling this a ‘workaround’ but it’s mitigation at best – sure, for the majority of applications it may be all that’s necessary, but it falls short of cross-the-board prevention. It’s not clear why they’re not more open about the cases that aren’t covered by the suggested workaround but it doesn’t take more than simple reasoning to reveal them. If you’re really concerned about the security of your application, keep reading.

Let’s go back to basics and look at where this issue stems from – all you need to do is differentiate between these three cases…

When the application is passed an encrypted value, it responds in one of three ways:

When a valid ciphertext is received (one that is properly padded and contains valid data) the application responds normally (200 OK)

When an invalid ciphertext is received (one that, when decrypted, does not end with valid padding) the application throws a cryptographic exception (500 Internal Server Error)

When a valid ciphertext is received (one that is properly padded) but decrypts to an invalid value, the application displays a custom error message (200 OK)

And depending on how your application uses encryption, you are still able to do this even with a constant error page – here’s one blogger’s explanation (misses the point, IMO):

How about Microsoft’s workaround?

Well, while the workaround contains a really valuable information, relevant for every system (as for not disclosing the real error), and it will prevent the automated tool released by the researchers to hack your system, it will, by far, NOT protect you from a potential attack!

How so? The workaround assumes that the potential attacker will look for an HTTP error response status (500), or for an error page containing a specific exception message. However, it is enough for attacker to recognize an abnormal, or just different system behaviour on certain requests.

Let’s get back to our ASP.NET system that stores an encrypted sensitive information in a cookie. Each request, the system will probably decrypt this information and use it. In case the ciphertext in a cookie is invalid, an exception will be thrown, and the system may act according to one of the following scenarios:

· Return a constant page, stating there was an error, without providing details– a good practice, this is actually the Microsoft’s workaround

· “Swallow” the exception, and behave like the cookie does not exist. The response may be a redirect to another pager, or just a a slightly changed HTML (instead of user’s name, a “login” link) – This is the way ASP.NET Forms Authentication works.

Note that every one of the possible responses is different from the normal one. Even the last scenario I’ve described above, as clean as it is, still returns a distinctively different response. Therefore, an attacker can take advantage of it, and write a simple script that infers this abnormal behaviour to an Invalid Oracle’s answer. It is that simple!

That’s mostly right except that it’s not sufficient to detect any error condition – you need to be able to discern between two specific error conditions (ciphertext not correctly padded vs. ciphertext is correctly padded but decrypts to an invalid value).

If visitors to your site can do this, you’re still vulnerable. Here’s a scenario: you don’t rely on Forms Authentication, but instead have a custom authentication scheme that relies on encrypted cookies. If an invalid cookie is submitted, you treat the user as anonymous; but if an exception is thrown during decryption, Application_Error kicks in. This scenario, not entirely uncommon, still allows the attacker to replay the request and differentiate between the 3 possible replies.

How does your application respond in these scenarios and how confident are you of the answer?

Monday, September 20, 2010

Update #2: Another good post echoing the “MITIGATE” theme (no signs of “PREVENTION” yet.) And some clarification from SO on how machineKey leaves other files (*.config, /bin/*) vulnerable:

“In ASP.NET 3.5 Service Pack 1 and ASP.NET 4.0 there is a feature that is used to serve files from the application. This feature is normally protected by the machine key. However, if the machine key is compromised then this feature is compromised. This goes directly to ASP.NET and not IIS so IIS's security settings do not apply. Once this feature is compromised then the attacker can download files from your application - including web.config file, which often contains passwords.”

This vector was first published in 2002 (8 years ago) and it’s not unique to .NET either – aspects of JSF, Rails, Django all seem to be affected (is the theme really as simple as encrypted data on the client?).

Update #1: Rinat Abdullin and Vlad Azarkhin offer some good details [4] [5] on this (the only blogs among my subscriptions to even mention the issue so far). Apparently, the difference in response times (among other subtle differences) still allows one to separate errors from accepted responses [6] – though this would require more of a site-specific attack. And the ability to request *.config files might be a secondary exploit for CMS products like DNN or Sitecore that expose the File System through authoring interfaces – though others are suggesting that it can be obtained through WebResource.axd (which uses some kind of key to authenticate incoming request for arbitrary resources).

For a low-level (detailed) explanation of the issue, see Brian Holyfield’s post [6].

Speechless.

Here’s a demo of POET [1] on DNN [2] – still unclear how this can be used to actually request *.config files though (potentially more serious, IMO):

The suggested fix [3], part of standard deployment best-practices, is to mask underlying HTTP error codes:

<customErrors mode="On" defaultRedirect="~/error.html" />

That’s the guidance from Microsoft, anyway; the group that released this video claims that “the setting of CustomErrors is _irrelevant_”.

Lots of confusion over this one, let’s hope it gets cleared up ASAP – stay tuned.