One vulnerability that VA scanners (Nessus et al) find quite readily is the ASP.NET Trace function being enabled. This is not the same thing as the TRACE verb on a web server – it is actually a debug function for .NET based websites. Nessus classifies it as a medium risk vulnerability, and this is one example of a scanner doing the opposite of its normal behaviour and rating something as less serious than it might well turn out to be.
Trace is enabled in IIS’s web.config (for the application, or machine.config for the server) and is either set on each individual page, or generally. The first setting is not one that is going to be accidentally left on (because it adds a table full of log entries to the bottom of the page itself), but the latter is possible. It is enabled like this
Normally when you try to browse to trace.axd on a server in a browser you get a yellow screen error and a message stating that for security reasons the page is only available from the console. Where it gets really scary is if localOnly is set to false – at which point the server starts recording every transaction made into a file which is readable on the server, sometimes without authentication.
Not only can this file contain detailed system calls and parameters, disclosing way more about the internals of the code than an attacker needs to know, but it can also reveal session cookies, and any other data that is sent to/from the server. In one case we had some time ago, a retailer had this enabled on their online shop and was merrily displaying users’ credit card details and the session ids associated with them.
Ensuring that trace enabled is set to false and that custom errors are set to on will make sure this information is not being disclosed – but this is one ‘medium’ vulnerability it is wise to take seriously.