Securing access to Microsoft Exchange 2013 EAC

The coexistence of the Exchange 2013 Administration Console (EAC) with the other Exchange website virtual directories represents a considerable security vulnerability for any organization that installs it using the out-of-box defaults. Since most organizations need Outlook Anywhere and EWS to be Web-facing, and usually OWA too, the EAC will also end up being publicly accessible – inadvisable security practice in itself, even more so for another important reason that I will explain. The EAC uses the IIS Virtual Directory /ecp which has other non-admin functions for normal email users, so it is not really desirable to try to limit access to it. Besides, an Exchange Service Pack or Cumulative Update is quite likely to reset the Virtual Directory settings and permissions later anyway. Now that the Exchange Management Console application has been retired, it is not practical to completely disable EAC unless you especially enjoy PowerShell, so we need to find a way to harden the server.

The problem is that the Domain’s built-in Administrator account does not have the Active Directory account lockout policy applied to it, so the EAC can simply be brute-force attacked if this account has access to the EAC or indeed OWA. One mitigation against this vulnerability is to make sure that the domain’s built-in Administrator account has all Exchange remote access disabled, and that a separate user account is used for day-to-day management. It is probably best to also disable the mailbox entirely to reduce the chance of someone accidentally re-enabling any of this in the EAC later.

Set-CASMailbox Administrator -OWAEnabled $false -ECPEnabled $false -ActiveSyncEnabled $false -OWAforDevicesEnabled $false -EwsEnabled $false -ImapEnabled $false -PopEnabled $false

Disable-Mailbox Administrator

Note that merely disabling the Administrator mailbox (without the first step of amending the access) offers no protection – the ECP can still be accessed and you won’t be able to use the Set-CASMailbox cmdlet, since no mailbox object exists.

There is still a big security problem though. Since the authentication is being handled by IIS the usernames are not being screened, and so a user encounters an HTTP 403 error when they are barred from using ECP but have been authenticated successfully (even if you remove the Administrator account from the ‘Organization Management’ Exchange Security Group), so the brute-force attacker can saturate the server with logon requests and precisely determine when they have cracked the Domain Admin credentials. Although these credentials cannot be used remotely if the above mitigation steps have been taken, the attacker can still use them later to fully penetrate the organization via other means: social engineering, physically entering the building etc.

Microsoft’s recommended solution is to use Powershell to designate a whole CAS server’s ECP Virtual Directory for Internal use only (keeping ECP disabled on the public facing CAS servers). This is totally unworkable for most small-to-medium enterprises though.

The only valid mitigation therefore is to restrict access to the ECP virtual directory to local subnets – something that we had wanted to avoid, and which on first sight looks impossible (since it’s a Virtual Directory, not a Website that we can re-bind to a new IP address and firewall more restrictively). In order to do this you will need to install the IIS Security Feature ‘IP and Domain Restrictions’:

Install-Feature-IIS-IP-Domain-Security

For the Default Web Site’s /ecp Virtual Directory (which is the public one), configure IP Address and Domain Restrictions:

IIS-IP-Domain-Security-Settings

In there, click Edit Feature Settings… (in the right-hand pane) and set ‘Access for unspecified clients’ to Deny. Then use Add Allow Entry to define your permitted IP ranges.

As I mentioned in the opening paragraph though this will need to be checked after Service Packs and Cumulative Updates are applied to the Exchange Server, in case this configuration is lost.

In fact the same precautions against brute force attack of the Administrator account would also apply to earlier versions of Exchange, and for VPN connectivity – i.e. when AD accounts are being used for any public facing authentication, the built-in Administrator should never be granted remote access.

Advertisements

9 thoughts on “Securing access to Microsoft Exchange 2013 EAC

  1. shutupsquare

    Hey thanks for this, I am looking into hardening our OWA instance, I have implemented the IP and Domain Restrictions’ and only allowed the local subnet to access the virtual directory /ecp however I’m not getting a 403 when accessing the /ecp instead I get an initial redirect to /owa/ for the login then after succesful login I get redirected back to the login form. Which means that a bad guy could still bruteforce the login creds ( but they cannot login to ecp with them ) Should I not be getting a 403 on request for /ecp ? Thanks.

    Reply
  2. Mike

    Limiting the Access range in IIS direct for Exchange was and will never be an options to choose. This has allways in longterm lead to problems that are almost unable to diagnose. For the Brute Force you capture this with an IPS-Filter (Like Fortigate) on the WAN and if you are concerned internal then you buy a Firewall between LAN/Server. /ECP /OWA hangs together close sind 2010. Also other management components and VDIRS.

    Reply
  3. benl

    Thank you for this post. While other say this is impossible, it does sort of work. I got the same issue as shutupsquare. Going to the ECP virtual directory would redirect to OWA, even though HTTP redirect was not setup. Also It seemed to affect internal and external users. If anyone has any other ideas it’d be nice to know.

    Reply
  4. lauferb

    I got the same thing as shutupsquare. ecp redirects to owa for internal and external users, it should 403 for external and work for internal. Also it says EAC on the OWA page when it redirects.

    Reply
  5. Andrew Lauwira

    It actually works, even though you see the login screen as a redirect to OWA. Just try to login. Even if you supply correct username and password, it won’t let you in, because the internal ecp virtual directory refuses the page.

    Reply
  6. JJnewtoE2k13

    thanks! i restricted ECP internal access only but I also found that owa access from internet cannot change password and etc options which I want to allow user change password in owa during internet access but restrict ecp access from internet; any idea how to do?

    Reply
    1. patters Post author

      Thanks for the link. It’ll be useful for people landing on this page. When I wrote this post (over 2 years ago) Exchange 2013 was brand new and this information wasn’t available.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s