Important: ASP.NET Security Vulnerability

A few hours ago we released a Microsoft Security Advisory about a security vulnerability in ASP.NET.  This vulnerability exists in all versions of ASP.NET.

This vulnerability was publically disclosed late Friday at a security conference.  We recommend that all customers immediately apply a workaround (described below) to prevent attackers from using this vulnerability against your ASP.NET applications.

Important Update: You can now download the official security patch update here.  Please install it ASAP on your servers – it is the only way to protect against the vulnerability.  You should no longer rely on the below workaround and instead install the official security patch update immediately to protect yourself.

What does the vulnerability enable?

An attacker using this vulnerability can request and download files within an ASP.NET Application like the web.config file (which often contains sensitive data).

At attacker exploiting this vulnerability can also decrypt data sent to the client in an encrypted state (like ViewState data within a page).

How the Vulnerability Works

To understand how this vulnerability works, you need to know about cryptographic oracles. An oracle in the context of cryptography is a system which provides hints as you ask it questions. In this case, there is a vulnerability in ASP.NET which acts as a padding oracle. This allows an attacker to send cipher text to the web server and learn if it was decrypted properly by examining which error code was returned by the web server.  By making many such requests (and watching what errors are returned) the attacker can learn enough to successfully decrypt the rest of the cipher text.

How to Workaround The Vulnerability

A workaround you can use to prevent this vulnerability is to enable the <customErrors> feature of ASP.NET, and explicitly configure your applications to always return the same error page - regardless of the error encountered on the server. By mapping all error pages to a single error page, you prevent a hacker from distinguishing between the different types of errors that occur on a server.

Important: It is not enough to simply turn on CustomErrors or have it set to RemoteOnly. You also need 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.

Enabling the Workaround on ASP.NET V1.0 to V3.5

If you are using ASP.NET 1.0, ASP.NET 1.1, ASP.NET 2.0, or ASP.NET 3.5 then you should follow the below steps to enable <customErrors> and map all errors to a single error page:

1) Edit your ASP.NET Application’s root Web.Config file.  If the file doesn’t exist, then create one in the root directory of the application.

2) Create or modify the <customErrors> section of the web.config file to have the below settings:

<configuration>        

   <system.web>

      <customErrors mode="On" defaultRedirect="~/error.html" />

   </system.web>        

</configuration>

3) You can then add an error.html file to your application that contains an appropriate error page of your choosing (containing whatever content you like).  This file will be displayed anytime an error occurs within the web application.

Notes: The important things to note above is that customErrors is set to “on”, and that all errors are handled by the defaultRedirect error page.  There are not any per-status code error pages defined – which means that there are no <error> sub-elements within the <customErrors> section.  This avoids an attacker being able to differentiate why an error occurred on the server, and prevents information disclosure.

Enabling the Workaround on ASP.NET V3.5 SP1 and ASP.NET 4.0

If you are using ASP.NET 3.5 SP1 or ASP.NET 4.0 then you should follow the below steps to enable <customErrors> and map all errors to a single error page:

1) Edit your ASP.NET Application’s root Web.Config file.  If the file doesn’t exist, then create one in the root directory of the application.

2) Create or modify the <customErrors> section of the web.config file to have the below settings.  Note the use of redirectMode=”ResponseRewrite” with .NET 3.5 SP1 and .NET 4.0:

<configuration>

   <system.web>

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

   </system.web>

</configuration>

3) You can then add an Error.aspx to your application that contains an appropriate error page of your choosing (containing whatever content you like).  This file will be displayed anytime an error occurs within the web application.

4) We recommend adding the below code to the Page_Load() server event handler within the Error.aspx file to add a random, small sleep delay. This will help to further obfuscate errors.

VB Version

Below is a VB version of an Error.aspx file that you can use, and which has a random, small sleep delay in it.  You do not need to compile this into an application – you can optionally just save this Error.aspx file into the application directory on your web-server:

<%@ Page Language="VB" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>

<script runat="server">
    Sub Page_Load()
        Dim delay As Byte() = New Byte(0) {}
        Dim prng As RandomNumberGenerator = New RNGCryptoServiceProvider()
        
        prng.GetBytes(delay)
        Thread.Sleep(CType(delay(0), Integer))
        
        Dim disposable As IDisposable = TryCast(prng, IDisposable)
        If Not disposable Is Nothing Then
            disposable.Dispose()
        End If
    End Sub
</script>

<html>
<head runat="server">
    <title>Error</title>
</head>
<body>
    <div>
        Sorry - an error occured
    </div>
</body>
</html>

C# Version

Below is a C# version of an Error.aspx file that you can use, and which has a random, small sleep delay in it.  You do not need to compile this into an application – you can optionally just save it into the application directory on your web-server:

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>

<script runat="server">
   void Page_Load() {
      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(); }
    }
</script>

<html>
<head runat="server">
    <title>Error</title>
</head>
<body>
    <div>
        An error occurred while processing your request.
    </div>
</body>
</html>

How to Verify if the <customErrors> section is correct

Once you have applied the above configuration, you can test to make sure the <customErrors> section is correctly configured by requesting a URL like this from your site: http://mysite.com/pagethatdoesnotexist.aspx 

If you see the custom error page appear (because the file you requested doesn’t exist) then your configuration should be setup correctly.  If you see a standard ASP.NET error then it is likely that you missed one of the steps above.  To see more information about what might be the cause of the problem, you can try setting <customErrors mode=”remoteOnly”/> – which will enable you to see the error message if you are connecting to the site from a local browser.

Install and Enable IIS URLScan with a Custom Rule

If you do not already have the IIS URLScan module installed on your IIS web server, please download and install it:

It takes less than a minute to install on your server. 

Add an Addition URL Scan Rule

Once URLScan is installed, please open and modify the UrlScan.ini file in this location:

  • %windir%\system32\inetsrv\urlscan\UrlScan.ini

Near the bottom of the UrlScan.ini file you’ll find a [DenyQueryStringSequences] section.  Add an additional “aspxerrorpath=” entry immediately below it and then save the file:

[DenyQueryStringSequences]
aspxerrorpath=

The above entry disallows URLs that have an “aspxerrorpath=” querystring attribute from making their way to ASP.NET applications, and will instead cause the web-server to return an HTTP error.  Adding this rule prevents attackers from distinguishing between the different types of errors occurring on a server – which helps block attacks using this vulnerability.

After saving this change, run “iisreset” from a command prompt (elevated as admin) for the above changes to take effect.  To verify the change has been made, try accessing a URL on your site/application that has a querystring with an aspxerrorpath and verify that an HTTP error is sent back from IIS.

How to Find Vulnerable ASP.NET Applications on Your Web Server

We have published a .vbs script that you can save and run on your web-server to determine if there are ASP.NET applications installed on it that either have <customErrors> turned off, or which differentiate error messages depending on status codes.

You can download the .vbs script here.  Simply copy/paste the script into a text file called “DetectCustomErrors.vbs” and save it to disk.  Then launch a command window that is elevated as admin and run “cscript DetectCustomErrors.vbs” to run it against your local web-server.  It will enumerate all of the applications within your web server and verify that the correct <customErrors> configuration has been specified.

command[1]

It will flag any application where it finds that an application’s web.config file doesn’t have the <customErrors> section (in which case you need to add it), or doesn’t have it set correctly to workaround this attack (in which case you need to update it).  It will print “ok” for each application web.config file it finds that is fine.  This should hopefully make it easier to locate issues.

Note: We have developed this detection script over the last few hours, and will be refining it further in the future.  I will post an update in this section each time we make a change to it.

How to Find More Information about this Vulnerability

You can learn more about this vulnerability from:

Forum for Questions

We have setup a dedicated forum on the www.asp.net site to help answer questions about this vulnerability.

Post questions here to ask questions and get help about this vulnerability.

Summary

We will post more details as we learn more, and will also be releasing a patch that can be used to correct the root cause of the issue (and avoid the need for the above workaround).

Important Update: You can now download the official security patch update here.  Please install it ASAP on your servers – it is the only way to protect against the vulnerability.  You should no longer rely on the below workaround and instead install the official security patch update immediately to protect yourself.

Thanks,

Scott

Published Saturday, September 18, 2010 4:23 AM by ScottGu

Comments

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 7:44 AM by Quango

Rushes off to patch web config.. fortunately I use customErrors already as should any good site

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 7:45 AM by José Alberto Monteiro Albuquerque

This errors happened yesterday on hotmail, right?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 7:49 AM by DnshPly9

Nice information

Thanks.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 7:50 AM by Rajesh

Does it affect Sharepoint sites too?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 7:55 AM by ScottGu

@Quango,

>>>>>>>>> Rushes off to patch web config.. fortunately I use customErrors already as should any good site

Please make sure to also map all custom errors to a single error page.  It is not enough to simply enable customErrors.  You also need to specify the defaultRedirect attribute and make sure that there are no sub <error> elements within the <customErrors> section.  My post above describes how to do this.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 7:56 AM by ScottGu

@Rajesh,

>>>>>>>>> Does it affect Sharepoint sites too?

Yes - it also impacts Sharepoint.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:03 AM by Irfan Suleman

Thank you, will update

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:09 AM by Anon2010

I don't have a <customErrors> element declared in my web.config, I have instead an IHttpModule inside the <modules> section. This module logs the error and redirects to either a search page (for 404's) or to an error page (for 500's). Am I vulnerable?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:10 AM by Barry Kelly

Unless I'm sorely mistaken, random waits will do nothing to fix this, just slow down the attacker somewhat, or force him to use more machines. Random waits average to a constant wait; there's already random latency in the network traffic.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:12 AM by Anthony

I have my own error module I use to return different error pages. Am I effected?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:13 AM by jangwenyi

This is serious I think and we need to apply the workaround as recommended.

I have encrypted my sensitive sections of the web.config, such as connection strings. Should I be worried?

forums.asp.net/.../1603804.aspx

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:17 AM by Vijay.Pandurangan

Will the ASP.NET MVC too get affected?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:17 AM by TheJet

How does this allow exposure of web.config?  This seems to enable decrypting of ViewState only, is there another related vulnerability that also allows the information disclosure?  Is there a whitepaper that details the attack for a better explanation of what's going on?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:18 AM by Steve Fenton

I take it we can still have a custom 404 page defined in addition to the default redirect on error, without violating the principles described above?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:22 AM by Steve Fenton

When it says no sub elements for errors should be defined, does this even include 404 errors?

<customErrors mode="RemoteOnly" defaultRedirect="/Error/">

<error statusCode="404" redirect="/Not-Found/"/>

</customErrors>

i.e. Should I change this to

<customErrors mode="RemoteOnly" defaultRedirect="/Not-Found/" />

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:25 AM by Demis Bellot

Is this a fundamental flaw in ASP.NET or just .NET's implementation of it? I.e. Will this affect mono ASP.NET web applications as well?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:26 AM by granicz

Does the vulnerability only affect resources accessible via ASPX pages?  Or do we also need to make changes to the custom error pages in IIS?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:29 AM by Peter

How is it possible to read the entire web.config just by decyphering what's in the viewstate? I understand that someone could put certain parts of it into the viewstate but you say this attack allows them to download the entire web.config? How can this happen in a REST environment?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:30 AM by Paco

Do we have to keep using a workaround in the future or will microsoft create a solution for this?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:54 AM by Mike

Scott,

Wow.  This is kind of a big one -- kudos to the ASP.NET team for such a quick response.

Does the vulnerability only extend to a particular site?  For example, if I am hosting 20 sites and 8 of them are patched, are those 8 vulnerable because the other 12 are not patched?

Can you provide an ETA on when the patch will be available?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 9:22 AM by Doug Rohrer

Vijay:

Remember ASP.NET MVC _is_ ASP.NET under the covers, and uses the same encryption, cookie handling, etc. that ASP.NET does, so I would assume that any ASP.NET MVC application would also be vunerable.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 9:28 AM by David

Thanks for the tip- I'm assuming this affects DotNetNuke sites as well?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 9:31 AM by Brock

Just wonder, for 3.5 sites and below, does the generic error page have to be html? Or can it be aspx, ie code, masterpage. Cheers

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 9:40 AM by TaoYang

Thank you for the information! will it also affect ASP.NET MVC? ASP.NET MVC doesn't have viewstate that need to be encrypted.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 9:45 AM by Vlad

Guys, this info is somewhat misleading. Sorry, Scott.

I've been investigating this exploit for the last couple of days. It's not important what error message the asp.net application returns. The fact that an error was returned, or any other abnormal response is enough to use the exploit.

The vulnerability exists not only in asp.net but in most other frameworks, like java.

The problem is in the AES encryption algorithm, which allows cracking the cipher by using oracles.

The only real cure is not to store any sensitive data on the client..

BTW, from my tests, the vulnerability can not be used to decrypt asp.net forms authentication cookie, since asp.net forms auth mechanism does not return any error. It just disregards the auth cookie, in case the cipher is invalid.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 9:48 AM by Joel Martinez

@Vijay, yes ... any web application that uses the ASP.NET platform (as in ASP.NET MVC) will be affected by this.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 9:51 AM by manish

really cool information

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:00 AM by Ken

can't use status code error pages anymore!? well that sucks

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:15 AM by Marik

Download the web.config file?!! Why do not fix this issue in the ASP.NET framework and release it through Windows Update ASAP? We have custom logic in the global.asax on the Application_Error event, and after that we displays two types of error pages without any specific error information. Does it help? We cannot change application's logic right now because of very serious bug in the ASP.NET framework.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:16 AM by Stilgar

Come on... who lets the default error page with exception information show on a production server? Give me a break...

If someone does this he should be fired anyway.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:37 AM by Marcus King

Vijay.Pandurangan yes ASP.NET MVC is affected too.  To be clear ANY version of .NET code running in the web is vulnerable including all versions 1.1, 2.0, 3.0, 3.5 and 4.0.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:42 AM by Jim Harte

If a site is using Windows authentication (Basic or Integrated), as opposed to Forms Authentication, is it still vulnerable?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:47 AM by dotnetguts

I have a asp.net website on shared web hosting.  How can i run the script to verify things are good?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:48 AM by Daniel Martín

@Vijay.Pandurangan: The vulnerability is in ASP.NET, so ASP.NET WebForms and ASP.NET MVC are both affected.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:49 AM by C-J Berg

It’s a shame the security researchers who discovered this vulnerability chose to go public before a hotfix had been made available. Thinking something good could come out of it is very naïve. They’re only helping the bad guys out there.

Many thanks to Scott and Microsoft for taking this seriously and being very public about it, now when the genie is out of the bottle. All my server applications are now reconfigured and protected!

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:52 AM by Nitin

Is the httpErrors tag in system.webserver also affected?

What if we're using Application_Error in global.asa to handle all the errors ourselves (via Server.ClearError -> Server.Transfer)?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:54 AM by Adeel

Is asp.net mvc 2 is also vulnerable for this attack?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 11:11 AM by Alecco

The work around doesn't solve anything. This is BS from Microsoft because a real fix requires a redesign of many, many things. This doesn't address the timing of responses, just to name 1 other way to do the attack.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 11:13 AM by Brian Feucht

Can you please provide details on why you can't have sub error elements?  I've taken a look at the details of this vulnerability and from I understood the encryption padding attack needs to be able to differentiate between two different exceptions.

The reason why I ask is I have many applications which use a separate error page for 404s.  I wasn't expecting these to be an issue.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 11:16 AM by Johnny O

Scott, this is really unfortunate.  We have 2 error pages.  One for 404 (page not found) and one for everything else.  404 errors should give a properly descriptive message to the user, so having to send users to same error page for ALL errors results in poor user experience.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 11:22 AM by Phill

C:\Websites>cscript DetectCustomErrorsDisabled3.vbs

Microsoft (R) Windows Script Host Version 5.7

Copyright (C) Microsoft Corporation. All rights reserved.

Could not find IIS ADSI object. Make sure you have IIS and IIS6 management compa

tibility installed.

^ I get this running it on Windows Server 2008 with IIS7? Do I REALLY need to install the IIS6 management compatibility stuff just to run this?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 12:13 PM by Lee Cichanowicz

Scott, I'm confused.  So it’s not just that we should deliver the same page (content) for all content, we should also deliver the same HTTP status code?  If so, which status code?  Further, if so, this is going to cause search engine indexing issues.  If a request comes in for a resource that no longer exists, I need to return a 404 to search bots.  Please clarify.

Cordially,

Lee

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 12:16 PM by Rabin

Thank you Scott, this is good to know. Will go ahead and patch it asap.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 12:16 PM by hajan

@Scott, thanks for this info!

Nice to see someone discovered this.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 12:47 PM by Evan

Why Custom Errors?  Why not just flip the encryption method from AES to 3DES in the config?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 12:48 PM by Michael

What is the timeline on release of a patch?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 1:00 PM by Drew

What about sites that use classic ASP only, and not coded in .NET? Any exposure there?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 1:35 PM by Martin Aatmaa

More information would be appreciated. In particular, whether we can continue to distinguish between 400 and 500 error types. If not, that's a significant regression in required functionality.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 1:41 PM by Dino

Hi,

Really appreciate the heads up! Do IIS errors need to be configured also vs. ASP.NET errors? e.g. on a SharePoint 2010 install I'm looking at I note that the 404 error comes from the IIS config, not the ASP.NET customErrors.

Also, is a hotfix imminent for the likes of Outlook Web Access and Communicator Web Access, or should we apply the workaround to these services manually?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 1:51 PM by SunJ

"The work around doesn't solve anything. This is BS from Microsoft"

That is how all of this reads. Changing the error page contents will not alter the HTTP status code returned in the response from IIS and, as others have mentioned, the time that IIS takes to respond in the two types of exception case can also be used to distinguish between the two cases.

As a side note : you *really* can't start changing the HTTP status codes used in HTTP responses as not only would this make your IIS non RFC compliant as an HTTP Web Server, it will mess up all sorts of browser behaviors; not least of which is how the browser responds to authentication challenges, i.e. when you ask for a URL to an objet on a password secured path, the browser sends a direct request and only when the web server responds with the appropriate HTTP status code, does the browser then prompt the user for the password credentials. If you start messing with HTTP status codes in IIS as a way to try and "patch" this vulnerability, you WILL cause yourself an outage on your .NET applications, including SharePoint. Please be warned.

The ASP.NET team is trying to appear put a "workaround" out there as fast as possible, presumably from some heavy handed top level Microsoft pressure to avoid the headline news story controversies like "All Microsoft Web Servers open to Hackers". In reality this "workaround" is little more than trying to use a mousetrap in a large room - the mouse can always go straight past the trap instead, but hey, atleast Microsoft can claim that they responded. The problem is that not only does this "workaround" not patch it up completely, the confusion that it's creating could cause trigger happy and hyper-sensitive IT admins to attempt drastic measures to seal off an apparently huge risk.

<rant>

Come on people - unless you're Hotmail or one of the big companies with an IIS Internet facing web server, you're internal WebServer (or SharePoint server) is highly unlikely to become a wide open source of information about your boardroom activities.

There are many, many, many SharePoint installations where there is no-one who understands the underlying ASP.NET framework and best practices and misleading information like this will only lead to administrators who do not understand the underlying ASP.NET framework to making rash decisions.

As for the guy who said anyone having the default error on a production server should be fired - not everyone is an ASP.NET guru and nor should they need to be. Do you for example know exactly how the underlying x64 instruction set used in the CPU works ? No, well there's a surprise. Products built ontop of other frameworks have administrators that understand that level of the stack. It's arrogant in the extreme to pick fault with them for not knowing every layer in the stack intimately.

To the person who was concerned about exposing connection strings in the web.config - I really hope you have a firewall with atleast a basic sensible policy between the Internet and your backend data servers, in which case, so what, really ... even with your connection string, they're not going to be able to connect to your web server.

</rant>

So what's the real solution in all of this ?

No, it's not even "MS should produce perfect code that has no vulnerabilities" as that is as equally an impossible state to reach as the expectation that every administrator knows each level of the stack intimately well.

Multiple layers of security. In this case, any decent Intrusion Detection Products or Firewalls with IDS capabilities, should be able to spot a deluge of requests targetting your webserver, flag up to you that you are under attack and take preventative actions for you. I don't work in IDS sales, but I wish I did - now would be a great time to be able to sell a few more boxes !

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 2:08 PM by Rob

1. MVC is obviously affected by oracle padding, but is MVC also affected by "polluted ViewState allows downloading any file" as MVC doesn't have ViewState, or does it process inbound ViewState in spite of not producing any?

2. Why is it recommended to not have a different 404 page from the generic, every-error ResponseRewritten error page?

3. Can one configure the ViewState encryption algorithm to use something besides AES?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 2:11 PM by Mike W

In MVC, would overriding the OnException in the Mvc.Controller take care of this problem as long as one error page is still served?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 2:12 PM by frank-s

Hi Scott,

running the script throws following error on my Win2k8 R2 server: Could not find IIS ADSI object. Make sure you have IIS and IIS6 management compatibility installed.

Sure, I am understanding the error message but does the script really need the component installed? That would mean we have to make a change to our IIS install which is not the first choice. That's why I am asking you for an alternative.

Any thoughts?

Thanks and regards

Frank

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 2:46 PM by Rinat Abdullin

How does custom errors setting prevent the exploit? Can't you still measure the average execution time and figure out how far did request go in the pipeline?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 3:25 PM by Tom Resing

@Scott do you have a SharePoint workaround? I don't think this one will work.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 3:34 PM by Jim Kennelly

How about a visual studio patch so new websites' web.config is setup properly with error.htm and random wait.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 3:51 PM by ScottGu

@Anon2010,

>>>>>>>> I don't have a <customErrors> element declared in my web.config, I have instead an IHttpModule inside the <modules> section. This module logs the error and redirects to either a search page (for 404's) or to an error page (for 500's). Am I vulnerable?

I would recommend temporarily updating the module to always redirect to the search page.  One of the ways this attack works is that looks for differentiation between 404s and 500 errors.  Always returning the same HTTP code and sending them to the same place is one way to help block it.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior).  But for right now I'd recommend not differentiating between 404s and 500s to clients.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 3:58 PM by ScottGu

@Barry,

>>>>>>>>> Unless I'm sorely mistaken, random waits will do nothing to fix this, just slow down the attacker somewhat, or force him to use more machines. Random waits average to a constant wait; there's already random latency in the network traffic.

We believe they actually do make a difference with the attack (and don't just slow the attack down).  A key part of the the attack vector shown is being able to distinguish between successful 404 responses for certain files and 500 responses using an ASP.NET feature.  If you enable the above workaround you send the same request content back for each type of error - which means you can't distinguish based on response payload.  The total time spent on the server with these requests is very small.  Adding the random wait adds to the random latency in the network traffic and we believe adds additional help in avoiding someone trying to use timings to guess the cause.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 3:58 PM by ScottGu

@Anthony,

>>>>>>>I have my own error module I use to return different error pages. Am I effected?

I would recommend temporarily updating the module to always redirect to the search page.  One of the ways this attack works is that looks for differentiation between 404s and 500 errors.  Always returning the same HTTP code and sending them to the same place is one way to help block it.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior).  But for right now I'd recommend not differentiating between 404s and 500s to clients.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:00 PM by ScottGu

@jangwenyi

>>>>>>> This is serious I think and we need to apply the workaround as recommended.

Yes - please do apply the workaround.

>>>>>>> I have encrypted my sensitive sections of the web.config, such as connection strings. Should I be worried?

Encrypting your connection strings has always been our recommended best practice - and prevents someone from identifying them if the web.config file is compromised.   Having said that, you want defense in depth and so do not want the web.config file ever exposed.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:00 PM by ScottGu

@Vijay,

>>>>>>> Will the ASP.NET MVC too get affected?

Yes - all versions of ASP.NET are affected, including ASP.NET MVC.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:04 PM by ScottGu

@TheJet,

>>>>>>>>> How does this allow exposure of web.config?  This seems to enable decrypting of ViewState only, is there another related vulnerability that also allows the information disclosure?  Is there a whitepaper that details the attack for a better explanation of what's going on?

The attack that was shown in the public relies on a feature in ASP.NET that allows files (typically javascript and css) to be downloaded, and which is secured with a key that is sent as part of the request. Unfortunately if you are able to forge a key you can use this feature to download the web.config file of an application (but not files outside of the application).  We will obviously release a patch for this - until then the above workaround closes the attack vector.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:05 PM by ScottGu

@Steve,

>>>>>>> I take it we can still have a custom 404 page defined in addition to the default redirect on error, without violating the principles described above?

No - until we release a patch for the real fix, we recommend the above workaround which homogenizes all errors.  One of the ways this attack works is that looks for differentiation between 404s and 500 errors.  Always returning the same HTTP code and sending them to the same place is one way to help block it.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior).  But for right now you should not differentiate between 404s and 500s to clients.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:06 PM by ScottGu

@Steve,

>>>>>> When it says no sub elements for errors should be defined, does this even include 404 errors?  i.e. Should I change this to

>>>>>> <customErrors mode="RemoteOnly" defaultRedirect="/Not-Found/" />

Yes - you should not have a 404 sub element.  Instead redirect everyone to /Not-Found.  This is a temporary workaround that closes the public attack vector - once we release a patch you can revert back to the behavior where your error pages are different.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:07 PM by ScottGu

@Demis,

>>>>> Is this a fundamental flaw in ASP.NET or just .NET's implementation of it? I.e. Will this affect mono ASP.NET web applications as well?

This vulnerability is in our ASP.NET implementation (and will be fixed in a patch).  I'm not sure if Mono has the same bug.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:09 PM by ScottGu

@granicz,

>>>>>>>> Does the vulnerability only affect resources accessible via ASPX pages?  Or do we also need to make changes to the custom error pages in IIS?

This vulnerability impacts ASP.NET resources (not just ASPX pages).  You shouldn't need to make any changes to the custom error pages of IIS.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:25 PM by doggy8088

The DetectCustomErrorsDisabled3.vbs VBScript looks like scan all of the web.config in all folders and sub-folders that all registered in IIS websites.  Most of the web.config under sub-folder may not need to assign a <customError> section on it.  Do you notice this problem?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:30 PM by James Martin

I am under the impression that this vulnerability does not require an error page or even a status code to function correctly. Posts from the researchers behind this on twitter seem to indicate that timing differences alone are enough. This would seem to indicate the <customErrors> advice does not solve the problem.

Am I missing something?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:43 PM by ScottGu

@Peter,

>>>>>> How is it possible to read the entire web.config just by decyphering what's in the viewstate? I understand that someone could put certain parts of it into the viewstate but you say this attack allows them to download the entire web.config? How can this happen in a REST environment?

The attack vector that was demonstrated publicly (which downloads the web.config file) uses a built-in feature of ASP.NET and is independent of viewstate.  

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:44 PM by ScottGu

@Paco,

>>>>>>> Do we have to keep using a workaround in the future or will microsoft create a solution for this?

The workaround is only a temporary suggestion - we will patch the vulnerability itself at which point it isn't required.  We published the workaround because of worries that someone might try to exploit this before a patch is available.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:52 PM by Joakim E

Does this also allow the decryption of the Session and Forms cookies? If so it would be completely devastating. View state is bad enough but if you can view and alter the session and forms cookies at will you can become any user on the site.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 4:56 PM by ScottGu

@Mike,

>>>>>>>> Wow.  This is kind of a big one -- kudos to the ASP.NET team for such a quick response.  Does the vulnerability only extend to a particular site?  For example, if I am hosting 20 sites and 8 of them are patched, are those 8 vulnerable because the other 12 are not patched?

At this point I'd err on the side of caution and patch all 20 of the sites.

>>>>>>>> Can you provide an ETA on when the patch will be available?

We are working on a patch now.  The workaround above is what we recommend now until we have that available.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:00 PM by ScottGu

@Ken,

>>>>>>>> first - it is great that you guys are pushing a workaround as fast as possible. As for the workaround itself - this is rather problematic. And by "this" I refer to "using the exact same error page, and exact same status codes" consider these two scenarios:  1. an e-commerce site. A url of a missing product should render a 404, probably with a custom message suggesting the user to keep browsing for other things 2. a site serving an API, where the clients depends on exact error messages  Is there any better workaround for the exploit?

When we issue a patch the workaround won't be required.  The workaround right now is a temporary one that can be used until the patch is available to prevent the attack that has been publicly demonstrated.  

Until the patch is available we recommend sending back consistent error messages - since the public attack relies on non-homogeneous responses to 404 and 500 error situations.  

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:00 PM by ScottGu

@David,

>>>>>>> Thanks for the tip- I'm assuming this affects DotNetNuke sites as well?

Yes - this affects DotNetNuke sites as well.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:02 PM by ScottGu

@Brock,

>>>>>>>> Just wonder, for 3.5 sites and below, does the generic error page have to be html? Or can it be aspx, ie code, masterpage. Cheers

Yes - you can point to a .aspx page as well.  For .NET 3.5 and below it will do a client-side redirect to whatever URL you send it.  .NET 3.5 SP1 added support so that you can also just send back HTML (and not change the URL) which a lot of people prefer since if end-users hit refresh again it will not simply reload the error page.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:02 PM by ScottGu

@TaoYang,

>>>>>>> Thank you for the information! will it also affect ASP.NET MVC? ASP.NET MVC doesn't have viewstate that need to be encrypted.

Yes - this also impacts ASP.NET MVC.  The public attack is not actually through ViewState but rather via a built-in feature of ASP.NET that is enabled for all ASP.NET application types.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:07 PM by ScottGu

@Ken,

>>>>>>> can't use status code error pages anymore!? well that sucks

Once a real patch is available for the workaround you can return to use status error codes for custom pages. Until then you should use the above workaround.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:08 PM by ScottGu

@Marik,

>>>>>>>> Download the web.config file?!! Why do not fix this issue in the ASP.NET framework and release it through Windows Update ASAP? We have custom logic in the global.asax on the Application_Error event, and after that we displays two types of error pages without any specific error information. Does it help? We cannot change application's logic right now because of very serious bug in the ASP.NET framework.

We will patch the vulnerability itself in ASP.NET - at which point the workaround isn't required.  We published the workaround because of worries that someone might try to exploit this before a patch is available.  

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:10 PM by ScottGu

@Jim,

>>>>>>>> If a site is using Windows authentication (Basic or Integrated), as opposed to Forms Authentication, is it still vulnerable?

Yes.  The attack that was covered at a security conference yesterday did not use either Forms Authentication or ViewState as the attack vector.

Even if you use Windows Authentication you should apply the workaround.  Once a patch to fix the vulnerability is available then the workaround will no longer be required.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:10 PM by ScottGu

@dotnetguts,

>>>>>>>>>> I have a asp.net website on shared web hosting.  How can i run the script to verify things are good?

You can't run a script remotely - but you can open your site's web.config file and update the <customErrors> section within it using the steps above.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:12 PM by ScottGu

@Nitan,

>>>>>>>>> Is the httpErrors tag in system.webserver also affected?

I do not believe so.

>>>>>>>>> What if we're using Application_Error in global.asa to handle all the errors ourselves (via Server.ClearError -> Server.Transfer)?

I would recommend temporarily updating the code to always send consistent content back for errors.  One of the ways this attack works is that looks for differentiation between 404s and 500 errors.  Always returning the same HTTP code and sending them to the same place is one way to help block it.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior).  But for right now I'd recommend not differentiating between 404s and 500s to clients.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:13 PM by ScottGu

@Adeel,

>>>>>>>> Is asp.net mvc 2 is also vulnerable for this attack?

Yes - you should apply the above workaround for ASP.NET MVC 2 sites as well.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:15 PM by ScottGu

@Brian,

>>>>>>> Can you please provide details on why you can't have sub error elements?  I've taken a look at the details of this vulnerability and from I understood the encryption padding attack needs to be able to differentiate between two different exceptions.

One of the ways this attack works is that looks for differentiation between 404s and 500 errors. It can use this differentiation to try out potential keys (typically over tens of thousands of requests). Always returning the same HTTP code and sending them to the same place is one way to help block it.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior).  But for right now I'd recommend not differentiating between 404s and 500s to clients.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:16 PM by ScottGu

@Johnny O,

>>>>>>> Scott, this is really unfortunate.  We have 2 error pages.  One for 404 (page not found) and one for everything else.  404 errors should give a properly descriptive message to the user, so having to send users to same error page for ALL errors results in poor user experience.

We will patch the vulnerability itself in ASP.NET - at which point the workaround isn't required.  We published the workaround because of worries that someone might try to exploit this before a patch is available.  

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:18 PM by ScottGu

@Phill,

>>>>>>> I get this running it on Windows Server 2008 with IIS7? Do I REALLY need to install the IIS6 management compatibility stuff just to run this?

Our current script does require that - since we wanted the script to work on all versions of IIS (and that is the only API that enables is).  We had to develop the script quickly which is why we haven't been able to build and test separate scripts for different versions.  We have had good success with people running the script across many thousands of sites, though, so if you can (even if temporarily) enable the IIS6 compat mode and run the script you should get good results from it.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:25 PM by Josh Pearce

Scott,

What is the mechanism which prevent *.config files from being downloaded out of the box? I assume it's some kind of baked-in disallow handler? Exploiting an AES vulnerability is one thing, but why on earth is there any facility for downloading arbitrary files?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:25 PM by Peter

Hi Scott,

Can you give us an estimate on the patch? (hours, days, weeks?)

Thanks for the quick responses.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 5:27 PM by Martin Aatmaa

Hi Scott,

I'm still not clear how this affects ASP.NET MVC in particular. With MVC, we have the option (via routing) to send any request not matching a route to a 404 page. Additionally, we have the option to catch any execution exception via the [HandleError] attribute and show a 500 page.

In both cases, the ASP.NET custom error pages are not used.

So, an MVC app will still show different output for a 404 or 500, irrespective of the ASP.NET web.config customErrors configuration.

Any clarification would be greatly appreciated.

Thank you!

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:21 PM by ScottGu

@Lee,

>>>>>>>> Scott, I'm confused. So it’s not just that we should deliver the same page (content) for all content, we should also deliver the same HTTP status code?  If so, which status code?  Further, if so, this is going to cause search engine indexing issues.  If a request comes in for a resource that no longer exists, I need to return a 404 to search bots.  Please clarify.

One of the ways this attack works is that looks for differentiation between 404s and 500 errors. It can use this differentiation to try out potential keys (typically over tens of thousands of requests). Always returning the same HTTP code and sending them to the same place is one way to help block it.  Note that one way to solve it would be to always return a 404 error page - in which case your search scenario should still be ok.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior).  But for right now the best way to close this attack vector is to not differentiate between 404s and 500s to clients.

Hope this helps,

Scot

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:22 PM by ScottGu

@Evan,

>>>>>>>> Why Custom Errors?  Why not just flip the encryption method from AES to 3DES in the config?

This particular attack vector isn't closed by that.  The workaround above is our recommended approach and prevents it.  We'll then fix the root issue in a patch.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:24 PM by ScottGu

@Michael,

>>>>>>> What is the timeline on release of a patch?

We did not receive advance disclosure of the issue, so do not have a patch available yet.  We are working hard on one though. There are lots of different platform matrixes and localization languages to build/test/verify which is why producing a patch with high confidence enough to deploy automatically across millions of machines takes a bit of time to get right.  In the meantime we published the above workaround to prevent attacks using the attack approach discussed publicly yesterday.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:25 PM by ScottGu

@Drew,

>>>>>>>> What about sites that use classic ASP only, and not coded in .NET? Any exposure there?

This vulnerability is ASP.NET based.  

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:31 PM by ScottGu

@Martin,

>>>>>>>>> More information would be appreciated. In particular, whether we can continue to distinguish between 400 and 500 error types. If not, that's a significant regression in required functionality.

One of the ways this attack works is that it looks for differentiation between 404s and 500 errors. It can use this differentiation to try out potential keys (typically over tens of thousands of requests). Always returning the same HTTP code and error page is one way to help block it.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior).  But for right now I'd recommend not differentiating between 404s and 500s to clients.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:33 PM by ScottGu

@Dino,

>>>>>>> Really appreciate the heads up! Do IIS errors need to be configured also vs. ASP.NET errors? e.g. on a SharePoint 2010 install I'm looking at I note that the 404 error comes from the IIS config, not the ASP.NET customErrors.

You shouldn't need to change any configuration within IIS.  Instead you want to configure things using the ASP.NET customErrors.

>>>>>>> Also, is a hotfix imminent for the likes of Outlook Web Access and Communicator Web Access, or should we apply the workaround to these services manually?

We are going to release a patch for ASP.NET that fixes the root issue - at which point all applications built on top of ASP.NET will be ok.  The workaround above is a temporary solution until that patch is available.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:37 PM by ScottGu

@Rob,

>>>>>>>1. MVC is obviously affected by oracle padding, but is MVC also affected by "polluted ViewState allows downloading any file" as MVC doesn't have ViewState, or does it process inbound ViewState in spite of not producing any?

MVC is not impacted by ViewState padding.  However, the attack vector that the above workaround is designed to prevent does not involve ViewState - and instead worksaround an issue with a built-in ASP.NET feature that is enabled by default on both Web Forms and MVC applications.  So you should apply it to MVC applications as well.

>>>>>>>> 2. Why is it recommended to not have a different 404 page from the generic, every-error ResponseRewritten error page?

One of the ways this attack works is that it looks for differentiation between 404s and 500 errors. It can use this differentiation to try out potential keys (typically over tens of thousands of requests). Always returning the same HTTP code and error page is one way to help block it.  Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior).  But for right now I'd recommend not differentiating between 404s and 500s to clients.

>>>>>>>>> 3. Can one configure the ViewState encryption algorithm to use something besides AES?

You can, although that is independent of the above workaround.  Doing that won't fix the issue being addressed above.  

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:38 PM by ScottGu

@Mike,

>>>>>>>>> In MVC, would overriding the OnException in the Mvc.Controller take care of this problem as long as one error page is still served?

I'd recommend implementing the above workaround using <customErrors>.  This will handle exceptions that are raised by built-in ASP.NET features (which is the cause of the above vulnerability).  If your app code in a controller is handling an internal exception it is probably ok.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:39 PM by ScottGu

@Frank,

>>>>>>>running the script throws following error on my Win2k8 R2 server: Could not find IIS ADSI object. Make sure you have IIS and IIS6 management compatibility installed.  Sure, I am understanding the error message but does the script really need the component installed? That would mean we have to make a change to our IIS install which is not the first choice. That's why I am asking you for an alternative.

Our current script does require that - since we wanted the script to work on all versions of IIS (and that is the only API that enables is).  We had to develop the script quickly last night which is why we haven't been able to build and test separate scripts for different versions.  We have had good success with people running the script across many thousands of sites, though, so if you can (even if temporarily) enable the IIS6 compat mode and run the script you should get good results from it.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:41 PM by ScottGu

@Rinat,

>>>>>>> How does custom errors setting prevent the exploit? Can't you still measure the average execution time and figure out how far did request go in the pipeline?

One of the ways this attack works is that it looks for differentiation between 404s and 500 errors. It can use this differentiation to try out potential keys (typically over tens of thousands of requests). Always returning the same HTTP code and error page is one way to help block it.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:42 PM by ScottGu

@Jim,

>>>>>>> How about a visual studio patch so new websites' web.config is setup properly with error.htm and random wait.

We are going to be patching the vulnerability in ASP.NET - at which point the above workaround will not be required.  We released the workaround last night because an attack vector using it was discussed publicly, and this provides the best way for customers to prevent it immediately.

Once the official patch is available the above workaround will no longer be required.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:43 PM by ScottGu

@Tom,

>>>>>>> @Scott do you have a SharePoint workaround? I don't think this one will work.

I believe the above workaround should work.  If you are having problems send me email (scottgu@microsoft.com) and we can help.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:44 PM by ScottGu

@doggy8088,

>>>>>>>> The DetectCustomErrorsDisabled3.vbs VBScript looks like scan all of the web.config in all folders and sub-folders that all registered in IIS websites.  Most of the web.config under sub-folder may not need to assign a <customError> section on it.  Do you notice this problem?

I believe the script will handle this correctly assuming a parent folder has the <customErrors> section defined correctly within it.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:48 PM by ScottGu

@James,

>>>>>>>> I am under the impression that this vulnerability does not require an error page or even a status code to function correctly. Posts from the researchers behind this on twitter seem to indicate that timing differences alone are enough. This would seem to indicate the <customErrors> advice does not solve the problem.  Am I missing something?

From the data we've seen we believe the above workaround addresses the current attack vector being discussed.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:50 PM by ScottGu

@Joakim,

>>>>>>>Does this also allow the decryption of the Session and Forms cookies? If so it would be completely devastating. View state is bad enough but if you can view and alter the session and forms cookies at will you can become any user on the site.

The SessionID is tracked as a client-side, with the session data stored on the server.  This attack does not allow you to get access to that.  Forms cookies are typically encrypted cookies.  We do not currently know of an exploit that allows someone to forge one.

The risk from the attack vector being discussed is that someone obtains the web.config file of an application, and in turn obtains sensitive data from it.  That is the scenario we are trying to make sure is avoided with the above workaround.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:53 PM by ScottGu

@Josh,

>>>>>>> What is the mechanism which prevent *.config files from being downloaded out of the box? I assume it's some kind of baked-in disallow handler? Exploiting an AES vulnerability is one thing, but why on earth is there any facility for downloading arbitrary files?

This particular attack vector uses a few things that unfortunately align to enable that. If it can identify a oracle padding key, it then forges a request with a key that can allow some files within an application vroot to be downloaded.

We believe the workaround above can be used to prevent this from happening while we get a patch that fixes the root issue in ASP.NET ready.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 6:54 PM by ScottGu

@Peter,

>>>>>>>> Can you give us an estimate on the patch? (hours, days, weeks?)

We did not receive advance disclosure of yesterday's report, so do not have a patch available yet.  We are working hard on one though. There are lots of different platform matrixes and localization languages to build/test/verify which is why producing a patch with high confidence enough to deploy automatically across millions of machines takes a bit of time to get right.  In the meantime we published the above workaround to prevent attacks using the attack approach discussed publicly yesterday.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 7:03 PM by ScottGu

@Martin,

>>>>>>>>>I'm still not clear how this affects ASP.NET MVC in particular. With MVC, we have the option (via routing) to send any request not matching a route to a 404 page. Additionally, we have the option to catch any execution exception via the [HandleError] attribute and show a 500 page.  In both cases, the ASP.NET custom error pages are not used.  So, an MVC app will still show different output for a 404 or 500, irrespective of the ASP.NET web.config customErrors configuration.  Any clarification would be greatly appreciated.

You should still apply the <customErrors> workaround above to your MVC application - as that will handle errors not handled by your MVC app itself.  This includes errors for built-in ASP.NET features (which is the current attack vector being discussed).

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 7:10 PM by Yann

Scott,

What I understand is that the attack use WebResource.axd to know if the sent encrypted message is valid (and in this case it sends a 404) or invalid (padding issue and in this case it send a 505) ? Is that right ?

In that case wouldn't it be better for asp .net MVC user to remove WebResource.axd from the web.config file ?

You said in a response to comments that you don't think that the hacker can forge a cookie, but in the POET vs Asp .Net video, we can cleary see that he creates an authentification cookie. Can you explain that ?

Thanks,

--

Yann

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 7:44 PM by spongman

this is a disaster for REST/AJAX services that depend on HTTP response codes.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:08 PM by Lynn Eriksen

Scott, are you protected if you have [deployment retail="true"/] in the machine.config?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:13 PM by Marik

Thanks for the answer but I wanna to add just few other comments - I do not care about ViewState, Session, Cookies etc., because  our applications do not store any important data in those storages, but downloading of web.config (there are often not just a connection strings, but SMTP accounts etc.) is not just a bug, it is serious mistake of the framework's architecture, and I want to know - who is responsible from Microsoft's side for this big issue?! And one more comment - do you understand that this post is not reading by a good guys only, but bad too? You wrote to many details, and this is also not very good, it was better to find how to fix it ASAP and release appropriate update without any comments (I think that not many companies will use your fix in the near future, maybe I'm wrong, sorry in this case)...

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:25 PM by lynn eriksen

Scott, are you safe if you have set retail = "true" on the deployment tag under machine.config?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 8:42 PM by Mat

I'm a little curious why you think changing the error pages will matter.  You say that the attack works by exploiting the differentiation between 404 and 500 errors.  Wouldn't changing the error page be defeated by the fact that the HTTP response would have the header "HTTP/1.1 500 Internal Server Error" despite it returing the 404 page?

And for REST services, would it suffice to simply remove the handler mapping for .axd rather than doing the whole custom error shebang (at least, I'm assuming this exploit relies on WebResource.axd or ScriptResource.axd?)

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 9:35 PM by effun

My application handles errors in a custom IHttpModule rather than <customError>, and displays them by redirecting to a custome .ASPX page using Server.Transfer. Will this affected by the vulnerability?

Thanks a lot.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:24 PM by Rick

We don't use WebResource.axd (or any of the controls which rely on it).  We tend to focus on emitting our own HTML and JS - we use Repeaters and ListViews and handwritten JS and the like instead.  If that is in fact the root of the problem, would it close the loop to just remove it for our sites?  That would be preferred over sending back incorrect status codes, which can screw up search engine rankings and confuse end users.

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 10:32 PM by Douglas McClean

Scott,

Could you say more about this built-in ASP.net feature that allows downloading the web.config file? What feature? Are you planning to remove it entirely? If not, is there a configuration setting in ASP.net or IIS that allows disabling it? What other files does it allow access to alongside the normal request pipeline?

# re: Important: ASP.NET Security Vulnerability

Saturday, September 18, 2010 11:56 PM by pbz

Scott, is it possible that after N bad requests to somehow refresh the key? It's possible that I'm not understanding the problem correctly, but what if we could regenerate the key they're after? This way they would have to start over... Thanks.

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 12:06 AM by Suprotim Agarwal

For devs trying to determine if ASP.NET 3.5 SP1 is installed

stackoverflow.com/.../how-do-i-tell-if-net-3-5-sp1-is-installed

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 1:33 AM by saikatbiswas82

Hi Scott,

Is it possible to configure the error.aspx page in global.ascx instead of web.config in order to avoid this threat?

-Thanks,

Saikat

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 2:05 AM by Atanas Korchev

Are WebResource.axd and ScriptResource.axd the only exploitable files? If yes, perhaps removing those HTTP handlers would be sufficient. Unfortunately this will only work in ASP.NET MVC applications which hardly ever rely on embedded web resources.

I just tested in a vanilla ASP.NET MVC 2 application and by removing Web/ScriptResource.axd all requests to the same return 404. This is without touching <customErrors />. Is this enough to mitigate the security thread?

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 2:10 AM by JeffS

Good morning Scott,

No matter what I do I cannot get 404 errors to redirect to my generic error page. I always get the genertic IIS7 error 404 message instead. I have followed your guidance and have been at it for a few hours now without any luck.

The site I'm working on now uses Forms authentication and if I login then try to get to a page that is on the root of the site that does not exist I get sent to the generic error page just fine. The trouble comes when I test for an invalid url to a resource that is off the root of the site like a document. It's here that I see the standard IIS7 404 message.

Any advice would be greatly appreciated.

See you at MIX in Vegas next year,

JeffS

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 5:56 AM by Pazu

1) I have no idea, whether sesitive info is in ViewState or web.config for CRM

2) I have no idea, if I can safely change web.config (which is completeley "unsupported" operation

BTW: this confirms my old practice - nothing sesitive in web.config at all - only integrated security, nothing sesitive in viewstate - only hashcodes like sessionid, if any.

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 6:17 AM by Mihailik

What the heck are you doing with that IDisposable?

RNGCSP is Disposable, there is no 'if'!

Whom did you hire to write that code???

Additionally, you don't want to keep an instance of RNGCSP alive for too long. As soon as it's done with generating it should be disposed.

Handling errors is not a place for slacking, the system is likely to already be under the stress. In these critical conditions using 'smart' code for no reason is a crime. Holding resources for too long is a crime.

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 6:19 AM by Pazu

On Rizzos post he writes: "POET is the free tool that we released a few months ago which can automatically find and exploit Padding Oracle vulnerabilities in web applications."

Their whitepaper is from 25-MAY-2010.

So doing a buzz now is a bit late. Somebody in MS missed the train ?

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 8:55 AM by EvereQ

It seems small typo here: 'RemoteOnly' should be instead of 'remoteOnly' in

"you can try setting <customErrors mode=”remoteOnly”/> – which will enable you to see the error message if you are connecting to the site from a local browser".

Btw, can we made code in C# version (for random delay) a bit less "tricky" in .NET 4.0:

I.e. instead of

  void Page_Load() {

     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(); }

   }

to be just:

  void Page_Load() {      

     var delay = new byte[1];      

     using (var prng = new RNGCryptoServiceProvider())      

         prng.GetBytes(delay);        

     Thread.Sleep(delay[0]);

   }

The only issue I see with such code (same like with code from your post) is that random delay limited to only 256 possible different values (from 0 to 255 milliseconds) and more so value 0 will not have any effect! Are you absolutely sure that such small range can really made hacker life _significantly_ worse? ;-)

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 9:17 AM by Venemo

@Scott, if I have customErrors enabled, and I also have defaultRedirect, does it hurt if I have a specific error page for HTTP 404, too? (And all other errors go tho the default redirect.)

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 10:10 AM by Rather Not Say

How is it possible to detect if the Web.Config has been read remotely?  Will this download appear in the IIS logs?

How can we tell if the vulnerability has been exploited?  Aside from extra thousands of junk requests showing that an attack is underway.

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 12:05 PM by Ron Pender

Hi Scott,

I first tried the workaround using the method for 3.5 SP1 and it didn't work. I then changed it to the method for 3.5 (no sp) and it worked. But, I'm certain I'm building with 3.5 SP1. I see this clearly in the about dialog of Visual Studio. Does the the difference between SP1 and not SP1 have to do with the server? I thought if the application is built for 3.5 SP1 then it must be run as that because otherwise the DLLs are incompatible. Can you explain? Thanks.

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 1:20 PM by Eric

Scott - do we need to change the default IIS static error pages to all map to the error.aspx file too?  

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 3:30 PM by rob33n

Thanks for post. I will do custom errors on.

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 4:25 PM by Matt

We have a few customerrors defined for sites using location tags and that the information is kept in apphost.config.

Using the vb detection script we scanned a applications on a test server and most came back as vulnerable. We then added a customerrors tag to the web.config of each application with a defaultRedirect and the detection tool came back as OK.

It my understanding that to mitigate the risk all customerrors must point to a single file. If this is the case the tool didn't appear to take into account the customerrors we had specified using location tags? If it did then I would have expected the tool to show the sites as still vulnerable?

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 5:01 PM by Eray Aydoğdu

hi,

i have so much asp.net application on running. These apps really important for my customers. But i cant spend my time for this. How can i do one treatment with each other. Can hosting  campany do anything ?

-Thanks

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 7:18 PM by ijobatua

В конце августа на просторах сети интернет стартовал новый уникальный проект – «Заработок в интернете от А до Я» http://ijob.at.ua.  В современных условиях развития интернета,  а так же в условиях экономического кризиса, нестабильности, становится всё более популярным работа в сети интернет.  

Ежедневно растущее количество пользователей и желающих зарабатывать в сети интернет  обусловило потребность в создании ресурсов, при помощи которых даже новички в этом бизнесе смогут разобраться, как же на самом деле зарабатываются деньги в сети интернет. Стало появляться множество сайтов, предлагающих работу в интернете, но в узком сегменте, интересном владельцам сайтов (например, с целью наработки рефералов для определенного проекта), рассматривая возможность заработка в интернете именно в этом ключе. Проект  Заработок в интернете от А до Я является объективным информационным справочником по всем видам заработка в интернете, регулярно пополняется и обновляется. Также тут предоставлены необходимые инструменты.

 Как комментирует свое открытие коммерческий директор Заработок в интернете от А до Я Лазуренко Андрей, данный информационный справочник является на сегодняшний день наиболее объективным ресурсом, позволяющим любой прослойке пользователей сети интернет избежать ошибок, не попасть на мошенников и найти свою нишу на просторах рунета. Благодаря такого рода деятельности каждый человек может самостоятельно регулировать свой уровень дохода, при этом работая в комфортных условиях у себя дома, экономя время и деньги на поездках на работу и т.д.

 Еще следует отметить, что одним из больших преимуществ заработка в интернете является отсутствие притеснений, выговоров и т.д. со стороны руководства – человек, работающий в интернете, сам себе руководитель.

 Широкая электронная база и постоянно увеличивающийся список проверенных ресурсов (включяя партнерские программы, фриланс-биржи и т.д.), а так же постоянно обновляющийся раздел о мошенничестве в интернете, позволяют максимально обезопасить пользователей проекта Заработок в интернете от А до Я.

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 7:48 PM by William

I am glad that you provided this quick solution and are working on a real fix to the root of the problem.

However, I work very hard to make sure all my ASP.Net sites are as secure as possible and I feel rather let down of this big one that is outside of my control.

After reading nearly every comment on this site and watching the attack video, I am really confused on how it actually works - I have read your "it can tell the difference between 400 and 500" comment numerous times, but I still do not really understand.

I appreciate the need for secrecy before a patch is released, but, will it be possible to release further details when it is all dealt with as to more of the background of this attack? To be honest, without something like this, I do not see my faith of ASP.Net returning any time soon.

Lastly, I have read about the feature of ASP.Net that is used to return the web.config or other files is a new-ish feature. I always use the latest version of ASP.Net - but in all honesty, I only do it because I can. I don't really use many components that were not used in version 2, how can I tell if I actually need this component and is there anyway to turn it off?

Thanks

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 10:40 PM by Daniel Archer

Is the attack only limited to the web.config file?  We store all our settings in seperate files outside the web.config like:

<smtp configSource="Config\MailSettings.config"></smtp>

Would an attacker have any access to these files if they know the path?

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 10:56 PM by Erdnando

Thanks.  I'll checkit.   These monday will release in production

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 11:21 PM by Sandun

As I think this issue should fix from the cryptography area of the ASP.net, but configuring the customError section in the web.config is a temporary fix. Isn't it ? Correct me if I'm wrong... :)

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 11:53 PM by ScottGu

@Yann,

>>>>>>>>> In that case wouldn't it be better for asp .net MVC user to remove WebResource.axd from the web.config file ?

If you are not using the WebResources.axd or ScriptResources.axd features then I would recommend removing them.

>>>>>>>>> You said in a response to comments that you don't think that the hacker can forge a cookie, but in the POET vs Asp .Net video, we can cleary see that he creates an authentification cookie. Can you explain that ?

The issue in the video was that he downloaded the web.config file - and included in the DNN web.config file is the machinekey value.  This can be used to generate authentication tickets.  Note that by default web.config files in ASP.NET don't include the machinekey value - so by default this would not be possible if the web.config file was downloaded (although the web.config file might still have other private data in it).

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Sunday, September 19, 2010 11:58 PM by ScottGu

@Lynn,

>>>>>>>> Scott, are you protected if you have [deployment retail="true"/] in the machine.config?

That will turn on customerrors - but not set the defaultRedirect property.  You'll still want to enable that in the app's web.config file using the above workaround.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:01 AM by ScottGu

@Marik,

>>>>>>> Thanks for the answer but I wanna to add just few other comments - I do not care about ViewState, Session, Cookies etc., because  our applications do not store any important data in those storages, but downloading of web.config (there are often not just a connection strings, but SMTP accounts etc.) is not just a bug, it is serious mistake of the framework's architecture, and I want to know - who is responsible from Microsoft's side for this big issue?! And one more comment - do you understand that this post is not reading by a good guys only, but bad too? You wrote to many details, and this is also not very good, it was better to find how to fix it ASAP and release appropriate update without any comments (I think that not many companies will use your fix in the near future, maybe I'm wrong, sorry in this case)...

This is definitely not intended behavior.  We are working to fix it in a security update.

In general when security issues occur and are public exploits our policy is to be open to customers about the issue and especially about how to protect themselves from it until a patch is available.  Malicious attackers will be able to find out the information from the public exploit information regardless.  Providing clear and open communication to customers helps protect them and does not disclose any new meaningful data to attackers.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:02 AM by ScottGu

@Mat,

>>>>>>>> I'm a little curious why you think changing the error pages will matter.  You say that the attack works by exploiting the differentiation between 404 and 500 errors.  Wouldn't changing the error page be defeated by the fact that the HTTP response would have the header "HTTP/1.1 500 Internal Server Error" despite it returing the 404 page?

When you enable <customErrors> within ASP.NET you'll send back 200 error responses if you use the defaultRedirect attribute.  This will not allow remote users to be able to determine the original HTTP error code or exception details.

>>>>>>>> And for REST services, would it suffice to simply remove the handler mapping for .axd rather than doing the whole custom error shebang (at least, I'm assuming this exploit relies on WebResource.axd or ScriptResource.axd?)

Yes - If you are not using WebResource.axd or ScriptResource.axd you can and should remove them from your local web.config file.  

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:06 AM by ScottGu

@effun,

>>>>>>> My application handles errors in a custom IHttpModule rather than <customError>, and displays them by redirecting to a custome .ASPX page using Server.Transfer. Will this affected by the vulnerability?

I would recommend temporarily updating the module to always redirect to the search page.  One of the ways this attack works is that looks for differentiation between 404s and 500 errors.  Always returning the same HTTP code and sending them to the same place is one way to help block it.

Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior).  But for right now I'd recommend not differentiating between 404s and 500s to clients.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:07 AM by ScottGu

@Rick,

>>>>>>>> We don't use WebResource.axd (or any of the controls which rely on it).  We tend to focus on emitting our own HTML and JS - we use Repeaters and ListViews and handwritten JS and the like instead.  If that is in fact the root of the problem, would it close the loop to just remove it for our sites?  That would be preferred over sending back incorrect status codes, which can screw up search engine rankings and confuse end users.

If you aren't using WebResource.axd and ScriptResource.axd then you can remove them which will also provide a workaround against this particular attack.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:28 AM by Adrian

Is this a bug in the way the padding algorithm is implemented or a bug with the algortihm in general ?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:12 AM by Daniel

Can you please explain how to:

"If you aren't using WebResource.axd and ScriptResource.axd then you can remove them which will also provide a workaround against this particular attack."

remove those, as this is the preferred approach for our MVC apps which don't use those.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:19 AM by ScottGu

@Dino,

>>>>>>>>> We've been able to implement the suggested workaround for a number of "normal" sites - however on one SharePoint 2010 For Internet Sites we see the application.config httpErrors always overriding the customErrors for the likes of 404s - so that the test proposed (mysite.com/pagethatdoesnotexist.aspx) always returns the httpErrors specified pages. As an interim, we've modified httpErrors also to return the same error page for all errors as per customErrors. Will this suffice?

If you can send me email (scottgu@microsoft.com) I can connect you with someone who can help answer this.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:22 AM by SteveW

Scott,

Am I at risk if my site doesn't host any Asp.Net pages, however IIS could still map .aspx requests to the .Net Framework.

Would the error messages returned give sufficient information to an attacker?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:27 AM by ScottGu

@pbz,

>>>>>>>>>>> Scott, is it possible that after N bad requests to somehow refresh the key? It's possible that I'm not understanding the problem correctly, but what if we could regenerate the key they're after? This way they would have to start over... Thanks.

You can't automatically reset keys. Although you could recycle them daily if you wanted to.

Note that the key itself is not disclosed with this attack (unless you store it in the web.config file and it is disclosed).  The oracle padding attack allows you to decrypt information and forge encrypted (but not signed) content through an oracle.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:28 AM by ScottGu

@saikatbiswas82,

>>>>>>> Is it possible to configure the error.aspx page in global.ascx instead of web.config in order to avoid this threat?

The <customErrors> workaround is actually the fix not the threat.  I'd recommend putting it in the web.config file using the instructions above.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:30 AM by ScottGu

@Atanas,

>>>>>>> Are WebResource.axd and ScriptResource.axd the only exploitable files? If yes, perhaps removing those HTTP handlers would be sufficient. Unfortunately this will only work in ASP.NET MVC applications which hardly ever rely on embedded web resources.  I just tested in a vanilla ASP.NET MVC 2 application and by removing Web/ScriptResource.axd all requests to the same return 404. This is without touching <customErrors />. Is this enough to mitigate the security thread?

At this time we are recommending always adding the <customErrors> section with the above workaround to your application.  If you are not using the WebResources.axd and ScriptResources.axd handlers then an additional workaround would be to remove them as well.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:31 AM by ScottGu

@JeffS,

>>>>>>>> No matter what I do I cannot get 404 errors to redirect to my generic error page. I always get the genertic IIS7 error 404 message instead. I have followed your guidance and have been at it for a few hours now without any luck.  The site I'm working on now uses Forms authentication and if I login then try to get to a page that is on the root of the site that does not exist I get sent to the generic error page just fine. The trouble comes when I test for an invalid url to a resource that is off the root of the site like a document. It's here that I see the standard IIS7 404 message.

If you can send me email (scottgu@microsoft.com) with more details we can help you enable this.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:36 AM by ScottGu

@EvereQ,

>>>>>>>> Btw, can we made code in C# version (for random delay) a bit less "tricky" in .NET 4.0:

Fair question - and to to be honest with you I'm not sure (too little sleep to safely do a crypto code review right now <g>).

I'd recommend using the code we provided above for now - since we had a lot of people look closely at it.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:37 AM by ScottGu

@Venemo,

>>>>>>> @Scott, if I have customErrors enabled, and I also have defaultRedirect, does it hurt if I have a specific error page for HTTP 404, too? (And all other errors go tho the default redirect.)

You do not want to have a custom 404 error page - as that allows an attacker to differentiate between error codes and is how the oracle exploit is enabled.  For right now you'll want to return the same error code in all circumstances.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:39 AM by ScottGu

@Rather Not Say,

>>>>>>>> How is it possible to detect if the Web.Config has been read remotely?  Will this download appear in the IIS logs? How can we tell if the vulnerability has been exploited?  Aside from extra thousands of junk requests showing that an attack is underway.

We do not know of anyone who has been attacked with this exploit.

To determine if you might have, you can check your HTTP logs.  Attacks will typically show thousands (or 10s of thousands) of 404 and 500 HTTP requests from a malicious client.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:42 AM by ScottGu

@Ron,

>>>>>>>>> I first tried the workaround using the method for 3.5 SP1 and it didn't work. I then changed it to the method for 3.5 (no sp) and it worked. But, I'm certain I'm building with 3.5 SP1. I see this clearly in the about dialog of Visual Studio. Does the the difference between SP1 and not SP1 have to do with the server? I thought if the application is built for 3.5 SP1 then it must be run as that because otherwise the DLLs are incompatible. Can you explain? Thanks.

Do you have .NET 3.5 on the web-server?  It sounds from your description that you might be building against .NET 3.5 SP1 but deploying onto a .NET 3.5 server.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:43 AM by ScottGu

@Edward,

>>>>>>> Look at the date of this article

Unfortunately details about the specific attack were only revealed Friday afternoon during the talk at the security conference.  

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:43 AM by ScottGu

@Eric,

>>>>>>>> Scott - do we need to change the default IIS static error pages to all map to the error.aspx file too?  

No - you shouldn't need to do this.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:45 AM by ScottGu

@Matt,

>>>>>>> It my understanding that to mitigate the risk all customerrors must point to a single file. If this is the case the tool didn't appear to take into account the customerrors we had specified using location tags? If it did then I would have expected the tool to show the sites as still vulnerable?

Good question - I think the script might not handle the separate file scenario.  I will forward this along to the person who maintains the script.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:48 AM by ScottGu

@William,

>>>>>>>> I am glad that you provided this quick solution and are working on a real fix to the root of the problem.  However, I work very hard to make sure all my ASP.Net sites are as secure as possible and I feel rather let down of this big one that is outside of my control.  After reading nearly every comment on this site and watching the attack video, I am really confused on how it actually works - I have read your "it can tell the difference between 400 and 500" comment numerous times, but I still do not really understand. I appreciate the need for secrecy before a patch is released, but, will it be possible to release further details when it is all dealt with as to more of the background of this attack? To be honest, without something like this, I do not see my faith of ASP.Net returning any time soon.

This blog post provides more details about the attack: blogs.technet.com/.../understanding-the-asp-net-vulnerability.aspx

To be honest, oracle padding attacks are difficult to understand/explain - the math involved in the crypto side of the world is pretty involved and most papers are about 20-30 pages in length.

>>>>>>>>>> Lastly, I have read about the feature of ASP.Net that is used to return the web.config or other files is a new-ish feature. I always use the latest version of ASP.Net - but in all honesty, I only do it because I can. I don't really use many components that were not used in version 2, how can I tell if I actually need this component and is there anyway to turn it off?

I will be posting another blog post soon that shows how to turn off some features (and what they are used for) that will help with this.

Thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:49 AM by ScottGu

@Daniel,

>>>>>>> Is the attack only limited to the web.config file?  We store all our settings in seperate files outside the web.config like:  <smtp configSource="Config\MailSettings.config"></smtp>  Would an attacker have any access to these files if they know the path?

In theory yes they could if they knew the exact path.  I'd recommend encrypting the contents if you want to make sure they are absolutely secure.  Note that the workaround above is a mitigation until the patch comes out to protect against the public attack.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:50 AM by ScottGu

@Daniel,

>>>>>>> Can you explain how to remove those, as this is the preferred approach for our MVC apps which don't use those.

I'll post another blog post shortly (either tonight or tomorrow AM) that details how to do this.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:51 AM by ScottGu

@SteveW,

>>>>>>>> Am I at risk if my site doesn't host any Asp.Net pages, however IIS could still map .aspx requests to the .Net Framework.  Would the error messages returned give sufficient information to an attacker?

Unclear - to be safe I'd probably recommend implementing the above workaround.  Or removing the script extensions to map ASP.NET resources in the app.

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 2:10 AM by ScottGu

@catz,

>>>>>>>> Thanks for posting this information Scott. I use this in ASP 2.0, 3.5 and 3.5 SP1 sites: <customErrors mode="RemoteOnly" defaultRedirect="Issue.htm" /> I am explicitly stating the defaultRedirect but the mode is not "On"

RemoteOnly will also work fine.  

Hope this helps,

Scott

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 2:11 AM by jhallal

Thanks for the information

Jamil

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 2:30 AM by Nathan

Hi,

1.What about web applications protected by forms authentication?

In this case, even after adding the recommended custom errors setting and Error.aspx file, a request to PageThatDoesNotExist.aspx does not go to the Error.aspx, it gets redirected to Login.aspx.  

2.  Does the redirect to the login page that forms authentication performs reveal anything?

2b. Does the redirect to the login page that forms authentication performs respond in any measurably different response time for a page that exists or otherwise?

3.  If 2 or 2b is yes, would implementing the random delay code (found in the recommended Error.aspx page) in the login.aspx be an effective mitigation of this attack?

Thanks,

Nathan

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 2:35 AM by Jonas Frost

... now any attacker can just pound /error.aspx on sites and eat the thread pool.. I __seriously__ don't think you should recomend that fix, Mr ScottGu.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 2:38 AM by RichB

It's a padding oracle attack, not an oracle padding attack.

ie padding revealed by an oracle.  It's nothing to do with the padding of an oracle, whatever that may be!

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 3:07 AM by Steve Fenton

Hi Scott,

Thanks for the replies - it's awesome that we can get good clarification like this so quickly.

All web.config files are being temporarily patched until the fix is out.

Thanks

Steve

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 3:47 AM by samy

We have a website with multiple virtual directories below. However, the website settings seem to override the 404 error redirection we defined in the web.config of our virtual directories.

If we deliberately create a 500 error, it redirects correctly to error.html, but a 404 error does not and returns indeed the default website 404 page.

Since the attack seems to be based on differentiating between 404 and others errors, is this safe? The script you gave tells us the web.config are correct.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 4:19 AM by Kristoffer

Hi Scott,

Will URLScan, configured to not allow .config extensions, be effective against this attack?

Regards

Kristoffer

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 4:28 AM by Adriano

Hi Scott, what happens if I set <CustomErrors mode="Off" /> AND I manage the errors through the "OnError" handler event? Such as the one found on Global.asax, -or- through an HTP handler?

Thanks.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 4:35 AM by nick_uk

Fair play Scott.

You released a fix on the same day and have responded to every comment on your blog.

Those of us that know the protocol for announcing a vulnerabiity fully understand why you have to go public. Although most "researchers" (gray hat hackers) follow a protocol that usually involves givind the vendor 45 days to prepare a fix. But you guys only get a day or two. Sounds a bit harsh.

I personally think you have acted amazingly well. I also gather you've been working pretty hard (out of hours) so thanks to the team for that.

At least someone appreciates your efforts.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 4:46 AM by DanAtkinson

I just tried this on our site and our customErrors node has a configSource attribute calling from another file.

When I run the vulnerability check against this setup, I get "** Vulnerable configuration found **". However when I copy the contents of the customerrors file into the web.config, I get 'OK'.

So, can I assume that the script doesn't account for the possibility that the customErrors node is actually in an external file, and therefore says it's vulnerable just to be on the safe side?

Thanks, Dan

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 5:34 AM by Adriano

Hi Scott, I would like to know whether handling the errors through "OnError" event on the GLOBAL.ASAX/Application class and performing our own redirection to a given ASPX page is considered unsafe.

Thank you!

Cheers

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 6:33 AM by Sameer Joshi

What if i have SSL all over my site?

Thanks, Sameer Joshi

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 8:32 AM by Deba

I am encrypting the web.config sections with RSA Cryto provider. If someone can read the web.config, can they decrypt the encrypted sections ?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 8:34 AM by Ricc

For people using SharePoint... Just to let you know that this fix does work!! (as expected at least)

The tests (against a random url) however dont show the correct responses because of the way SP handles url requests. If you test your sever against system urls (eg WebResources.asx?blahh...) this will produce 200 errors as expected with the fix applied. Without it applied you will get 500 errors.

Let’s get this one fixed ASAP Scott. Good luck. Please keep us informed of progress.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 8:53 AM by BrianCPayne

What about using the Application_Error method of the GLOBAL.ASAX page to handle returning the custom error page? This is an easy method that seems to work rather well and provides other behind-the-scenes methods for handling other events.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 9:03 AM by mhildreth

Scott,

Our sites all use customErrors already with a default redirect. However, we do not specify redirectMode="ResponseRewrite" explicitly. The MSDN docs indicate that the default value or the redirectMode attribute is ResponseRedirect. Can you shed some light on how that attribute affects this issue? Thanks in advance,

-Mark

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 9:18 AM by alejo

Hey who can believe that they released so quickly without previous info? Can tell us the truth please? What you know what you don't know?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 9:24 AM by Andrew

To be clarify (and thanks for your patience with all of us!):

Is it safe to just have the mode set to "Off"? Or must it be "On/RemoteOnly"?

If it must be "On/RemoteOnly" and no "defaultRedirect" attribute is defined (and no custom error pages defined), is that safe?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 9:27 AM by Richard Hubert

And the script bombs on Windows Server 2008 R2 with IIS7.5:

T:\tmp>cscript DetectCustomErrorsDisabled3.vbs

Microsoft (R) Windows Script Host Version 5.8

Copyright (C) Microsoft Corporation. All rights reserved.

Could not find IIS ADSI object. Make sure you have IIS and IIS6 management compatibility installed.

T:\tmp>

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 9:39 AM by BrianCPayne

I guess I either wasn't clear or complete enough in my question or I just don't understand the answer.  I use the Application_Error method of the Global.ASAX page to redirect all errors to a generic error page tailored to the individual application.  This method also sends me an e-mail message with all the error details so that I can know about the error and work on preventing it in the future.  How does this compare to doing effectively the same thing with the <customErrors> section of the web.config?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 9:46 AM by john

I have had this type of custom error page for a while anyway just because it was more user friendly.

In my logs for the past year I have been seeing errors stating that "padding was invalid". Do you think this could be related to the issue. I would usually see a number of these appear together in the log. I was assuming it was some sort of bot such as an indexing engine hitting the pages in an unexpected way.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 9:51 AM by MadManMoon

Scott - A couple quick questions that I hope you are able to find the time to reply to.

- Is it possible to use external config files (via <appSettings file="..."> and/or <mySection configSource="...">) located in a directory with access credentials that are more secure than that of the anonymous IIS user (without anonymous users being prompted for login when attempting to access a page on the site)? The thought being that if it's possible, it may provide an increased level of security that would help reduce exposure to the vulnerability.

- If the above is not possible, would it not make more sense for one to take a half day to write a simple custom class/object that accesses a custom configuration scheme/file located in a directory outside of any IIS folders accessible by anonymous users?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 9:56 AM by Chad Michel

How would this affect the usage of the MVC [HandleError] attribute. Should this attribute be removed and should we only handle errors thru the <customErrors> section?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:16 AM by imarrero

Thanks so much Scott !!

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:18 AM by Chris Lamont

Is Windows Azure affected?  My hopes in using the Azure platform is that I would get more protection from these types of attacks... considering it's a managed service by Microsoft.

Let me know if there is any security benefit to using the Azure platform, or if being protected has any dependency on me manually setting my ServiceConfiguration to (osVersion = "*")

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:19 AM by Jaime Bula

How does this affect WCF services that use ASP.Net Authentication?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:21 AM by uwspstar

thanks for your code, I will check my site and fix it ASAP.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:42 AM by Arun

Any latest updates on this?!!!!!!!!!!

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:45 AM by Luís Falcão

Very important information, thanks a lot.

A further and desirable enhancement for to the VBScript vulnerabilities checking file, would be following the configSource attribute. In my case, for deployment reasons, all sections that have configurations depending on the deployment environment (customErrors included), use the configSource attribute to include the corresponding environment section file configuration.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:46 AM by Vladimir Gofaizen

Has anybody tested this attack with Request Validation turned on? Can you still get the machine key?

I assume that most developers with public websites that use user accounts and machine key encrypted items on the client enable it..

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 11:07 AM by Thomas Derenthal

I got this web.config mod from and article in VisualStudio magazine online on Friday. Will this also work?

<machineKey validationKey="AutoGenerate,IsolateApps"  validation="3DES"   decryptionKey="AutoGenerate,IsolateApps"   decryption="3DES" />

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 11:11 AM by gsbell

Does this exploit allow access to code-behind files?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 11:15 AM by Edcilem

I think the script to check for sites that are not configured does not check the extra configuration for 3.5 SP1 and 4.0.  I have a site that does have SP1 installed and has CustomErrors on and defaultRedirect configured.  However, we do not have redirectMode="ResponseRewrite".  This was not pickedup by this script.  Is there a way this could be found as well?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 11:18 AM by Mike

Does a similar fix need to be done with invalid paths too?  It looked like this just does custom errors for invalid files.  Could the errors from invalid paths also be exploited or do I not need to worry about that?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 11:32 AM by Rouchie

>>>>>>  I use the Application_Error method of the Global.ASAX page to redirect all errors to a generic error page tailored to the individual application

Me too.  Let's have some clarification here please Scott :-|

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 11:36 AM by jamezw

Instead of modifying X number of web.config files, could an IIS setting be changed to simply block any request for any web.config file?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 11:48 AM by SimonG

Scott, I'm worried about the scalability if we implement the solution regarding the 'thread.sleep' implementation....won't this result in requests being queued up?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 11:53 AM by Wes

Wouldn't using a different encryption method for the key work as well (say TripleDES)?  If you wanted to keep your error pages....

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:02 PM by aspnetguy

does the stack tarce look sth like this if they are trying to exploit this

Stack Trace :    at System.Web.UI.Page.DecryptStringWithIV(String s, IVType ivType)

  at System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext context)

  at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

  at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:03 PM by aspnetguy

So if we have a standard httpapplication moudule handling our errors and and redirecting a custom application error page, I am taking from above discussion that we are not effected. Is that correct?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:04 PM by John Li

Can this exploit be used on asmx and wcf web services?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:05 PM by John Li

Can this exploit be used on asmx and wcf services as well?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:10 PM by mark3asp

I don't see that adding the attribute: redirectMode="ResponseRewrite" makes sense for a MVC site. I added it and my 404s were no longer going to my Error page but to the generic asp.net 404 error page. When I removed that attribute my custom Error page was used.

Can we have some clarification here? What's the sense in adding redirectMode="ResponseRewrite" with MVC sites?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:11 PM by Brandon

A nice change for the script would be for it to just generate and display a list of affected web sites rather than just showing an alert for each one. That would be much friendlier.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:15 PM by aspnet guy

The scripts are not working as it says IIS management compatibility needs ot be installed..We are running IIS 7 on windows server 2008

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:26 PM by Dave Mound

Does this still need to be done if im on a host who uses Plesk as I think Plesk handles the default error pages?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:27 PM by bradser

Scott, I'd appreciate it if you could generate a checksum for the script, so we can verify it's integrity before/after running it on production boxes.

Thanks,

Brad

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:45 PM by jihohan

If we are using basic auth for example, we must return 401.

What is the recommendation in this case?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:51 PM by Andy

>>>>>>>> I use the Application_Error method of the Global.ASAX page to redirect all errors to a generic error page tailored to the individual application.  This method also sends me an e-mail message with all the error details so that I can know about the error and work on preventing it in the future.  How does this compare to doing effectively the same thing with the <customErrors> section of the web.config?

I also use this. I always thought it had the same effect as the configurable redirect page. Is this not the case guys?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:56 PM by MikeM

Yeah, I'm curious about whether this would give access to code-behind files as well.  Or raw, unproccessed ASPX files and such.

Given my limited understanding of the situation, I take it the answer is yes, they can.  That's brutal.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 12:57 PM by eppyjerk

Scott,

Can you confirm or deny that ASP.NET Web Services are vulnerable to this exploit?  Does this exploit require the use of built-in ASP.NET *.axd requests to be successful?  I know you are getting a lot of the same questions repeatedly, when can we expect a follow-up post to organize some of these responses?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:01 PM by Tim

As with Mark, I am also interested in more info about redirectMode="ResponseRewrite". I have an application that runs on ASP.NET 4.0 with the following: <customErrors mode="On" defaultRedirect="Error.htm" />. This is similar to the 1.1 and 2.0 workaround listed above. Is this sufficient with ASP.NET 3.5 and 4.0? If not, can you please give details why this is not sufficient?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:02 PM by Brian Hamachek

Is ASP.Net code running in Windows Azure effected?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:23 PM by Greg Brady

Does this apply to files in subdirectories, such as App_Data?  Could someone retrieve arbitrary files from there?

Does an ASP.NET MVC application under IIS6 provide additional attack surface when configured with a wildcard script mapping?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 1:32 PM by Frank Samijn

Dear Scott,

Thank you for the support on this ASP.NET security vulnerability.

I'm worried about our Exchange (2007/2010) servers, mainly the Client Access Servers.

Could this security vulnerability be used to compromise the CAS machines?

So, should we apply the workaround?

Kind regards,

Frank

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 2:14 PM by TonyB

Hi Scott,

Thanks for the good info.  Is ScriptResource/WebResource the only current attract vector?

Would sub-classing ScriptResourceHandler  and wrapping ProcessRequest in a try/catch with the catch always returning a 404 fix the problem?

AssemblyResourceLoader is sealed so I'm not sure how to do that for WebResource.axd.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 2:15 PM by Pete

For ASP.NET MVC users, we need to know whether or not ResponseRewrite vs. ResponseDirect is critical.  ResponseRewrite does not let you specify the error page as a route, but only as an aspx or html page.  A few others have asked above.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 2:31 PM by Bruce

Scott, what about all the ASP.NET stuff in Exchange/OWA. The vbs tools says files like:

C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell\web.config:

are vulnerable. I hate to mess with Exchange.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 2:54 PM by Hung

The problem actually lies in encryption algorithm.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 2:58 PM by Bob

Could you provide explicit instuctions for a MVC workaround?  If you click my name, you should be brought to a StackOverflow post, if that's more convenient.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 3:21 PM by Erik Sargent

Scott - we really appreciate the effort you are putting in to respond to the hundreds of questions - many of them repetative - that this issue has generated. You continue to be an awesome example of how customers want to be able to interact with microsoft. Wish all the product teams were as open and hard working with the public as you (and your team) are!

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 3:22 PM by Jim R

Can anyone spot a problem with this code?  I'm planning on adding it to the vbscript just after line 164 - I've tested it but not run it in production yet...

   IF errFound > 0 THEN

       WScript.Echo Path & ": ** Vulnerable configuration found **"

'-------------------------------------------------------

' New Code to FIX the problem by setting a default error page and also "turn on"  the custom errors attribute.

'  Close the XML Doc because we will  overwrite it

       WScript.Echo "-----------------------------------------------------"

SET xmldoc = nothing

dim thisFolder, theNode, parentNode, fileToLoad

thisFolder = replace(Path,"\web.config","")

'  backup the existing file to a consistent name

objFileSys.CopyFile Path,thisFolder & "\web.BackupBeforeVulnerabilityFix.config", true

'  copy over the SimpleError.aspx  file --  this must be "pre-staged"  at   c:\temp\simpleerror.aspx"  before running this script

objFileSys.CopyFile "c:\temp\simpleerror.aspx",thisFolder & "\simpleerror.aspx", true

'  1.  Load the Web.Config document

'  2.  locate the customErrors node and remove it if found

'           (this removes any specific error pages if they exist UNDER the node--rare if at all in our case)

'  3.  create the customErrors node and set the attributes we want

'  4.  save the file.

SET xmlDoc = CreateObject("Microsoft.XMLDOM")

xmlDoc.async="false"

fileToLoad = Path

'-----------------------------------------------------------------------

'  TESTING - MAKE COPY OF WEB.CONFIG ->   TRYME.CONFIG

WScript.Echo "Copying "  & Path & " to " & thisFolder & "\TryMe.config"

objFileSys.CopyFile Path,thisFolder & "\TryMe.config", true

fileToLoad = thisFolder & "\TryMe.config"

'-----------------------------------------------------------------------

xmlDoc.load(fileToLoad)

SET theNode = xmlDoc.selectSingleNode("//configuration/system.web/customErrors")

if not (theNode Is Nothing) then

WScript.Echo "-- Existing Node XML:  " & theNode.XML

theNode.parentNode.removeChild(theNode)

else

WScript.Echo "-- No existing node, adding only"

end if

SET parentNode = xmlDoc.selectSingleNode("//configuration/system.web")

SET theNode = xmlDoc.createNode(1,"customErrors","")

CALL theNode.setAttribute("mode","On")

CALL theNode.setAttribute("defaultRedirect","~/simpleerror.aspx")

WScript.Echo "-- NEW Node XML:  " & theNode.XML

parentNode.appendChild(theNode)

WScript.Echo "-- File Saved :  " & fileToLoad

CALL xmlDoc.save(fileToLoad)

       WScript.Echo "-----------------------------------------------------"

   ELSE

       WScript.Echo Path & ": ok"

   END IF

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 3:42 PM by Chris Lamont

If the Oracle is silenced by reducing the difference between a 4xx errors and 5xx errors, does the Oracle not expose itself between 2xx responses and the now static 4xx response?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 3:43 PM by Chris Lamont

fyi - I am told by my TAM that Exchange is not vulnerable

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 4:10 PM by EvereQ

Re @ScottGu:

".. too little sleep to safely do a crypto code review right now .."

Sure I think most of us understand that you (same as your teams) do really hard and excellent job and want to thank you for the support and you can ignore comments that say something different (like comments that try to found somebody who is responsible for such issue etc)! And sure we all do understand that your primary target right now - is windows update fix, etc..

But my comment was not just about "typo"! Aactually maybe take time to fix it in post? as many people do not have QA etc and can do fixing directly in production web.config etc.. they will be really "unhappy" to see total site down because of typo... :)

Same I don't want just to show another way to write same code, but in .NET 4! I want to highlight some issues with C# code that I see better after "get rid" of all "tricks" with IDisposable etc :)

Actually I see 2 "possible" issues:

a) Thread.Sleep((int)delay[0]); This line of code can actually simply issue something like Thread.Sleep(0)!

So with some probability code from post do NOT add ANY "cryptographically strong" delay to response time! I.e. it's just add constant value to total response time that equal to time it takes to execute Page_Load method code if there are no  waiting threads to execute! What does it mean? Say hacker already have some soft.

He can continue to run that soft without any modification and with some probability he can get success even with C# code from your post :) Yes, it make his life worse, but not as much as we want :)

b) In other 255 cases (byte type resolution), when you DO get "crypto strong" delay value, the RANGE and RESOLUTION of this value POTENTIALLY can become issue!

As probably you know Thread.Sleep actually have some "resolution" (lets say 20), i.e. potentially, you can get something like 20,40,60,80,100,120,... milliseconds delays, but not say 3 :)

I.e. say our "true" 'resolution' is only 13 :) (note: I am NOT hacker, but it's possible for me to figure this out in short period of time :D)

If hackers already think up how to dial with oracles etc, how we can be sure that such delay with fixed range (more so range that KNOWN now to hackers :D, i.e 20,40,60,80... milliseconds and up to say 260) can be useful to protect sites? Yes, this "fixed" delay probably make hacker life "worse" but MAYBE using "brute force" it's still possible to organze attack? I simply do not have time with my job to study more 'oracle' issues :) to figure out how problematic for hacker such delays :)

So question is: maybe better to generate few crypto random bytes and use simple loop instead of Thread.Sleep? (p.s. not sure it's good idea to use Thread.Sleep on windows OS in cryptography anyway) that will really made hackers life worse?

I think most of us can "temporary" live with issue that in case of 404 or 500 error our users will wait even 5 seconds to get error page :)

What you think?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 4:22 PM by Evan Larsen

Scott,

If this vulnerability allows the attacker to download the web.config, whats stoping them from downloading your application's library assemblies? Also, what other files could they possibly download?

I thought there was some type of MIME exclusion settings that IIS had? how does this attack circumvent that?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 5:33 PM by Joseph

Should we get a new flux capacitor?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 6:02 PM by cspielman

Does this vulnerability apply to ASP.NET web services?  It doesn't seem as if there is a ViewState issue.  But does the web.config issue still exist?  Is the web.config issue avoided if sensitive info is embedded in an assembly?

If someone can elaborate, that would be great. Thanks.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 6:26 PM by ChrisS

I have implemented the workaround on my concerned sites.  One peculiar behavior I just stumbled on is when you try www.mysite.com/~/  

This will through a 404 .NET error no matter what my customError tag settings are.  The resulting page reveals server information and physical paths.  How can I disable this error page?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 6:28 PM by TonyB

@Chris Lamont

I think the exploit code uses 404 as an affirmative response (i.e. "The crypto string you sent is good but I was unable to find that resource") and 5xx as a negative response ("You sent a bad crypto string").

If 404 and 5xx both return the same message and status to the attacker they don't have a way to know if the crypto string they are sending is correct or not.

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 9:51 PM by Chad Michel

If one site is exploited within a shared hosting environment are all sites on the same machine open at that point?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 9:52 PM by Michael Fever

Does this apply to Windows Server 2000?  I really do not like messing around with production environments.  Yeah its 10 yrs old but it works and I like it  =(

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:06 PM by Priya

Does it affect sites hosted via ISA?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:45 PM by opikvk

thanks alot geeks :)

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:45 PM by Scott Isaacs

What about sites that have ASP.NET installed, but aren't taking advantage of it?  For example in shared hosting where ASP.NET, classic ASP and PHP are all enabled on a particular site, if only classic PHP is being used, is that site still vulnerable since ASP.NET is installed?  Do we need to add a web.config file to a site that is otherwise purely PHP just because ASP.NET is enabled for that site in IIS?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:52 PM by Eric

It seems like there are two issues: crypto defect and the way ASP .NET allows you to bypass forbidden extensions and just serve them via WebResource.axd. Is that correct?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 10:58 PM by marcinsw

Just imagine how many guys have taken advantage of this hole before they shared it with someone who shared it with Microsoft... I will have to go through server logs to check if my web.config wasn't downloaded, hope it leaves a trace there... I will sue bastards if they did it on my site, seriously...

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 11:39 PM by Shawn Mehaffie

"It is not enough to simply turn on CustomErrors or have it set to RemoteOnly".  Why does that not take care of the issue?  I was under the impression that setting it to RemoteOnly send all remote user to the same error page and does not give any explicit error information back to the user. So is this not the same as setting the default error page.

If it is set to RemoteOnly and an specific error page is set, will admins running the site on the server still get the standard error page so they can see specific error when run on the server?

I know this has been asked before, but i did not see an answer.  If a site requires https are these sites as risk?

# re: Important: ASP.NET Security Vulnerability

Monday, September 20, 2010 11:42 PM by S. Shawn Mehaffie

Scott,

Is there a way to set this in the machine.config file instead of each web.config.  This would really help those of us who have numerous sites all on the same server.

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 12:00 AM by Craig Taylor

Two things.

First to all the people bagging Microsoft over this so me your development framework and then we can test that for vulnerabilities.

Second my hat goes off to Microsoft and particularly ScottGu for getting this 'temp' fix out to the public.

I certainly welcomed it.

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 12:02 AM by sreejukg

Thank you for the post.

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 12:11 AM by priya.devalraju

Does it affect sites hosted via ISA

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 12:21 AM by Carlos

Excelent!!!

Thanks

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 12:32 AM by sreejukg

Is this applicable to Sharepoint sites?

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 1:23 AM by Prashant

Realy you are great.

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 2:15 AM by ScottGu

I just posted another blog post about the security issue here: weblogs.asp.net/.../frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

It answers a number of common questions that people have asked above.  If you can please review it, and if it does not answer your question then ask your question again on that post (instead of this one) that would be great - as it would help me keep up with all the questions being asked.  

Many thanks,

Scott

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 2:40 AM by Licam

Hi Scott,

are WCF Services running in ASP.NET Compatibility Mode affected too?

Thx

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 7:50 AM by rtpHarry

You have spelled occurred wrong in the vb version of error.aspx ;)

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 11:54 AM by ILIA BROUDNO

Our ASP.NET applications all use custom errors and they do show the same content to the caller no matter what the error is. The difference is that we do not do it via web.config we do it via Global.asax in Application_Error event handler.

It is essential to our error reporting that we do it this way.

Are we still safe?

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 11:59 AM by Steve K

How does this affect using the membershipprovider with

a machinekey configure with validation="SHA1" decryption="AES"

Is the site still vulnerable?

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 12:01 PM by Steve K

How does this affect using the membershipprovider with

A machinekey configure with          validation="SHA1"

         decryption="AES"

If one uses this is the site still vulnerable?

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 12:24 PM by Mike

Thanks Scott.  Timely and easy to implement.

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 12:27 PM by Ben Sapp

It looks like the vbs script at the above link ignores comments.  If customerrors is commented out it will report the web.config OK.

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 12:50 PM by i8beef

If you are using MVC, and your error pages are being served by an MVC controller, wouldn't setting the redirectMode to ResponseRewrite not work, since it would use Server.Transfer behind the scenes, and IIS wouldn't be able to find a file system location that corresponded to the defaultRedirect and thus would return its own 404 page?

I seem to be running into this... If that's the case would it be better to:

1. Use Response.Redirect in my Application_Error method to redirect to my error page manually, or

2. Just change back to ResponseRedirect in the customErrors section?

Bonus question: Whats the difference between 1 and 2? Does an attacker actually still see the 404 response or anything else in either case?

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 12:51 PM by Shirish

One query:

For error page, should we use only ".htm" or we can use ".aspx" as well. I am asking this as i have read many times that we should use ".htm" for error pages instead of ".aspx". Could you please explain this.

Thanks,

Shirish Sharma

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 1:27 PM by Judy Vedder

I think people need to be cautious.  It appears to me that the host settings can display 3.5, but you may have 3.5 SP1 installed.  The instructions for 3.5 and 3.5 SP1 are different.

My host provider has confirmed that 3.5SP1 installed on the server, but my host settings says 3.5. I am going to follow the instruction for 3.5 SP1 - is that the correct action?

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 5:36 PM by Brian Merrifield

If you are getting the error:

"Could not find IIS ADSI object. Make sure you have IIS and IIS6 management compatibility installed."

Make sure you run the script via an administrative command prompt (Right-click Command Prompt, click Run as administrator).

-Brian

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 8:32 PM by Kevin W. Wall

@Evan: You asked "Why not just flip the encryption method from AES to 3DES"...  because the oracle padding attack exploits a weakness in the PKCS7 (or PKCS5) padding scheme; it is not a weakness in any particular cipher. The proper fix for this is to ensure message authenticity by adding a "message authentication code" (MAC) over the IV and ciphertext and to check that the MAC is valid prior to trying to decrypt.

@Microsoft: This problem was fixed in OWASP's ESAPI 2.0-rc7. It is FOSS, licensed under a BSD license. Even though it is written in Java, it should be fairly straightforward to convert to C# so feel free to use.

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 8:58 PM by Monib

Is there any ETA on when would ASP.NET team would be releasing the update? We are in the process of fixing our servers , but may have to retract the fix after an update is released. So just for information purposes want to know the ETA.

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 9:29 PM by Adrian Francis

Just found this post and error. Re the script, with a bunch of sites, cscript DetectCustomErrorsDisabled31.vbs > results.txt makes it much easier to run through, saving the output to a txt file.

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 21, 2010 11:40 PM by Hung

I tested the script and it marked my C:\inetpub\wwwroot is "vulnerable configuration found", even it doesn't have web.config file. The same status with some other folders, that don't have web.config file either.

Bug in checking script?

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 5:49 AM by Dimitris Karantonis

Hi,

1. Does this affect public REST wcf services without security enabled?

2. Does this affect public web services without security enabled?

3. Does this affect static web sites (the vulnerability script displayed no vulnerability for static asp.net web sites, even though the custom errors section was commented

thanks

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 6:18 AM by pitz

For the folks who have asked about the web.config file being downloaded, this is possible ONLY if the first padding oracle attack has been successful (i.e., the attacker finds out what the decryption key is).  The subsequent download capability is not limited to web.config, but to all files in your web directory, including assemblies in the bin directory.  The downloads would not easily be discernible in the IIS logs because it hides under an ASP.NET feature introduced in 3.5.

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 6:27 AM by Naeem

Hi Scott, do you know if CRM is also affected?

Thanks

P.S. Good work on keeping us informed

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 6:47 AM by Bill

I keep seeing references to "the attack that has been publicly demonstrated" -- does that mean there are other similar attacks that were not demonstrated publicly?

Was Microsoft warned ahead of time that this release was imminent?  It seems this category of vulnerability has been known for some time, why was it not addressed before it was made public?

The guys who released this, along with the tool to exploit it, call themselves "security researchers".  Releasing this in the wild without giving anyone prior notice is NOT research.  These "researchers" are either anti-Microsoft trolls or blackmailers -- we may never know which.

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 7:08 AM by Viresh Shah

Hi Scott,

Thanks for this post. One question arises here how it would affect search engine rankings. As you're asking not to differentiate between response codes then how search engine would come to know when some pages are removed or not found. Because response would never contain right response code. Because content of my website changes frequently. So what about dead links?

Thank you. Viresh

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 8:10 AM by Charles Ochang

I am working on a new MVC project and I was just wondering how I would extend this to the project. It then occurred to me that just copying this may not work due to how URLs are invoked in MVC. Any thoughts?

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 8:33 AM by Nick

"The issue in the video was that he downloaded the web.config file"

What if you block all the requests to web.config file using ISAPI filter at IIS level?  Will that work and prevent this attack?

Thanks

Nick

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 8:53 AM by aspuser

scott,

I applied the insturrictuons but for 404 error, I am still seeing the standad error page. I am using elmah.dll to log my errors. should I remove elmah from my application?

I always uses the redirect but here I am getting the asp.net standard error page for 404 eror.

can you explain why this could be happing? thanks !

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 9:22 AM by Ras Fred

Just to add my name to the list...we have sites using Application_Error in Global.asax - this method redirects to a single specific web page.  We have a different page listed in the customError web.config method.  Is this okay?  Thank you!

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 11:10 AM by David

What if we have a page level error handler that .redirects or server.transfers to a specific general error page? I've got several pages that do just that and the provide only minimal error information.

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 11:26 AM by Markus Mühlich

For a couple of websites this workaround and script will work by hand. It's even more complicated and extremly time and cost-consuming to handle this workaround with hundreds of websites.

Therefore I wrote I a small console application, which will run this workaround automatically and creates also the necessary error pages (incl. the code for error.aspx). It needs to run directly on each box with administrative rights.I tested it on my own servers and it runs pretty well.

If someone is interested, I realy like to share it (but on erveryones own risk). Please e-mail me at secvul@netspec.de.

Regards

Markus

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 11:34 AM by Fadi

How about you guys fix ASP.NET and release a patch quickly rather than do this?

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 11:37 AM by Brian J. Sayatovic

Several people have commented that using a random delay (0-255ms) would still average to a constant distinct from the oracle-attacking requests.  Why not instead have the error page attempt the same trick the attack uses so that you're invoking the exact same timing?

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 12:00 PM by Kevin Tan

The article only mentioned about ASP.NET and JCF

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 12:02 PM by Kevin Tan

Sorry, I didn't quite finish typing for my previous comment.

I was wondering that the article only mentioned about ASP.NET and java platform; however, is ASP system exposed to the same threat too?

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 12:15 PM by Hai Le

is this problem found out by one vietnamese expert named THAI ? he stated tha 25% of ASP.NET website is risky

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 1:13 PM by BGK

What would happen if the customerrors is set to true with defaultredirect set to errorpage.aspx and again have error codes that also redirect to errorpage.aspx. The only difference would be that the errorpage.aspx would take a string query parameter that is set based on the value of the error code.

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 1:35 PM by david s

IS this a big vulnerability is my sharepoint server is hosted internally only? I figure it shouldn't and maybe will wait for microsoft to release a fix

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 8:48 PM by Andrew

If the problem exists only for WebResource.axd and ScriptResource.axd pages, would the fix below suffice?

<location path="WebResource.axd">

 <system.web>

   <customErrors defaultRedirect="/error.aspx" mode="On" />

 </system.web>

</location>

<location path="ScriptResource.axd">

 <system.web>

   <customErrors defaultRedirect="~/error.aspx" mode="On" />

 </system.web>

</location>

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 10:17 PM by xmen

What about if the attacker check the content-length as well, I think it still have hole. So, I'm sending random content-length by adding some random numbers in error page.

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 22, 2010 10:29 PM by Ron

Is this OK?

<customErrors defaultRedirect="OnError.aspx" mode="RemoteOnly"></customErrors>

When I run DetectCustomErrorsDisabled31.vbs I get OK on everything.

By the way, the error message on OnError.aspx says 404.  Is that OK?

# re: Important: ASP.NET Security Vulnerability

Thursday, September 23, 2010 4:50 PM by nannette

For this, I posted a full project with error handling and mailing yourself an email with errors.

weblogs.asp.net/.../asp-net-security-vulnerability-error-handling-project.aspx

It is a 3-part post with a ZIP of the project included.

One of the comments I received on my post was:

You never do thread.sleep in asp.net. You will end up running out of server threads. Should be implemented async-ly.

# re: Important: ASP.NET Security Vulnerability

Friday, September 24, 2010 12:24 PM by nannette

I wrote a blog post with a completed project that detects errors and sends an email to the user and implemented your suggested fix within it.

I received this comment:

You never do thread.sleep in asp.net. You will end up running out of server threads. Should be implemented async-ly.

# re: Important: ASP.NET Security Vulnerability

Friday, September 24, 2010 3:23 PM by Jen

>>>>>>>> No matter what I do I cannot get 404 errors to redirect to my generic error page. I always get the genertic IIS7 error 404 message instead. I have followed your guidance and have been at it for a few hours now without any luck.  The site I'm working on now uses Forms authentication and if I login then try to get to a page that is on the root of the site that does not exist I get sent to the generic error page just fine. The trouble comes when I test for an invalid url to a resource that is off the root of the site like a document. It's here that I see the standard IIS7 404 message.

If you can send me email (scottgu@microsoft.com) with more details we can help you enable this.

Scott,

I have the same issue as JeffS. I checked the FAQs you posted and did not see this addressed. Can you explain how to fix this?

Thank you,

Jen

# re: Important: ASP.NET Security Vulnerability

Friday, September 24, 2010 4:45 PM by sholodak

I wrote an HttpModule-based solution to the padding oracle exploit.  The project is up at sws.codeplex.com and licensed under Apache 2.  I don't have any official releases out there yet because I could use some help testing it and/or coding it.  I haven't seen the exploit tools so I haven't been able to verify it's effectiveness yet.  Right now, it's got 2 main features relating to the padding oracle expoit:

1) It stores FormsAuthenticationCookie and FormsAuthenticationTicket information on the server at the time the ticket is issued.  It uses this information to strengthen ticket validation... a LOT.  Even if your machine keys are compromised, nobody can create a FormsAuthenticationCookie that will pass validation.

2) It detects & prevents certain known padding oracle attack vectors (CryptographicException's on .axd requests) -- returns 200 codes where 404's or 500's are expected & introduces delays to the response.

sws.codeplex.com / www.sholo.net for more info

# re: Important: ASP.NET Security Vulnerability

Monday, September 27, 2010 4:25 AM by Carsten

Hi,

you wrote "3) You can then add an error.html file to your application that contains an appropriate error page of your choosing (containing whatever content you like). This file will be displayed anytime an error occurs within the web application."

Do I have to create a error.html file?

If it is not present, is the workaround working too?

Thanks

# re: Important: ASP.NET Security Vulnerability

Monday, September 27, 2010 4:49 AM by Vijai Prakash Maurya

Very useful information.

Thanks

# re: Important: ASP.NET Security Vulnerability

Monday, September 27, 2010 8:29 AM by frobnitzz

It's been asked before but I'll ask again as I think it's going to prevent me (and alot of other folk!) a load of work and worry...

Are sites behind ISA at risk? I'm going to hazard a guess at NO! Flood mitigation should prevent the attack in the first place right?

Thanks,

John

# re: Important: ASP.NET Security Vulnerability

Monday, September 27, 2010 8:47 AM by Rovastar

@frobnitzz

Sites behind ISA or any firewall are vulnerable as all the attack vectors are there it is just a question of scale.

I am not sure what ISA would have in place for a botnet over an hour period attacking you site with a simple 20 character URL which you do not know.

Why do you think it would protect you?

# re: Important: ASP.NET Security Vulnerability

Monday, September 27, 2010 9:25 AM by frobnitzz

@Rovastar

Just going on what I've read so far.. to quote another post on this site;

"The publicly disclosed exploit would cause the web server to generate thousands (or more likely tens of thousands) of HTTP 500 and 404 error responses to requests from a malicious client.

You can use stateful filters in your firewall or intrusion detection systems on your network to detect such patterns and block such clients

"

So I figured flood mitigation in ISA would work?

If I knew the answer I wouldn't be asking :)

Thanks,

John

# re: Important: ASP.NET Security Vulnerability

Monday, September 27, 2010 12:05 PM by Rovastar

@frobnitzz

No worries. I think most attacks will be from 1 IP and that the flood protection will help, I imagine most firewalls have some flood protection anyway so I don't see a need to change this.

But there could in the modern age of attacks have a distributed attack via a botnet.

# re: Important: ASP.NET Security Vulnerability

Monday, September 27, 2010 1:40 PM by Todd Walker

Does Microsoft ForeFront TMG provide any protection against this vulnerability?

# re: Important: ASP.NET Security Vulnerability

Monday, September 27, 2010 1:42 PM by a-romill

I am in OCS support, and have a case where the workaround breaks his CWA, so he had to rollback, and cannot apply the workaround.  Is this a known issue?

# re: Important: ASP.NET Security Vulnerability

Monday, September 27, 2010 1:53 PM by gimpy

I have applied the workaround following your instructions.  It seems to work for any url I try except for urls that end with .config or just . (period).  In these cases I get 404 errors.

# re: Important: ASP.NET Security Vulnerability

Monday, September 27, 2010 6:28 PM by Jani Hyytiäinen

Hmmm,

I've always wondered why all the asp.net applications have 'web.config' in the root dir with connectionStrings in it in the first place. Kind of like asking for it by design.

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 28, 2010 3:42 PM by pitz

If you're still using the workaround here (instead of downloading and testing the released patch), note the Sep 24 update of the workaround (adding URLScan into the workaround), because the customErrors section by itself is not enough to prevent the padding oracle exploit.  forums.asp.net/.../1607422.aspx

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 28, 2010 6:26 PM by carlcom

To use the padding oracle, the server needs to try to decrypt something.  We are not encrypting anything, viewstate is just base64 encoded, so are we vulnerable?

# re: Important: ASP.NET Security Vulnerability

Tuesday, September 28, 2010 7:38 PM by Kenneth

Microsoft released a patch MS10-070 which addresses this problem. The patch mentioned additional encryption for communication between ASP.net pages and server.

Is there an assessment on the relation between this patch and the workaround?

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 29, 2010 1:24 AM by John Boy

So can someone please clarify that the MS10-070 patch that was released today (Tuesday) addresses the asp.net concerns, and avoids the need to use the workaround?

This is not clear to me yet.

Thanks.

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 29, 2010 1:45 AM by Peter

Some more info over at isc.sans.org - they have gone to alert level Yellow.

# re: Important: ASP.NET Security Vulnerability

Wednesday, September 29, 2010 6:09 AM by Chris

I have several web servers with host intrusion detection services installed on them. What I need is some assistance in sniffing/detecting any return traffic from the web server (if vulnerable). I am guessing detection would be on the return response. If anyone could assist please post.

# re: Important: ASP.NET Security Vulnerability

Thursday, September 30, 2010 11:32 AM by Parrotlover77

I went to the security advisory to download the patch and it says to visit Microsoft Update.  I did that from several servers, but no patch is found.  It's also not found on WSUS.  What gives?

# re: Important: ASP.NET Security Vulnerability

Thursday, September 30, 2010 12:10 PM by Mark H

Well, the MS10-070 does NOT remediate this vulnerability.  Still shows as vulnerable with the VBS script, as well as thru a Foundstone scan.  Worthless patch.

# re: Important: ASP.NET Security Vulnerability

Friday, October 1, 2010 7:53 AM by J.

Hi,

Doe we need to change the machinekeys and encryptionkeys in the web.config? If so that will give problem with authentication. I am questioning if with this vulnerability you should not change any of chose. Assume those keys are intercepted and you apply all the patches MS recommends. Then I believe your site already have been compromised?

J.

# re: Important: ASP.NET Security Vulnerability

Saturday, October 2, 2010 12:18 PM by JJ

The MS patches does fix this issue and the vbscript just searches for the customerror settings so why would you expect the script to find if you have patched asp.net ?

Just read the security blog:

""Updated September 29, 2010

Added a note clarifying that the workaround and the detection script are no longer necessary once the security update has been installed. The security update is now available - please see MS10-070 for more information.""

# re: Important: ASP.NET Security Vulnerability

Monday, October 4, 2010 3:51 PM by Roger

Is their a way to tell in the IIS Logs that this vulnerability has been exploited already.  We recently manually installed the security updates and want to make sure on our web servers that this has not already been exploited.

Also if we find that a server has been exploited what are the recommended actions in that situation?

Thanks,

Roger

# re: Important: ASP.NET Security Vulnerability

Tuesday, October 5, 2010 6:02 AM by kim moss

Its great to see an article about security features in .net,

gr8 work..

cheers....

# re: Important: ASP.NET Security Vulnerability

Tuesday, October 5, 2010 6:56 PM by Stop Smoking Help

If you are using MVC, and your error pages are being served by an MVC controller, would not setting the redirectMode to ResponseRewrite not work, since it would use Server.Transfer behind the scenes, and IIS wouldn't be able to find a file system location that corresponded to the defaultRedirect and thus would return its own 404 page?

I seem to be running into this... If that's the case would it be better to:

1. Use Response.Redirect in my Application_Error method to redirect to my error page manually, or

2. Just change back to ResponseRedirect in the customErrors section?

Bonus question: Whats the difference between 1 and 2? Does an attacker actually still see the 404 response or anything else in either case?

# re: Important: ASP.NET Security Vulnerability

Thursday, October 14, 2010 8:14 AM by Peelo

Too late...just fixing production environment with thousands of "default.asp" -files generated by a such virus...

Damn hackers !

# re: Important: ASP.NET Security Vulnerability

Monday, October 18, 2010 9:48 AM by John

I put the customerrors patch in the Web.config, but when I try to go to an invalid page on the site, it just churns and churns and then about 5 minutes later (seriously), it comes back with an error that says:

XML Parsing Error: no element found

URL would go here.

Line Number 1, Column 1:

Any thoughts why that would be happening?