10

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)?
Scott Pack
  • 15,167
  • 5
  • 61
  • 91
David Stratton
  • 2,646
  • 2
  • 20
  • 36

2 Answers2

6

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.

Community
  • 1
Abe Miessler
  • 8,155
  • 10
  • 44
  • 72
  • Easy way to test on Chrome. Go to the site. Then run this in the console window of the developer tools (should return 403 forbidden):fetch('/', {method: 'DEBUG'}).then(function(response) {console.log(response.status);}); – mhenry1384 Jul 14 '17 at 16:40
1

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

Ogglas
  • 677
  • 4
  • 12
  • 26