Just for completeness, consolidating here the answers from what-is-the-non-standard-http-verb-debug-used-for-in-asp-net-iis: (thanks @Mark, @Jørn).
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.
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.
It uses Windows authentication, and DCOM to actually do the debugging though (obviously, if you're allowing RPC traffic, then you've got bigger problems) or of any exploits. UrlScan does block it by default, though.
However, 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.