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.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
