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

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.

Answer 2

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 3

@Mark, @Jørn, thanks for the excellent info, I had also been curious about this.
As for the your report, from a security point of view, there is one other aspect (besides RPC and debugging support) - attack surface. I's kind of a low-risk item, but best practice is generally to minimize any external interfaces that you dont need, so that potential attackers have less room to maneuver, and have lower probability of finding that one critical flaw.
Btw, having debug compilation turned on has other effects, as it does leave more traces, pdb files, etc around. Not necessarily high risk, but still... (not to mention PCI compliance, if this is relevant.)