What should I do to protect myself?
ScottGu has links for the downloads
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.
<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.
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.