Exposed Management Consoles

Exposed Management Consoles - A look at Microsoft Exchange

In most organizations where we find Microsoft Exchange, we find Outlook Web Access (OWA) open to the internet. Generally, external access to OWA and ActiveSync is allowed when mobile users are accessing Exchange email. This is all hosted using Microsoft's Internet Information Services (IIS). What many administrators may not realize is what other websites are running by default and may be exposed to the internet as well.

The Necessity of External Access: OWA and ActiveSync

Microsoft Exchange uses different server roles to determine what services a server offers and hosts. The Client Access role generally is what provides services that give users access to mail, including OWA and ActiveSync. In simple environments, Administrators will typically forward HTTPS, tcp/443, through the firewall to the Exchange Client Access Server (CAS).

A Deep Dive into Default Websites and Applications in Exchange 2013 CAS

Let's take a look at the default website and the Applications that are setup in IIS by default on a typical Exchange 2013 CAS:

The ActiveSync and owa applications are expected and normally what are used by users accessing email from the Internet. Some of the others are a little more interesting.

The ECP Application: An Innovation with Implications

The ECP Application is the Exchange Control Panel, which is a new feature introduced in Exchange 2010 and later. This web application allows administrators to manage the Exchange infrastructure via a web console. By default, this is accessible to anyone over the internet when you make OWA available.

Risks Associated with Exposing Web-based Administrative Tools

Even better, with Exchange 2013, the local Exchange Management Console was done away with, leaving administrators with only the Exchange Powershell console and the web-based ECP as options to manage Exchange.

How to Disable ECP: A Walkthrough

For those not comfortable exposing a web based administrative tool to the world, the following command issued at an Exchange Powershell prompt will disable ECP:

Set-EcpVirtualDirectory -identity"exch01\ecp (default web site)" -AdminEnabled $false

The downside of this is that when you disable it, you disable it locally on the server as well, meaning you will have to use Powershell cmdlets to perform even the most basic tasks. (Better brush up on your Powershell!)

The PowerShell Entry: The Hiden Entry Point

The other interesting web application that is exposed by default is the PowerShell entry. This is a remote Powershell interface over HTTPS which means that anyone with credentials can gain an interactive Powershell prompt on your Exchange server using the following commands:

$UserCredential = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange Client Access server>/PowerShell/ -Authentication Kerberos -Credential $UserCredential

Unchecked Access: The Risks of Exposed Management Interfaces

If the credentials provided are basic domain user credentials, then you can only run a limited set of read-only type cmdlets. If you provide admin level credentials, then you can do just about anything a local administrator can do. Again, all of this is accessible by default when you forward 443 to an internal Exchange 2010 or later server.

Striking the Balance: Security vs Functionality in Recent Exchange Versions

The takeaway here is to always know what you are exposing to untrusted networks. These management interfaces are dangerous when accessible from the internet. Where they cannot be restricted, you should be logging and monitoring access to these URLs.

Microsoft has done a pretty good job over the last few years of following the"off by default" security practice, however in recent versions of Exchange, functionality and ease of management have made security best practices take a back seat.

Placing Security First: Best Practices for Exchange Website Access

Integrating an admin level console into the OWA website is just a bad idea. Make sure you are familiar with what is published in the default Exchange website and restrict access wherever you can.

Authored By: Jeremy Johnson, CISSP, MCSA