ASP.NET Custom Errors Security Flaw

Posted by: Steven Smith, on 18 Sep 2010 | View original | Bookmarked: 0 time(s)

Microsoft just released some details on a security flaw that was publicized a few hours ago.  On this post, you can learn more about the ASP.NET vulnerability and how to detect whether your web sites might be affected by them.  This is a serious flaw that you should take steps to address as soon as possible, since the attack can be performed by anybody with the available tools, in less than a minute, and can provide them with access to any file the site has access to (including web.config), as well as potentially root level access to the machine.  This YouTube video shows the use of the tool (POET) in action.

In order to detect sites on your server that may be vulnerable, copy the script provided here to a file on your server named DetectCustomErrors.vbs.  Next, open a command line window as administrator and run the following command (I ran it from d:\ which is the root folder of my drive where my web sites are located):

cscript DetectCustomErrors.vbs

The output will be something like the following:


Once youve identified the config files that are vulnerable, the simplest solution is to provide a single custom error page, like so:

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

The way the exploit works is by gaining information from which errors are returned and potentially from how long it takes for a given error to be returned.  By always returning the same static file in response to any error, you deny the attacker this information and maintain the security of the application.

Dont forget to apply this fix to non-production-but-public sites as well.  If you have publicly accessible test, stage, beta, etc sites, they need to be addressed unless they are in a completely locked down DMZ, since anything on their machine could be compromised by this exploit.

Please share this post and the information in it as widely as possible.  As of this moment, virtually any ASP.NET web site online can potentially be compromised with about a minutes work.  By working together quickly, we (developers and IT pros) should be able to eliminate this vulnerability quickly, saving our companies and clients from potentially large losses.

Update Theres a slight bug in the script as published.  Change line 123:

from : EnumWebConfig(objDir.Path)

to:     EnumWebConfig(physicalPath)

Category: ASP.NET | Other Posts: View all posts by this blogger | Report as irrelevant | View bloggers stats | Views: 1477 | Hits: 31

Similar Posts

  • ASP.NET Custom Errors Security Flaw: Please Read! more
  • ASP.NET Custom Errors Security Flaw: Please Read! more
  • Designer Support for One-Way navigations in Entity Framework 4 more
  • How To: Silverlight grid hierarchy load on demand using MVVM and RIA services more
  • Free software for you! WebsiteSpark let the mountain go to Microsoft instead. more
  • Scenarios for WS-Passive and OpenID more
  • Customizing the SharePoint ECB with Javascript, Part 3 more
  • Why VBA Still Makes Sense more
  • Customizing the SharePoint ECB with Javascript, Part 1 more
  • Ruminations on Multi-Tenant Data Architectures more

News Categories

.NET | Agile | Ajax | Architecture | ASP.NET | BizTalk | C# | Certification | Data | DataGrid | DataSet | Debugger | DotNetNuke | Events | GridView | IIS | Indigo | JavaScript | Mobile | Mono | Patterns and Practices | Performance | Podcast | Refactor | Regex | Security | Sharepoint | Silverlight | Smart Client Applications | Software | SQL | VB.NET | Visual Studio | W3 | WCF | WinFx | WPF | WSE | XAML | XLinq | XML | XSD