ASP.NET Padding Oracle Detector

UPDATE: Patch available, forget the workarounds, install it now:

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.



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:

  • double-click it and you will be prompted for a site URL
  • or invoke from a Command Prompt passing the site URL as the first argument. e.g.:
    cscript AspNetPaddingOracleDetector.js

Here’s what it looks like if you point it at a site that may be vulnerable:

C:>cscript //nologo AspNetPaddingOracleDetector.js
Testing site:

=== 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
Testing site:
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.

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!

Follow @duncansmart on Twitter

16 thoughts on “ASP.NET Padding Oracle Detector

  1. Thanks for posting this and the tool. In testing this against SharePoint I found that the error page would have the form element post back to the current url (which would throw your tool). To work around this, replace your response1.body != response2.body line with the following:

    if (response1.body.replace(//, "") != response2.body.replace(//, "")) {

    If I could figure out how to submit changes to your Google Code, I would.

    1. Maybe this will work:

      if (response1.body.replace(/<form name="aspnetForm.*?>/, "") != response2.body.replace(/<form name="aspnetForm.*?>/, "")) {

      1. Cheers Jon, I saw that behaviour too. Not sure if it can be completely automated and some judgement will always be required interpreting the results. If you’ve ever had a site penetration tested, there are plenty of false positives to be sifted through like this.

      2. In reply to Duncan really, but if you are getting lots of false positives from your penetration testers, you aren’t using the right testers. They should be eliminating the false positives before giving you the report, and giving you good actionable advice on how to fix the problem. Thats what you are paying for, if you are just getting the output of a tool then you could be running the tool your self.

        Anyway, thanks for the help ID’ing how to spot a vulnerable site, adds a much needed extra detail missing from the info from MS.

      3. Andrew – tell me about it! You’re absolutely right. Unfortunately we don’t always get to choose the testers – they’re chosen/mandated by particular customers.

  2. Nice one Duncan, very quick way to test for different response types. The other thing that might be worth looking for is response duration over “n” enumerations. Scott Gu’s random sleep code has some merit and too much consistency in the response duration will likely disclose it hasn’t been implemented. Of course before that though you’ve got to make sure your HTTP response code is 200 or else response rewriting isn’t turned on and you’ll likely be getting 302s anyway. Food for thought 🙂

    BTW, someone left me a comment on my post about the padding oracle today which seems to demonstrate a way to force the underlying server error – regardless of custom error configuration – using an invalid “aspxerrorpath” query string value. I’m interested in whether people can see validity in this:

    1. Thanks Troy,

      Wow – that aspxerrorpath one is classic.

      I’ve come across that before… yes in Reflector: HttpReponse.RedirectToErrorPage. I’ve used it so that javascript on a static Error.htm page can sniff the “X-AspNet-Version” HTTP header so that we can tell the administrator that they’ve configured a site to run under the wrong version of .NET.

    1. as far as i see, your site is testing the vulnerability in a wrong way, you should use following requests to identify problem

      webresource.axd?aspxerrorpath=test – 404
      webresource.axd?d=test&aspxerrorpath=test 404

  3. while 1; do echo Don’t waste your time with workarounds; done
    This vulnerability can be exploited even if the server shows exactly the same error and takes the same amount of time to answer. Patch and stop confusing people.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s