Asp.Net critical security vulnerability

@YaronNaveh

Edit: Some information in the original version of this post was not correct. I have fixed it.

A few hours ago Microsoft had publicly disclosed a critical Asp.Net security vulnerability. In short, a hacker can get sensitive data from an Asp.Net application in a few minutes. This information includes any file on the server (e.g. web.config) and any viewstate data even if it is encrypted. To block this attack, site owners should immediately direct all errors to a single page (custom errors redirect).

If you have a production Asp.Net system read this now and go fix it.

How does the vulnerability work?

Without making this a walkthrough to my hacker readers, this is the general flow:

Some common encryption algorithms (among them TripleDes and AES) divide the encrypted data to blocks of equal size, where the last block is padded with additional data to make all blocks equal. A few years ago a security researcher had published an article explaining how to hack such an algorithm provided that a "padding oracle" exists. What is a padding oracle? It is an application (or some abstract... oracle) which tels us if the padding of an encrypted data is in the correct format.

Well, it turns out that Asp.Net uses TripleDes, and that some specific feature of Asp.Net turns it into a "padding oracle", you get the idea...


How to avoid this?

1. The single most important rule is this:

When there is an error in your application, never let the end user know what it was. In particular never allow an end user to distinguish between 404 and 500 status codes.


The way to do it is to redirect all errors to one page.
ScottGu's post explains how to do it.

2. The hacker that found this hole wrote his in this twitter account:

error message setting is irrelevant. no error? there's always HTTP status. always the same HTTP status? there's always big timing different

He means that even though we hide from him the real Http status (by redirecting to a single error page) the real status still "leaks" by computing the response time.

This means that adding a random wait before sending the error page can help us. ScottGu's post has the details too.


If you are really interested in the bits & bytes (&blocks) of this kind of attacks this is a nice introduction.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!

Replay attacks in Wcf (now really)

@YaronNaveh

A few months ago I have written a post about replay attacks in Wcf. One of my readers had sent me a mail mentioning that while that post had some interesting information on replay attacks in general, it did not really discussed the Wcf part. In particular he asked me about the Wcf nonce cache and its difference from the Wse one. Also he was interested in cases where a replay attack may become a DOS attack. Here is what I wrote him back:

Yes, Wcf has a replay cache. One difference from the Wse cache is that in Wcf only the primary signature value is used for cache and not a username nonce (Wcf does not emit these anyway). You might want to take a look at some of the relevant Wcf security settings, for example ReplayCacheSize.

If you are really interested you can open reflector in System.ServiceModel.Security.ReceiveSecurityHeader.ProcessPrimarySignature() and see how the primary signature is validated againt the nonce cache:

...
this.primarySignatureValue = signedXml.GetSignatureValue();
    if (this.nonceCache != null)
    {
        CheckNonce(this.nonceCache, this.primarySignatureValue);
    }

...

As for DOS, the cache comes to solve the problem of replay attackes, e.g. an attacker sends a message a second time which makes a transaction presumably run twice and cause business damage. DOS attacks overloads the server with many requests until it stops from effectively surveying clients. While these attacks are not related, the cache used to prevent replay attacks can become very big until the server is out of memory. This can happen with or without a DOS taking place. For this reason the cache is limited in size and after X minutes a timestamp is used instead. If an attacker can send many non-replay requests in a short time to fill the cache he might be able to actually replay a message before the time windows is closed. However this will not be considered a DOS (even if it is just semantics). Regardless, I am not aware of any way for a web site to protect against a massive DOS attack where bots from around the globe act together.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!