Windows

•

A recent vulnerability scan using McAfees Secure Scan, one of those automated scans often used for PCI-DSS self certification, advised that the Windows Server in question disclosed the internal I.P. address.

We have run both McAfee's Secure Scan and Comodo's Hacker Guardian. McAfee charges for one I.P. at about USD$300, which is about the price Hacker Guardian asks for about 10. However, McAfee's report is much more thorough, and goes into much more detail into information disclosure vulnerabilities, where as hacker guardian sticks to the standard Mitre CVE issues.

Vulnerability

McAfee reports the IIS information disclosure as follows. This was a Windows 2008 R2 server running IIS 7.5

Threat
Some Web servers contain a vulnerability giving remote attackers the ability to attain your internal IP address or internal network name.

An attacker connected to a host on your network using HTTPS (typically on port 443) could craft a specially formed GET request from the Web server resulting in a 3XX Object Moved error message containing the internal IP address or internal network name of the Web server.

A target host using HTTP may also be vulnerable to this issue.

McAfee gave a link to clear detail on how to resolve the issue, which I later found worked perfectly. though that was no fun, I wanted to see the vulnerability first hand.

Some further digging into the supplied links, and after coming across this kemp article, I found that the issue occurred under the following conditions:

  • HTTP Version is 1.0
  • Host Headers are empty
  • A 3xx Action in Invoked.

Testing the exploit

I started with the following curl command:

curl https://www.website.com.au/ -v -l --http1.0 --Header "Host: "

This was based off the kemp article above, and has one major issue. For an empty host be to send via curl, the header value should be "Host:", not "Host: ". The cURL Man Page confirms this,

However, after adding this the vulnerability did not reveal itself.

The missing factor was outlined in this Juniper Vulnerability page.

This is achieved by browsing a web site using HTTPS, and locating a valid web directory

I first tried adding a folder to the curl request, however forms authentication resulted in every folder resulting in a redirect back to the forms login page.

I then tried a publicly accessible folder, used to store files meant for public access. This gave me the internal IP address, as clear as day, in the location header.

Therefore, 4 conditions were required in the end:

  • HTTP Version is 1.0
  • Host Headers are empty
  • A 3xx Action in Invoked.
  • The URL includes a folder

The final curl command that found it was in the following format.

curl https://www.website.com.au/folder -v -l --http1.0 --Header "Host:"

Patching the Hole

As per the McAfee report. this MS blog page details how to resolve the issues in IIS 7+.

appcmd.exe set config -section:system.webServer/serverRuntime /alternateHostName:"serverName" /commit:apphost

Where "serverName" is what you wish to show in place of the I.P. address.

As it is less than ideal to run a command that patches a vulnerability, without understanding exactly what it is doing, I verified the applicationHost.config, which sits under the %Windows%\System32\inetsrv\config\ folder,

As expected  the following was added to the applicationHost.config file.

<serverRuntime alternateHostName="serverName" />

•

Like any software raised on linux, even where it runs under a JVM like Elasticsearch, running it on windows bring to light a few quirks.

One of the most common Elastic Search Environment Variables is ES_HEAP_SIZE, shown in the System variable panel below.

With the default set to 1GB, setting this is often done early on, though note the following 2 gotcha's in windows.

  1. After you set the ES_HEAP_SIZE, you need to re-install the service. Restarting ES won't do it.
  2. If you are restarting the service from the command line, remember to open a new CMD window after setting the Environment Variables, A stale window will hold the old value, (or have none if none was set) and restarting the service in that cmd.exe session won't update the heap size.

Here is how you can ensure that your Environment Variable took under the JVM section via /_nodes/stats?pretty=true

Also, remember to not cross 31Gb!

http://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html