UPDATE: Patch available, forget the workarounds, install it now: http://weblogs.asp.net/scottgu/archive/2010/09/28/asp-net-security-update-now-available.aspx
If you develop or run an ASP.NET based site you need to be aware of a potential attack that has been reported widely, known as the padding oracle exploit whereby encrypted values can be systematically decrypted or encrypted ultimately allowing an attacker to log into a forms authenticated site as a user of their choosing or download arbitrary files. Troy Hunt has an excellent write-up of the crypto stuff at the core of the attack.
There are some immediate things you can do that ScottGu outlines which involve updating <customErrors> in your web.config. But I felt that there are plenty of ASP.NET sites out that have their own way of dealing with errors which may be vulnerable due to the way they report errors.
One example is Exchange Outlook Web Access (Exchange 2007 at least), which by default exposes the underlying error details (helpfully including a stacktrace no less!) in its default error page and therefore can be potentially used as a padding oracle.
E.g. https://exchange.example.com/owa/auth/webresource.axd?d=foo:
This error page is served up as a 200 OK so it can’t be mitigated by a load balancer easily.
Whether an attack can actually be escalated against OWA from this is unknown to me at this time, nor which versions would be affected. OWA might not be using standard Forms Auth etc, but I haven’t heard the definitive word on this. Some kind soul has published steps on how to mitigate this apparent OWA vulnerability on the ASP.NET forums.
Anyway, I looked the attack against ASP.NET general and came up with what I thought was some useful information and posted this on the ASP.NET forums:
I’ve done some digging and come up with what I think is useful information for you if you have a custom error handling solution in place instead of or as well as the usual ASP.NET <customErrors> stuff.
From comments on ScottGu’s post it seem to be that the main suspect to be the actual padding oracle is WebResource.axd (possibly other axd’s).
- If you look in .NET Reflector at the IHttpHandler.ProcessRequest method in System.Web.Handlers.AssemblyResourceLoader there’s a call to Page.DecryptString early on.
- This is the thing that will cause a HTTP 500 status to be returned if it fails, e.g. if the padding, etc in Request.QueryString[“d”] is invalid
- If the attacker manages to get the padding right, then it continues on, ultimately to call throw new HttpException(404…)
It’s this differentiation: is the padding correct (404) or not (500) that is at the root of the exploit: the padding oracle.
If your error handling returns exactly the same response for both – it masks the oracle. To test if you’re vulnerable externally, a simple test is to request both:
- webresource.axd?d=foo
- webresource.axd with no parameters
and check using FiddlerTool, or FireBug that the entire response is identical for both including the status and all the headers (except for the Date header I guess!).
Of course I may have missed something, but I hope this information helps you until the official fix comes out.
Using the script
To automate the above simple test I’ve written a little Windows Script Host script in JavaScript that can be used in a couple of ways:
Here’s what it looks like if you point it at a site that may be vulnerable:
C:>cscript //nologo AspNetPaddingOracleDetector.js http://mysite1.example.com
Testing site: http://mysite1.example.com/
MIGHT BE VULNERABLE: HTTP status mismatch
=== Response 1 ===
404 Not Found
=== Response 2 ===
500 Internal Server Error
And here’s what it look like if the site does not appear to be exposing an obvious padding oracle:
C:>cscript //nologo AspNetPaddingOracleDetector.js http://mysite2.example.com/blah
Testing site: https://mysite2.example.com/blah/
Site might be OK: WebResource.axd is not acting as a padding oracle
Please use your judgement in interpreting the output and do not assume that you are safe/vulnerable based solely on its output.
To test Exchange Outlook Web Access typically you will want to run the script against the /owa/auth virtual directory, e.g. https://msexchange.example.com/owa/auth.
What about ScottGu’s script?
The difference between this script and the one mentioned by ScottGu is that this one actually does a simple test of your site from the outside to see if the mitigations you have put in place are likely to have helped you. For example you may have put an iRule on your F5 BigIP to mitigate the issue: this will help you test if that has been effective.
Plz send me teh codez
Download the script (right-click, save as) and just double-click it to try it out. Or view the script source on Google Code.
Hope that helps!
Duncan Smart's Blog 