ASP.NET has the problem similar to the one ORACLE Padding. This helps an attacker to send chosen cipher text to the server and discover if it was decrypted properly based on error code returned by the server. Hacker on many attempts can successfully decrypt the cipher. He might  again alter the plain text and re-encrypt make website crap as well. There is a possibility of decrypting encrypted View State data due to this vulnerability.

A Hacker can see secured information for your public ASP.NET website might request and download files in the Website.These files may be like the web.config file that often contains important data like connection strings, SMTP Credentials, authentication settings. This is a serious flaw that needs to be corrected in ASP.NET.  This vulnerability exists in all the versions of ASP.NET.

1.Go to the Web.config, modify custom errors section as follows.

<configuration>

 <system.web>

 <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/Siteerror.aspx" />

   </system.web>

</configuration>

2. Add an Siteerrror.aspx page  to the application that contains generic information. Anytime error occurs page gets redirects to Siteerror.aspx

3. The error page need to have slight delay. We need to place the below code to the Page_Load() server event handler within the Siteerror.aspx.cs.

using System.Security.Cryptography;

using System.Threading  ;

 protected void Page_Load(object sender, EventArgs e)

        {

            byte[] delay = new byte[1];

      RandomNumberGenerator prng = new RNGCryptoServiceProvider();

      prng.GetBytes(delay);

      Thread.Sleep((int)delay[0]);

         

      IDisposable disposable = prng as IDisposable;

      if (disposable != null) { disposable.Dispose();

      }

SharePoint portal server 2003 is secured for this vulnerability. The following are Major SharePoint Products affected by this vulnerability.

· SharePoint 2010

· SharePoint Foundation 2010

· Microsoft Office SharePoint Server 2007

· Windows SharePoint Services 3.0

· Windows SharePoint Services 2.0

The same work around need to be applied for DNN sites as well.. The work around is based on the DNN Version that we are using. Please refer DNN blog for more details.

This vulnerability applies to all ASP.NET applications, those hosted in Windows Azure. “ So the same work around need to be applied to all the ASP.NET applications using AZURE.

This fix need to be applied to all ASP.NET sites that includes MVC Framework too.

If the WCF Data Service is hosted in ASP.NET, it is possible that the vulnerability is present. If any users use the ASP.Net encryption to hide sensitive information from the client and use that data to make decisions in the WCF Data Service, then they have to apply the work around.

Note : We need not compile the file .This can be directly placed in Webserver.  Use this work around in all the public websites that you host in test or Production . Pass this information to the community as much as you can.

This is just a work around, but not a fix. Soon MS will release a patch for this. I am sure that all of us are eagerly waiting for that to run it in our web applications to make our applications more secure. Un-till then follow this work around !!

[UpDate on Sept 27] : ASP.NET Security Update is going to ship on Tuesday 28th OCT

[UpDate] The Patch has been released. If you are using this patch the above said work around is no longer required.  For downloading the patch as windows update please visit here

The encryption logic for the Form Authentication  tickets indeed has changed, so if you persisted them (in a database) they are no longer valid. There is another related issue – the patch introduced an incompatibility between ASP.NET 1.1 and ASP.NET 2.0/3.5/4.0 Form Authentication  tickets. MS is  working on a fix (in ASP.NET 1.1) for that issue.

If  you are running a Web Farm, please make sure all machines are running the same version of ASP.NET.  Please see the KB Article