The recent ASP .NET vulnerability is an ongoing concern. It works in a way that is generalisable to other systems and it is only a matter of time before other security holes are found. New details of how Microsoft plans to fix it and what to do in while we wait ...

At the end of last week Microsoft had to deal with the discovery of a security hole in ASP .NET which it moved to fix with remarkable speed. However, there is more to say and questions to answer. Scott Guthie's blog, once again, carries the weight of what Microsoft needs to tell us.

The security problem was revealed at the Ekoparty conference in Argentina. Two "security researchers" demonstrated how using the DotNetNuke CMS and a tool called Poet. They then posted a video which you can see below on how to do it.

The video shows the setting up of a new DotNetNuke web site complete with security keys. It then goes on to show how the security can be broken to obtain a key and create the superuser's cookie.

With the easy to get  hold of tool and the "make it simple" video almost anyone could break into almost any .NET ASP web site. The pubic disclosure, before Microsoft had time to respond, is clearly a questionable act.

Microsoft is working on an update to ASP.NET that will be released via Windows Update after testing is complete. Until this is ready Microsoft expects ASP .NET users to manually configure things to protect themselves against the problem. For details of how to do this see  ScottGu

The workarounds are temporary - and will not be required once the update fixes the problem.

All types of ASP.NET Applications (including both Web Forms and MVC), including SharePoint are vulnerable to the attack. (A SharePoint fix has been posted)

The vulnerability is due to the way ASP .NET uses the  3DES encryption and SHA1 cryptographic hash function - both are widely used. It is also likely that other systems that send encrypted cookies,  JSF for example, are vulnerable to the same sort of attack. 

ASP.NET uses encryption padding in a way that provides information in error responses that can be used by a malicious party to work out the encryption key being used.

As the exploit is based on sending lots of requests that generate errors, a sure sign that your site is being attacked is the presence of  thousands (or more likely tens of thousands) of HTTP 500 and 404 error responses to a single client. 

You can use stateful filters in your firewall or intrusion detection systems on your network to detect such patterns and block such clients.  The Dynamic IP Restrictions module supported by IIS 7 can also be used to block these types of attacks. It should also generate thousands of warnings in the application event log of your server.

As the exploit examines the codes in the error responses to work out the key, the current workaround plugs the hole by changing the way error messages are generated so that the server always returns the same error response. Of course any programmer who has implemented a custom error module has to modify the code to make sure that they don't provide information about the nature of the error.

Further reading

New ASP .NET vulnerability

3DES

SHA-1