How to Mitigate Against Internal IP Address/Domain Name Disclosure In Real Server Redirects

Web servers may be configured to send redirects to client requests. In some cases, specially crafted queries may be used to expose internal IP addresses. Typically this is done by sending a blank host header which can result in the server sending a redirect using its own IP address as the host name.

An example configuration is provided below:

The Virtual IP address is 10.140.0.223 and the Real Server is defined as 10.140.0.22.

The domain name resolution is as follows:

www.domain.com 10.140.0.223 

 

The Real Server (10.140.0.22) uses IIS Web Services and is configured to redirect requests to /redirectURL.

 

Problem

In the normal case when we connect to the server, it responds with the correct redirect based on the host name sent in the initial query:

 

Test with normal http 1.0 request.

kemptech@LC-161:~$ curl http://www.domain.com -v -l --http1.0
> GET / HTTP/1.0
> User-Agent: curl/7.35.0
> Host: www.domain.com
> Accept: */*

< HTTP/1.1 302 Redirect
< Content-Type: text/html; charset=UTF-8
< Location: http://www.domain.com/redirectURL
* Server Microsoft-IIS/8.5 is not blacklisted
< Server: Microsoft-IIS/8.5
< Date: Fri, 06 Feb 2015 15:06:21 GMT
< Connection: close
< Content-Length: 156
<
<head><title>Document Moved</title></head>
* Closing connection 0
<body><h1>Object Moved</h1>This document may be found <a HREF="http://www.domain.com/redirectURL">here</a></body>

 

However, if the request is sent as HTTP 1.0 with a blank host header, the server may respond with its own internal IP (10.140.0.222) in the Location Header. This results in the internal IP address of the Real Server being exposed.

 

Test: HTTP 1.0 request sent with empty Host Header.

kemptech@LC-161:~$ curl http://www.domain.com -v -l --http1.0 --Header 'Host: '
> GET / HTTP/1.0
> User-Agent: curl/7.35.0
> Accept: */*

< HTTP/1.1 302 Redirect
< Content-Type: text/html; charset=UTF-8
< Location: http://10.140.0.222/redirectURL
* Server Microsoft-IIS/8.5 is not blacklisted
< Server: Microsoft-IIS/8.5
< Date: Fri, 06 Feb 2015 15:06:39 GMT
< Connection: close
< Content-Length: 154
<
<head><title>Document Moved</title></head>
* Closing connection 0
<body><h1>Object Moved</h1>This document may be found <a HREF="http://10.140.0.222/redirectURL">here</a></body>kemptech@LC-161:~$

 

Solution

Depending on the server type, there should be a way to prevent the internal IP address from ever being sent in 302 Redirects on the Server. However, if this is not possible, a LoadMaster Content Rule may be used to block any internal IP addresses from being exposed in a 302 redirect.

 

Header modification rule:
Rule Type: Replace Header
Header: Location
Match String: /(https?:\/\/)([0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3})(?::\d+)?(\/.*)/
Replacement: \1www.domain.com\3

This can then be added to the Virtual Service: Virtual Services > View/Modify Services > Advanced Properties > HTTP Header Modifications > Response Rules.

 

The internal address is now hidden in all 302 Redirect Responses and replaced with www.domain.com.

 

Result 

kemptech@LC-161:~$ curl http://www.domain.com -v -l --http1.0 --Header 'Host: '
> GET / HTTP/1.0
> User-Agent: curl/7.35.0
> Accept: */*
>
< HTTP/1.1 302 Redirect
< Content-Type: text/html; charset=UTF-8
< Location: http://www.domain.com/redirectURL
* Server Microsoft-IIS/8.5 is not blacklisted
< Server: Microsoft-IIS/8.5
< Date: Fri, 06 Feb 2015 15:20:40 GMT
< Connection: close
< Content-Length: 154
<
<head><title>Document Moved</title></head>
* Closing connection 0
<body><h1>Object Moved</h1>This document may be found <a HREF="http://10.140.0.222/redirectURL">here</a></body>

 The internal ip might be exposed for the port 80 Redirect on the LM, this can be mitigated by putting the FQDN in Redirect box instead of the %H (https://FQDN%s).

Was this article helpful?

3 out of 5 found this helpful

Comments

Avatar
systemsadministration

The last line in this article says: "The internal ip might be exposed for the port 80 Redirect on the LM, this can be mitigated by putting the FQDN in Redirect box instead of the %H (https://FQDN%s)."

However, putting the FQDN in the redirect box isn't an option for me, as I have a bunch of sub-vs in the :443 VS that each listen to a unique host header.

Avatar
Brian Morich

Hello,

Another way of mitigating this issue when adding a FQDN to the "302 redirect" is not possible is by utilizing a content matching rule and two SubVSs on your port 80 redirect Virtual Service in order to block connection attempts with empty host headers. This rule must be a content matching rule and include a Header Field of 'Host' and a Match String of /.*/ this rule should be applied to one SubVS while the default rule should be applied to the other SubVS. For the SubVS with the match rule created we can add the 302 redirect as https://%h%s and for the SubVS with the default rule we will change the 302 to a 403, thus blocking requests made with empty host headers. If you have any further questions I would recommend opening up a case with support