Last post Sep 20, 2010 04:04 PM by joshuaperry
Sep 19, 2010 11:47 AM|SamJonesIII|LINK
May we please expand the scope of this discussion?
Specifically, may we discuss how to detect if the vulnerability is present from the web-client presentation of the application?
Issue: The web.config itself is not an authoritative indication of the presence of the issue.
The vbs script discussed (by Mr. Gu, and the article here: http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx ) present a vbs script that scans your web.config files, and looks for the <customErrors> section.
For a simple asp.net app, this is the correct thing to look for.
However, our app is a "big, professional" app. All the errors (the simple errors, anyway) are redirected in code to our own error.aspx.
Our web.config lacks a <customErrors> section, or any mention of our error.aspx file.
On our site, if you go to <our-url.com>/nonexistent-file.foo (or any extension, or no extension), you ALWAYS get our error.aspx and an http result of 200.
There is probably a way to get an http 500 (by pumping the server too hard, like a ddos or something), but I don't know how just sitting at home.
Given that my site appears to lack the "simple" presentation of the vulnerability, AND that the tech write ups (and scanning tools so far available) appear not to apply to my site, I would like to know:
1) How I can properly scan my site for the vulnerability from a web CLIENT (which is how a hacker would see my site)
2) Some sense as to what steps to take next, as the published steps seem not to apply.
Sep 20, 2010 04:04 PM|joshuaperry|LINK
If you're already returning a 200 every time instead of a 404 or 500, you are already as protected as you can be short of encrypting your web.config since the exploit relies on the different error responses to be effective. The work-around from Mr. Guthrie
actually changes all the 404s and 500s to a 200, and that's why it is effective.