Protecting your ASP.NET sites against padding oracle attacks
When I was a child, one of my favorite board games was called Mastermind—see http://en.wikipedia.org/wiki/Mastermind_(board_game). One player (the code maker) created a pattern of four colored pegs (of which there were six possibilities with duplicates allowed) and the second player (the code breaker) was tasked with solving the code in twelve guesses or less. Given the fact that there were 1296 possible combinations, it would seem that the code maker would win almost every time. However, a brute force guessing method isn’t required because, after each guess, the code maker provides clues (via different colored pegs) that the code breaker can use to narrow down the list of possible alternatives for each successive guess.
Believe it or not, some mathematicians have created algorithms that take maximum advantage of the clues provided and allow the Mastermind game to be solved in as few as five or six guesses; guaranteed! It's amazing how a few clues can drastically reduce the amount of time necessary to solve a complex problem. This example also demonstrates how serious it can be when you expose clues to sensitive information like passwords. The chances of a hacker guessing those secrets can quickly go from virtually non-existent to almost certain.
Recently, a group of researchers announced that they had discovered a flaw in the cryptography implementation used by ASP.NET to encrypt such things as ViewState data (http://threatpost.com/en_us/blogs/new-crypto-attack-affects-millions-aspnet-apps-091310 ). The technique used to exploit the flaw is called a padding oracle attack. The exact specifics of the exploit method require an advanced degree in mathematics to fully understand, but it boils down to the following. A hacker can send thousands of requests with incorrect cipher data to a web server running ASP.NET, and the web server's response to the incorrect data will differ slightly depending on how it was incorrect. Given enough "guesses," the hacker can gain the insight needed to determine the correct cipher data and then do things like decrypt ViewState data on a page or download files like web.config that contain sensitive information in them. The scariest part is that the researchers demonstrated (and released) a tool that they built that enables the exploit to be leveraged with 100 percent certainty in less than one hour! Given that about a quarter of all websites in the world are powered by ASP.NET, that makes for a pretty huge threat surface.
Fortunately, within hours of the announcement of the vulnerability and accompanying exploit, Microsoft released guidance on how to apply a temporary fix to websites running ASP.NET until they are able to build and test a service pack to fix the cryptography flaw that the exploit leverages. See http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx . Essentially, you must map all web error responses to a generic error web page, as well as add some code to that page to delay how long it takes to display for a random amount of time. Sample code is provided in the guidance.
By taking these steps, your web server will no longer expose the clues required by a hacker to determine the cipher text to decrypt your sensitive information. The guidance also includes links to a frequently asked questions document, a .vbs script that can be used to determine which websites on your web server are still vulnerable, and guidance for protecting SharePoint sites against the vulnerability. Lastly, it contains a reminder that it is always a good idea to encrypt important information within your web.config file, so that if it is ever compromised, the hacker will not be able to utilize the data that it contains. The method used to encrypt data in your web.config file is different than that used for the other items exploited by this vulnerability.
I strongly encourage you to take the steps necessary to protect your ASP.NET websites until a formal service pack is available via Windows Update. I would also recommend monitoring Microsoft security announcements, because as you can see, not every hacker or researcher gives Microsoft time to respond before announcing vulnerabilities to the world. When big news like this happens, every minute counts.