locked
ASP.NET Vulnerability - module instead of <customErrors> RRS feed

  • Question

  • User-592043436 posted

    I don't have a <customErrors> element declared in my web.config, I have instead an IHttpModule inside the <modules> section of web.config. 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? 

    Saturday, September 18, 2010 3:09 PM

Answers

  • User-158764254 posted

    I don't have a <customErrors> element declared in my web.config, I have instead an IHttpModule inside the <modules> section of web.config. 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? 

     

    Th exploit uses response code differences as part of its attack.  A very similar question was asked on Scott Gu's blog and the recommendation was to send ALL error's to the exact same error page.

     

    http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

    >>>>>>>> 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

     

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, September 18, 2010 5:27 PM

All replies

  • User-113666759 posted

    Probably yes. Here's what the authors say:

    error message setting is irrelevant. no error? there's always HTTP status. always the same HTTP status? there's always big timing different

    Only error handler with random delay might help here.

    Saturday, September 18, 2010 3:17 PM
  • User1738250506 posted

    customErrors section tells asp.net to redirect to a particular page when a specific http error occurs in the application. If you do not set the customErrors element in your web.config, it defautls to RemoteOnly mode as mentioned in your C:\Windows\Microsoft.NET\Framework\vx.x.xxxx\config\web.config.comments file. This means that the exception details will not be sent to the browser if the browser resides in a remote machine (not on the machine where the web server is running).

    So not including a customErrors section is same as including it with RemoteOnly mode.

    Saturday, September 18, 2010 3:19 PM
  • User-592043436 posted

    > Only error handler with random delay might help here.

     

    So I could just add a random delay with Thread.Sleep to my existing error module and I would be safe? 

    Saturday, September 18, 2010 3:26 PM
  • User-592043436 posted

    > So not including a customErrors section is same as including it with RemoteOnly mode.

     

    Ok, but I have a module to handle the errors. The default RemoteOnly handling of the error doesn't get involved because the HTTP module in the pipeline handles the error before. 
    Right? 

    Saturday, September 18, 2010 3:29 PM
  • User-113666759 posted

    I think you should be much more safe. Just make sure to use Cryptographic random number for Thread.Sleep. For the additional safety you can make it vary in the interval of 0..1000ms (as opposed to the interval of 0..255 suggested by Microsoft).

    I hope comment from Microsoft would clarify the situation here.

    Saturday, September 18, 2010 3:40 PM
  • User-113666759 posted

    Upd. As Mike have commented, random delay might not do any help.

    Saturday, September 18, 2010 3:56 PM
  • User-158764254 posted

    I don't have a <customErrors> element declared in my web.config, I have instead an IHttpModule inside the <modules> section of web.config. 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? 

     

    Th exploit uses response code differences as part of its attack.  A very similar question was asked on Scott Gu's blog and the recommendation was to send ALL error's to the exact same error page.

     

    http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

    >>>>>>>> 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

     

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, September 18, 2010 5:27 PM