IIS Request Filtering to block HTTP Verbs (For example Trace)

The issue

Request Filtering is a built-in security feature that was introduced in Internet Information Services (IIS) 7.0. This can be used to block specific verbs like "Trace".

When request filtering blocks an HTTP request, IIS 7 will return an HTTP 404 error to the client and log the HTTP status with a unique substatus that identifies the reason that the request was denied. Verb Denied.

HTTP Substatus	Description
404.5	URL Sequence Denied
404.6	Verb Denied
404.7	File Extension Denied
404.8	Hidden Namespace
404.1	Request Header Too Long
404.11	URL Double Escaped
404.12	URL Has High Bit Chars
404.13	Content Length Too Large
404.14	URL Too Long
404.15	Query String Too Long
404.18	Query String Sequence Denied
404.19	Denied by Filtering Rule

How to block

To block specific verbs, all you need to do is modify your web.config and under <system.webServer> à <security> add the following:
<requestFiltering>

    <verbs applyToWebDAV="false">

         <add verb="TRACE" allowed="false" />

    </verbs>

</requestFiltering>

OR

Step 1: Open IIS Manager

Step 2: Navigate to site & look for "Request Filtering"

Step 3: Navigate to HTTP Verbs & Deny TRACE

Verification of the issue (when bound to 443 over https)

Here we will attempt to check if the HTTP Trace method has been disabled on IIS.

1. To complete this step you will need a machine with openssl. 
2. You will need to log into the machine from step a using putty or an equivalent terminal. 
3. Create a connection to the secure server via openssl using s_client 
   openssl s_client -connect dev.server.supportpoint.com:443 -servername dev.server.supportpoint.com -host dev.server.supportpoint.com -port 443
   
4. Next mimic a TRACE connection
   
   
   
   by entering:
   TRACE /  HTTP/1.0
   Connection: dev.server.supportpoint.com 
5. As you can notice here, the result returned is 404. 
6. Check the IIS Access Logs for 404.6 (When request filtering blocks an HTTP request, IIS 7 will return an HTTP 404 error to the client and log the HTTP status with a unique substatus that identifies the reason that the request was denied. In our case, 404.6 is Verb Denied)
1. Find the Application Id

1. Go to the IIS Manager
2. Right-click your site à Manage Website à Advanced Settings 
3. Your ID is an integer value
4. 
   
2. Navigate to logs directory & open last modified log file
1. Go to %SystemDrive%\inetpub\logs\LogFiles
2. Then find the folder based on your Application ID. 
1. If your ID is 1, then go to W3SVC1. 
2. If your ID is 2, then go to W3SVC2. 
3. … and so on
3. Open the Last Modifed Log file
3. Search the log file for your TRACE request.
4. You should now be able to see that the error logged is 404.6 

Part 1: Async requests in ASP.NET MVC 4 when working with Session [Understanding the problem]

This is a multi-part post dedicated to Async requests in ASP.NET MVC 4 when working with Session. Be sure to follow this series starting from the first post to gain a clear understanding.

Our Objective

A part of the application that we're developing at Panviva required us to download an xml file generated by our legacy system via a web service call to the existing application server. While the task at hand was was easy to accomplish, I noticed that the time it took to generate the file could take a few minutes. Additionally it blocked the user from making any other requests while it processed. I know, YIKES!!

Of course its not acceptable cause while that request responded, the user in that session could pretty much do nothing else.

How web servers respond

Its important to understand how the web server responds to requests.

On the web server, the .NET Framework maintains a pool of threads that are used to service ASP.NET requests. When a request arrives, a thread from the pool is dispatched to process that request. If the request is processed synchronously, the thread that processes the request is busy while the request is being processed, and that thread cannot service another request.

This might not be a problem, because the thread pool can be made large enough to accommodate many busy threads. However, the number of threads in the thread pool is limited (the default maximum for .NET 4.5 is 5,000). In large applications with high concurrency of  long-running requests, all available threads might be busy. This condition is known as thread starvation. When this condition is reached, the web server queues requests. [Info Src Link]

The problem

So looks like it was Thread Starvation that was causing the issue ... OR WAS IT?? *Insert Dramatic Pause*

Find out more in my next post here! (Spoiler Alert: Turns out it wasn't Thread Starvation)

Internet Information Services(IIS) reveals its real or internal IP Address

In the ever changing world of global data communications, inexpensive Internet connections, and fast-paced software development, security is becoming more and more of an issue. Security is now a basic requirement because global computing is inherently insecure.

Keeping that in mind, we recently ran our flagship product through a security audit. It was such a helpful exercise in tying-off any remaining lose ends in our application in terms of application security. 

Based on the security audit report, there was a relatively minor issue that appeared when accessing the /images directory of our application. Turns out that the Location response header of the 301 request returns an Internal IP address. The issue is detailed below.

---

Issue reported

Internet Information Services (IIS) may reveal its real or internal IP address in the Location header via a request to the /images directory. The value returned whilst pen testing is https://10.0.0.10/images.

---

The risk

Information regarding internal IP address ranges is usually hidden from internet facing systems and can provide an attacker with useful information about internal network structure which can be later used in a targeted attack. 

---

The recommendation

As a matter of best practice, internal information should be removed or masked.

---

Understanding the Issue

When the /images directory is requested, IIS ensures that /images directory has “Directory Browsing” enabled. If it is not enabled and the directory does not have a Default.html/htm page within the directory, a “Forbidden” page needs to be shown.

When the request method used is HTTP/1.0, the Location response header of the 301 request returns an Internal IP address. This needs to be mitigated! 

In terms of HTTP Headers, the following 2 request, responses are made:

• Response Code 301 /images => /images/
• Response Code 403 Forbidden

The actual interactions between the browser and server are listed below.

* Response Code 301 /images => /images/

The request

Remote Address	10.0.0.10: 443
Request URL	https://dev-2008-iis01.pv.local/images
Request Method	GET
Status Code	301 Moved Permanently

Request headers

Accept	text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding	gzip,deflate,sdch
Accept-Language	en-US,en;q=0.8
Connection	keep-alive
Cookie	ASP.NET_SessionId=e5hlhemgbpcu0a3k0dphke5y; __RequestVerificationToken=ufS2rtMQMEHuRRQdV8umKRyJF4LMN4Pt9tNbF2QEDxQhvLWlZiycwD_vYNVlUwi6858t5-m8oLvW1CppLT1VuXVPeLE1
Host	development-server-iis.local
User-Agent	Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36

Response headers

Content-Length	162
Content-Type	text/html; charset=UTF-8
Date	Tue, 22 Jul 2014 03:27:31 GMT
Location	https://development-server-iis.local/images
Server	Microsoft-IIS/7.5
X-Powered-By	ASP.NET

* Response Code 403 Forbidden

The request

Remote Address	10.0.0.10:443
Request URL	https://development-server-iis.local/images/
Request Method	GET
Status Code	403 Forbidden

Request headers

Accept	text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding	gzip,deflate,sdch
Accept-Language	en-US,en;q=0.8
Connection	keep-alive
Cookie	ASP.NET_SessionId=e5hlhemgbpcu0a3k0dphke5y; __RequestVerificationToken=ufS2rtMQMEHuRRQdV8umKRyJF4LMN4Pt9tNbF2QEDxQhvLWlZiycwD_vYNVlUwi6858t5-m8oLvW1CppLT1VuXVPeLE1
Host	development-server-iis.local
User-Agent	Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36

Response headers

Content-Length	1233
Content-Type	text/html
Date	Tue, 22 Jul 2014 04:0:16 GMT
Server	Microsoft-IIS/7.5
X-Powered-By	ASP.NET

Verification of the exploit

As you saw in the initial response header from the server, the Location header (highlighted in red) does not actually reveal an IP address (which is what we want).

This is deceiving as it turns out, IIS may reveal the internal IP Address if the request method is HTTP/1.0 instead of HTTP/1.1

To verify this issue, I used https://development-server-iis.local/images/. As this issue is reproducible in HTTP/1.0, we can verify it via TELNET.Using TELNET, make the request as follows:

telnet /images HTTP/1.0

The following Response is received:

---

The resolution

As IIS server sometimes leaks its internal IP address in a header field, to combat it we can specify the host name to use for redirection. To do so, we will use “ServerRuntime”.

The <serverRuntime> element configures the following settings that are related to the Internet Information Services (IIS) 7 server runtime:

• Setting the enabled attribute to true will configure IIS 7 to serve content on the URL where the <serverRuntime> element is configured; setting the enabled attribute to false will configure IIS 7 to not serve content for that URL.
• The alternateHostName attribute specifies a host name that is different from the computer name in the HTTP Content-location head

Note: This is compatible in the following versions:

Version	Notes
IIS 8.5	The <serverRuntime> element was not modified in IIS 8.5.
IIS 8.0	The <serverRuntime> element was not modified in IIS 8.0.
IIS 7.5	The authenticatedUserOverride attribute was added in IIS 7.5.
IIS 7.0	The <serverRuntime> element was introduced in IIS 7.0.
IIS 6.0	The <serverRuntime> element replaces the following IIS 6.0 metabase properties: SetHostName MaxRequestEntityAllowed UploadReadAheadSize

Information you need

Before you commence, you will need to know the 

Name of website

This is visible in “Internet Information Services Manager” (inetmgr)

As you can see, in our case, the name of the Website is “WebTier”

Host Name

In our case, the name of the host was “development-server-iis.local”

Steps to resolve

1. Log into the server that hosts the Web Tier of Support Point application as an Administrator and open an administrator command prompt.
2. Navigate to AppCmd.exe (is located in the %systemroot%\system32\inetsrv\)
3. Using AppCmd enable server runtime for your Application using the following command
   appcmd.exe set config "WebTier" -section:system.webServer/serverRuntime /enabled:"True" /commit:apphost (Note: Here you will need to replace WebTier with the name of your website.)
4. Using AppCmd enable server runtime for your Application using the following command
   appcmd.exe set config "WebTier" -section:system.webServer/serverRuntime /alternateHostName:"development-server-iis.local" /commit:apphost (Note: Here you will need to replace WebTier with the name of your website. You will also need to replace development-server-iis.local with your host name.)
5. Restart the website via “Internet Information Services Manager” (inetmgr)

---

Verification of Resolution

To verify if this has resolved the issue, we can use telnet in a similar way to when we verified the existence of the exploit. The response received shows that the issue has been resolved.

Using TELNET, make the request as follows:

telnet /images HTTP/1.0

The following Response is received:

---

References: http://www.iis.net/configreference/system.webserver/serverruntime

---