Internal IP/ Host Name Disclosure In Server Redirects

Hi! Hope you guys are doing well. The vulnerability which I'm going to explain today is present in wild and is often neglected by the pen-testers as either they are not aware of its existence or they neglect it as individually it doesn't pose any security risk. But when it comes to impact calculation even if the server is behind a firewall or NAT, an attacker can see internal IP of the remote host and this may be used to further attacks.

Note: Credit goes to @Mudit Punia for finding this issue and making me aware of this.

Description: 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/ Host name. Typically, this is done by sending a blank host header which can result in the server sending a redirect using its own IP address/ internal host name as the host name.

Different test cases for forcing application to reveal Internal IP/ Host name:

Case 1: Internal IP Disclosure

Figure 1: Normal request and response of the application

Figure 2: Application disclosing Internal IP in response

Case 2: Internal Host Name Disclosure

Figure 1: Normal request and response of the application

Figure 2: Application disclosing Internal Host Name in response

Thus, we can see that when the request is sent as HTTP 1.0 with a blank host header, the server may respond with its own internal IP/ Host name in the Location Header. This results in the internal IP address /Host name of the Real Server being exposed.

Impact: Disclosure of Internal IP address/ Host name can be used by an attacker to exploit the server, its hosting network, etc. This helps an attacker to chain multiple issues and launch specific attacks against internal environment of the application.

Recommendation: There is not usually any good reason to disclose the internal IP addresses used within an organization's infrastructure. It is recommended to mask or obfuscate the private addresses. Cases where the address is being returned in HTTP header, there header should be configured to mask the private address. Depending on the type of server, there should be a way to prevent the Internal IP address/ Host name from ever being sent in 302 Redirects on the Server. However, if this is not possible, a new rule can be created & used to block any Internal IP addresses/ Host name 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.

Note: 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).

Limitations: There are several limitations to the Header Modification Rule, few of them are given below. Thanks @Lokesh Sharma for pointing this out.

1. It will work only when Internal IP is disclosed, it won't work in cases where Internal Host Name is disclosed.
2. It will only work when Internal IP starts with HTTPS.
3. Better solution is to compare against server_name and making sure that Location header starts with server_name and cases where this condition fails, replace it with server_name. This method will also work in cases where multiple domains are hosted on the same server.
4. It won't work in those cases where Internal IP or Host Name is being disclosed in error pages i.e. 4XX pages.

References: Mitigating Against Internal IP Address/Domain Name Disclosure in Real Server Redirects

That's all for this article friends. Please feel free to give feedback or suggest new topics!