How serious is this new ASP.NET security vulnerability and how can I workaround it?
What should I do to protect myself?
[Update 2010-09-29]
Microsoft security bulletin
KB Article with reference to the fix
ScottGu has links for the downloads
[Update 2010-09-25]
While we are waiting for the fix, yesterday ScottGu postet an update on how to add an extra step to protect your sites with a custom URLScan rule.
Basically make sure you provide a custom error page so that an attacker is not exposed to internal .Net errors, which you always should anyways in release/production mode.
Additionally add a random time sleep in the error page to prevent the attacker from timing the responses for added attack information.
In web.config
<configuration>
<location allowOverride="false">
<system.web>
<customErrors mode="On" defaultRedirect="~/error.html" />
</system.web>
</location>
</configuration>
This will redirect any error to a custom page returned with a 200 status code. This way an attacker cannot look at the error code or error information for information needed for further attacks.
It is also safe to set customErrors mode="RemoteOnly", as this will redirect "real" clients. Only browsing from localhost will show internal .Net errors.
The important part is to make sure that all errors are configured to return the same error page. This requires you to explicitly set the defaultRedirect attribute on the <customErrors> section and ensure that no per-status codes are set.
What's at stake?
If an attacker manage to use the mentioned exploit, he/she can download internal files from within your web application. Typically web.config is a target and may contain sensitive information like login information in a database connection string, or even link to an automouted sql-express database which you don't want someone to get hold of. But if you are following best practice you use Protected Configuration to encrypt all sensitive data in your web.config.
Links to references
Read Microsoft's official comment about the vulnerability at http://www.microsoft.com/technet/security/advisory/2416728.mspx. Specifically the "Workaround" part for implementation details on this issue.
Also some information on ScottGu's blog, including a script to find vulnerable ASP.Net apps on your web server.
For an explanation on "Understanding Padding Oracle Attacks", read @sri's answer.
Comments to the article:
The attack that Rizzo and Duong have implemented against ASP.NET apps requires that the crypto implementation on the Web site have an oracle that, when sent ciphertext, will not only decrypt the text but give the sender a message about whether the padding in the ciphertext is valid.
If the padding is invalid, the error message that the sender gets will give him some information about the way that the site's decryption process works.
In order for the attack to work the following must be true:
- Your application must give an error message about the padding being invalid.
- Someone must tamper with your encrypted cookies or viewstate
So, if you return human readable error messages in your app like "Something went wrong, please try again" then you should be pretty safe. Reading a bit on the comments on the article also gives valuable information.
- Store a session id in the crypted cookie
- Store the real data in session state (persisted in a db)
- Add a random wait when user information is wrong before returning the error, so you can't time it
That way a hijacked cookie can only be used to retrieve a session which most likely is no longer present or invalidated.
It will be interesting to see what is actually presented at the Ekoparty conference, but right now I'm not too worried about this vulnerability.
Understanding Padding Oracle Attacks
Lets assume your application accepts an encrypted string as a parameter - whether the parameter is a cookie, a url parameter or something else is immaterial. When the application tries to decode it, there are 3 possible outcomes -
Outcome 1 : The encrypted string decrypted properly, and the application was able to make sense of it. Meaning, if the encrypted string was an 10 digit account number, after decryption the application found something like "1234567890" and not "abcd1213ef"
Outcome 2 : The padding was correct, but after decryption the string obtained was gibberish that the app couldn't understand. For example, the string decrypted to "abcd1213ef", but the app was expecting only numbers. Most apps will show a message like "Invalid account number".
Outcome 3 : The padding was incorrect, and the application threw some kind of error message. Most apps will show a generic message like "Some error occurred".
In order for a Padding Oracle attack to be successful, the attacker must be able to make several thousands of requests, and must be able to classify the response into one of the above 3 buckets without error.
If these two conditions are met, the attacker can eventually decrypt the message, and then re-encrypt it with whatever he wishes. Its just a question of time.
What can be done to prevent it?
Simplest thing - anything sensitive should never be sent to the client, encrypted or no encrypted. Keep it on the server.
Make sure that outcome 2 and outcome 3 in the above list appear exactly the same to the attacker. There should be no way to figure out one from the other. This is not all that easy, though - an attacker can discriminate using some kind of timing attack.
As a last line of defence, have a Web Application Firewall. The padding oracle attack needs to make several requests that look almost similar (changing one bit at a time), so it should be possible for a WAF to catch and block such requests.
P.S. A good explanation of Padding Oracle Attacks can be found in this blog post. Disclaimer: Its NOT my blog.
From what I read until now...
The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances
They need the encrypted cookie of a user that have been already logged in, on any account. They also need to find data in cookies - I hope that developers do not store critical data in cookies :). And there is a way that I have below to not let asp.net store data in the login cookie.
How can someone get the cookie of a user that is online if he doesn't get his hands on the browser data? Or sniff the IP packet ?
One way to prevent that is to not allow cookies to transport without ssl encryption.
<httpCookies httpOnlyCookies="true" requireSSL="true" />
Also one more measure is to prevent storing Roles in cookies.
<roleManager enabled="true" cacheRolesInCookie="false">
Now about the cookies that are not secure for the regular pages, this needs some more thinking what you left your user do and what not, how you trust him, what extra check you can do (for example if you see a change on the ip, maybe stop trust him until relogin from security page).
Reference:
Can some hacker steal the cookie from a user and login with that name on a web site?
How to check from where attacks come and not give back informations. I wrote here a simple way to prevent the padding is invalid and logging at the same time to track down attackers: CryptographicException: Padding is invalid and cannot be removed and Validation of viewstate MAC failed
The way to track the attacker is to check the padding is invalid. With a simple procedure you can track them down and block them - they need some thousands of call on your page to find the key !
Update 1.
I have download the tool that suppose that's find the KEY and decrypt the data, and as I say its trap on the above code that's check the viewstate. From my tests this tool have many more to fix, for example can not scan compressed view state as it is and its crash on my tests.
If some one try to use this tool or this method the above code can track them down and you can block them out of your page with simple code like this one "Prevent Denial Of Service (DOS)", or like this code for preventing Denial of service.
Update 2
Its seems from what I read until now that the only think that is really need it to not give information back about the error, and just place a custom error page and if you like you can just create and a random delay to this page.
a very interesting video on this issue.
So all the above its more measure for more protections but not 100% necessaries for this particular issue. For example to use ssl cookie is solve the snif issue, the not cache the Roles in cookies it good to not send and get back big cookies, and to avoid some one that have all ready crack the code, to just place the admin role on the cookie of him.
The viewstate track its just one more measure to find attack.