Everybody’s talking about the ASP.NET Padding Oracle vulnerability released a few days ago at the ekoparty Security Conference. However, until now there wasn’t enough information on how do you check if your application is vulnerable or not.

Yesterday, Duncan Smart from ASP.NET forums published some very useful information that allows us to do that. An application is vulnerable to a padding oracle attack if it responds differently in the following three cases:

1. When a valid ciphertext is received (one that is properly padded and contains valid data).
2. When an invalid ciphertext is received (one that is not properly padded).
3. When a valid ciphertext is received (properly padded) but the decrypted value is not valid for the application.

If you want to know more about padding oracles, a very good resource is Automated Padding Oracle Attacks with PadBuster.

How do we apply this to ASP.NET?

The key to attacking ASP.NET is the file WebResource.axd. This file is also used in the exploit video released by Juliano Rizzo. This file can be used as a Padding Oracle because it responds differently in all three cases.

Here are the three cases.

1. valid ciphertext

Make a request like http://website.com/application/WebResource.axd?d=jzjghMVYzFihd9Uhe_arpA2
The response status is 200 OK and the response body is the content of the web resource you’ve requested (some javascript code in my case).

2. invalid ciphertext

Make a request like http://website.com/application/WebResource.axd?d=acunetix
The response status is 500 Internal Server Error and the response body is some error message.

3. valid ciphertext but invalid data

Make a request like http://website.com/application/WebResource.axd?d=
The response status is 404 Not Found and the response body is some error message.

This is the padding oracle that allows an attacker to exploit this vulnerability. If your application responds differently in all of these three cases, it’s vulnerable.

Very important: Setting CustomErrors to “On” or “RemoteOnly” (in web.config) doesn’t solve this problem because the padding oracle is still there (the error message displayed on the 500 error page is not important for this vulnerability).  Therefore, the only solution is the one presented by Scott Guthrie.  Edit web.config to use redirectMode set to ResponseRewrite and defaultRedirect to an error page defined by you.

Once this workaround is applied, the application will return the same status code and response body in all three cases. If you are using .NET Framework version 3.5 SP1 or 4.0, it’s even better.

If you are using .NET Framework version 3.5 SP1 or 4.0, the workaround provides further protection by also helping to mitigate against potential timing analysis attacks. The workaround uses the redirectMode=”ResponseRewrite” option in the customErrors feature, and introduces a random delay in the error page. These approaches work together to make it more difficult for an attacker to deduce the type of error that occurred on the server by measuring the time it took to receive the error.

Today we’ve released an update for Acunetix WVS that is automatically checks if your application is vulnerable or not to this ASP.NET vulnerability.

Bogdan Calin

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.

  • The microsoft advisory implies that this vulnerability can be exploited to ends other than merely decrypting application information. In particular, disclosure of files on the system itself. Has anyone investigated this claim? If this is indeed exploitable, this is a situation which is far more worrisome than the exploit which was demonstrated.

    Too, this tool doesn’t reflect the observation that Thai Duong made – which is that the actual response codes are unnecessary, timing attacks can give the same information.

    • @Calandale Yes, from my understanding it’s possible to read the contents of any file from the application directory. The WebResource.axd file can be used to do exactly that. You have to prepare the right value for the d parameter (this parameter specifies what resource/file you want to read). You can do that after you’ve recovered the encryption key.

      The workaround that uses the redirectMode=”ResponseRewrite” option in the customErrors feature introduces a random delay in the error page. Therefore, timing attacks don’t work anymore.

  • Are you aware if by using ResponseRewrite and defaultRedirect it is still possible to carry out Oracle Padding using the response status codes instead of the response body?

    This way attackers could still look for status response codes 302 which would happen on the non-valid ciphertext as you get redirected to the new custom error. which would then give a 200?

    Or does the setting of responserewrite and defaultredirect get around that possible attack scenario?

    • @TheTestManager From my tests, after you’ve configured ResponseRewrite and defaultRedirect there are no redirects (301/302) to the custom error page. I just see a 200 status code. Our tool (HTTP Editor) doesn’t automatically follow redirects.

  • In Case 3 “valid ciphertext but invalid data” (“When a valid ciphertext is received (properly padded) but the decrypted value is not valid for the application.”), is it the same to change only 1 letter of a valid cipher to an invalid one? For example, can we use this one:
    when the valid one is:
    (I’ve changed “jzjghMVYzFihd9Uhe_arpA2” to “jzjghMVYzFihd9Uhe_arpA1”)

  • Comments are closed.