Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know how to check this setting in code, and I know where to look in the web.config, but I can't seem to find information on how a vulnerability scanner like Qualys would detect this.

I've considered the following, but I have no way of knowing if my guesses are any good:

  • Is there an http header that is sent from the web server when Debug=true?
  • Is the scanner/software intentionally causing an error and detecting debug information reflected back to the client?
  • Is the software looking for long-running requests (since debug mode effectively lengthens response times before a timeout occurs)?
share|improve this question
    
I don't think that is true. See my answer. – Abe Miessler Oct 1 '13 at 19:44
    
@AbeMiessler I stand corrected :) – NULLZ Oct 2 '13 at 0:16
up vote 5 down vote accepted

Setting the debug attribute will not result in a different error page. Custom error pages are handled in the web.config in the configuration/system.web/customErrors node. Some info.

One possibility is that the scanner is detecting this by looking at the Cache-Control http header. This header will return private when you are in debug mode and public when you are not. There is a good article that goes into some of this which can be found here.

A more likely possibility is that they are making a DEBUG request to the site and checking to see wether it is returning 200 or 403. There is a good SO post on this here.

While having the debug attribute set to true can cause performance problems, it's not the only thing that can cause performance problems, so it seems like using this method would generate a lot of false positives.

share|improve this answer
    
Thank you. That is quite helpful! – David Oct 1 '13 at 21:14

You can actually check this @AbeMiessler

Normal HTTP-request:

 GET / HTTP/1.1
 Host: www.test.com
 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:28.0) Gecko/20100101 Firefox/28.0
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Encoding: gzip, deflate
 Cookie: Token=dfe31f692334663ae9d466662be6d3
 Connection: keep-alive
  • We set the path to "/Test.aspx" or some other filename that does not exist
  • Add the HTTP header "Command: stop-debug"
  • Method set to "DEBUG"
  • Remove, if present, the parameter 'ReturnUrl'

Modified request:

 DEBUG /Test.aspx HTTP/1.1 HTTP/1.1
 Cookie: Token=dfe31f692334663ae9d466662be6d3
 Content-Length: 0
 Accept: */*
 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64;)
 Host: www.test.com
 Command: stop-debug

Response if debug is enabled:

HTTP/1.1 200 OK
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Mon, 14 Apr 2014 12:19:45 GMT
Content-Length: 2

OK

enter image description here

You can read more about it here: https://www.owasp.org/index.php/ASP.NET_Misconfigurations

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.