.NET Handler Enumeration
Table of Contents
Overview
Vulnerability scanners frequently produce issues such as .NET Handler Enumeration. This can allow an attacker to determine all handlers enabled on the server. The value of this is extremely minimal and we categorize the risk of this as a ‘Note’.
The root cause of this issue is most often errors such as the following:
Technical Description
Microsoft .NET supports a number of application extensions. As an example, Nessus checks for the following:
- .ashx – Generic handler
- .aspx – ASP.NET page handler
- .asmx – Web service handler
- .rem – Remoting handler
- .soap – SOAP handler
We can analyze the detection plugin by looking at a Nessus nasl file:
list = make_list(".ashx", ".aspx", ".asmx", ".rem", ".soap");
We can then see the plugin make a request for a random file with each extension:
foreach ext (list)
{
u ="/" + rand_str(length:8) + ext;
r = http_send_recv3(method: "GET", item: u, port:port);
It then checks each response for descriptive errors:
if ( "[FileNotFoundException]:" >< r[2] ||
"[HttpException]:" >< r[2] ||
"System.Runtime.Remoting.RemotingException:" >< r[2] ||
egrep(pattern:"^Location:.*aspxerrorpath=", string:r[1]) )
{
By seeing this, we can confirm the enumeration is made possible by either of two things:
Any error containing FileNotFoundException
, HttpException
, System.Runtime.Remoting.RemotingException
, or a URL redirection matching the regex ^Location:.*aspxerrorpath=
.
Solution
You can prevent most instances of .NET handler enumeration by disabling verbose error messages in .NET. This can be set in the web.config
with the following:
<configuration>
<system.web>
<customErrors mode="On" defaultRedirect="~/Error.aspx" redirectMode="ResponseRewrite"/>
[..]
</system.web>
[..]
</configuration>
There is not always a true solution to prevent someone from enumerating handlers. Other errors and custom functionality may also confirm that the handler is supported. However, this should prevent most vulnerability scanners from raising the issue.