What is the non-standard HTTP verb "DEBUG" used for in ASP.NET/IIS?

Question

I am reading a report from a "web application security" company, whom have been scanning a few websites of the company I am working for. It appears from the report - which seems written without any human involvement - that several attempts where made to break our sites using requests like this:

DEBUG /some_path/some_unexisting_file.aspx Accept: */* More-Headers: ... 

The result from our server surprises me:

HTTP/1.1 200 OK Headers: ... 

As DEBUG does not seem to be mentioned anywhere in the HTTP 1.1 specification I would have expected the result to be 400 Bad Request or 405 Method Not Allowed.

From earlier question on SO, I have learned that the DEBUG verb is used in some sort of remote debugging of ASP.NET applications, but not many details are available in that question or its answers.

Exactly what is the DEBUG verb used for? Why does the application answer 200 OK for invalid URLs when using this verb? Is this a security problem? Are there any potential security problems surrounding the DEBUG verb, that ASP.NET developers/system administrators should be aware of?

Any insights/advice/references will be appreciated.

Answer 1

As hinted by Mark, the DEBUG verb is used to start/stop remote debugging sessions. More specifically, a DEBUG request can contain a Command header with value start-debug and stop-debug, but the actual debugging is done via an RPC protocol.

So, why does a security scanner perform such request? It appears that poking an ASP.NET website with the DEBUG requests can be used to reveal if the web.config has <compilation debug="true">. The test can be performed with telnet, WFetch or similar, by sending a request like this:

 DEBUG /foo.aspx HTTP/1.0 Accept: */* Host: www.example.com Command: stop-debug 

Depending on whether debugging is enabled or not, you will get either 200 OK or 403 Forbidden.

It is generally accepted that you should never have <compilation debug="true"/> in a production environment, as it has serious implications on the performance of the website. I am not sure if having debugging enabled opens any new attack vectors, unless RPC traffic is enabled as well, in which case you have more serious problems anyway (cf. Mark's answer). Any additional insights on the security perspective will be greatly appreciated.

There is an easy way to avoid accidentally getting <compilation debug="true"/> in production websites. Simply, add <deployment retail="true"/> to your machine.config.

Apparently, having <deployment retail="true"/> in the machine.config is not equal to setting <compilation debug="false"/> in this particular case. The result from throwing DEBUG requests against the web application can only be changed with the latter. Mind-boggling!

Answer 2

http://support.microsoft.com/kb/937523

When the client tries to automatically attach the debugger in an ASP.NET 2.0 application, the client sends a HTTP request that contains the DEBUG verb. This HTTP request is used to verify that the process of the application is running and to select the correct process to attach.

It uses Windows authentication, and DCOM to actually do the debugging though - so I'm not aware of the DEBUG verb itself being a large security risk (obviously, if you're allowing RPC traffic, then you've got bigger problems) or of any exploits. UrlScan does block it by default, though.

I'd probably put a network sniffer on it to check what information leaks though.