Why private IP address is still revealed on IIS server even after applying fix 834141


Customer has a 3rd party security scanning tool that is complaining that IIS6 is revealing its internal IP address in HTTP responses. The customer already has KB834141 configured and installed. We found that it is due to some ISAPI filter configured on IIS server.


 


Symptom:


===================


When Microsoft Internet Information Services (IIS) receives a GET request without a host header, the Web server may reveal the IP address of the server in the content-location field or the location field in the TCP header in the response. This problem may occur if the request does not contain a specific page or if IIS must redirect the original request to another page.


 


For example:


IIS6 server would return the following response to client suppose us telnet to IIS server and input the command “HEAD / HTTP/1.0”:


 


HTTP/1.1 200 OK


Content-Length: 1433


Content-Type: text/html


Content-Location: http://172.23.***.***/iisstart.htm


Last-Modified: Fri, 21 Feb 2003 23:48:30 GMT


Accept-Ranges: bytes


ETag: “09b60bc3dac21:274”


Server: Microsoft-IIS/6.0


X-Powered-By: ASP.NET


Date: Tue, 17 Feb 2009 08:52:12 GMT


Connection: close


 


After applying the hotfix “FIX: IP address is revealed in the content-location field in the TCP header in IIS 6.0” http://support.microsoft.com/?id=834141 and configuring UseHostName and SetHostName as the KB suggested, the response should be something like:


 


HTTP/1.1 200 OK


Content-Length: 1433


Content-Type: text/html


Content-Location: http://ykchenwebsite/iisstart.htm


Last-Modified: Fri, 21 Feb 2003 23:48:30 GMT


Accept-Ranges: bytes


ETag: “09b60bc3dac21:271”


Server: Microsoft-IIS/6.0


X-Powered-By: ASP.NET


Date: Tue, 17 Feb 2009 08:45:54 GMT


Connection: close


 


However, it still returned the private IP address on customer’s IIS server.


 


Root Cause:


===============


We checked customer’s IIS web server’s metabase.xml and I noticed the following lines:


 


<IIsWebVirtualDir           Location =”/LM/W3SVC/1/ROOT”


                        AccessFlags=”AccessRead | AccessScript”


                        AppFriendlyName=”Default Application”


                        AppIsolated=”2″


                        AppPoolId=”DefaultAppPool”


                        AppRoot=”/LM/W3SVC/1/ROOT”


                        DefaultDoc=”Default.aspx,Default.htm,Default.asp,index.htm,iisstart.htm,index.cfm”


                        Path=”c:\inetpub\wwwroot”


                        ScriptMaps=”.asp,C:\WINDOWS\system32\inetsrv\asp.dll,5,GET,HEAD,POST,TRACE


                                    .cer,C:\WINDOWS\system32\inetsrv\asp.dll,5,GET,HEAD,POST,TRACE


                                    .cdx,C:\WINDOWS\system32\inetsrv\asp.dll,5,GET,HEAD,POST,TRACE


                                    .asa,C:\WINDOWS\system32\inetsrv\asp.dll,5,GET,HEAD,POST,TRACE


                                    .idc,C:\WINDOWS\system32\inetsrv\httpodbc.dll,5,GET,POST


                                    .shtm,C:\WINDOWS\system32\inetsrv\ssinc.dll,5,GET,POST


                                    .shtml,C:\WINDOWS\system32\inetsrv\ssinc.dll,5,GET,POST


                                    .stm,C:\WINDOWS\system32\inetsrv\ssinc.dll,5,GET,POST


                                    *,C:\CFusionMX7\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll,3


 


This is a wildcard mapping which means any HTTP request comes to IIS server will be handled by the ISAPI filter C:\CFusionMX7\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll first.


 


So I downloaded Macromedia ColdFusion MX7 Trial version and install it on my test IIS server for double check. This time I found that the internal IP address is *leaked* on my side also:


 


HTTP/1.1 200 OK


Content-Length: 1433


Content-Type: text/html


Content-Location: http://172.23.***.***/iisstart.htm


Last-Modified: Fri, 21 Feb 2003 23:48:30 GMT


Accept-Ranges: bytes


ETag: “09b60bc3dac21:274”


Server: Microsoft-IIS/6.0


X-Powered-By: ASP.NET


Date: Tue, 17 Feb 2009 08:52:12 GMT


Connection: close


 


Then I *removed* this wildcard script mapping on my test IIS server:


 


Open IIS manager -> Right click Web Sites -> Click Properties -> Home Directory -> Configuration… -> Select “C:\CFusionMX7\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll” in Wildcard application maps and *Remove* it -> Click OK to make the change take effect.


 


Now the SetHostName value is returned as expected:


 


HTTP/1.1 200 OK


Content-Length: 1433


Content-Type: text/html


Content-Location: http://ykchenwebsite/iisstart.htm


Last-Modified: Fri, 21 Feb 2003 23:48:30 GMT


Accept-Ranges: bytes


ETag: “09b60bc3dac21:271”


Server: Microsoft-IIS/6.0


X-Powered-By: ASP.NET


Date: Tue, 17 Feb 2009 08:45:54 GMT


Connection: close


 


The problem could be reproduced after me adding the wildcard maps C:\CFusionMX7\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll back to IIS configuration.


 


As we know, if an HTTP request that does not include an HTTP:Host header value is sent to IIS, and there is an ISAPI filter configured in IIS that makes a call to GetServerVariables(servername) during the SF_NOTIFY_PREPROC_HEADERS event, the IP address will always be returned instead of the server’s hostname (or the value set in SetHostName). This is because PREPROC_HEADERS is called before IIS has read the configuration data (in this case either UseHostName or SetHostName), therefore there is no other choice but to return the IP address. This behavior only occurs if the HTTP request doesn’t send an HTTP:Host header value; if the request contains a Host value, then SERVER_NAME will contain the value of the client’s Host header. Web browsers using HTTP/1.1 are not supposed to omit the Host header value, so this scenario is much more likely to be seen where the HTTP request is generated and sent by something other than a web browser (or if a web browser is using HTTP/1.0)


 


We can either ensure the HTTP client application includes a HTTP:Host header value in its request. (Actually HTTP:Host headers are required by the HTTP/1.1 specifications (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23) or write an ISAPI filter that blocks and rejects any incoming HTTP requests that do not include an HTTP:Host header.


 


Regards,


 


Yong Kang Chen

Comments (0)

Skip to main content