Microsoft Exchange Client Access Server Information Disclosure

If you manage Microsoft Exchange and OWA in your environment and you are undergoing an external penetration test or Cyber Essentials assessment, you will often be faced with the Client Access Server Information Disclosure vulnerability identified by Nessus (https://www.tenable.com/plugins/nessus/77026) or other vulnerability scanners.

Until recently, this vulnerability went unaddressed by Microsoft for versions of IIS after 6.0 and before 10.0. The majority of advice provided by online resources suggests applying the latest patches, but as patches don't exist for version 7.0 to 8.5, this isn't an option.

The best way to address this issue is to understand why the server reveals an internal IP address to begin with. When issuing an HTTP version 1.0 request to the server (for any URI) without the Host header set, the server will refer to itself by its internal IP address. Take for example the following request:

# ncat -ssl owa.mymailserver.net 443 GET / HTTP/1.0

This results in the following response, revealing the internal IP address of the server:

GET / HTTP/1.0
RESPONSE
HTTP/1.1 301 Moved Permanently
Cache-Control: no-cache
Pragma: no-cache
Location: https://192.168.1.30/owa/
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Wed, 05 Sep 2018 14:53:52 GMT

The reason this is possible is because the HTTP 1.0 protocol doesn't require the Host header to be set by the client as part of a request. This is in contrast to HTTP 1.1, which requires the client to specify a host.

Our recommended solution to this issue is to configure the IIS server to deny requests made without the Host header set. This can be achieved through the URL rewrite module for IIS (https://www.iis.net/downloads/microsoft/url-rewrite).

A rule can be created to reset the connection when encountering a request without the Host header, as follows:

Step 1: Open URL Rewrite in the application's control panel.

Step 2: Click Add Rule(s) under Actions:

Step 3: Choose Request blocking rule and click OK:

Step 4: Set Block access based on Host Header, Block requests that do not match the pattern, using regular expression and set the pattern to .+ (i.e. match one or more of any characters):

Step 5: Click OK, the rule should then appear in URL Rewrite:

Connections made via HTTP 1.0 without a Host header will now be rejected by the server. The results can be seen below:

As always, we strongly recommend thoroughly testing any changes made in your environment to ensure that business critical functionality is not interrupted as a result of any changes made.