Implementing Exchange DownloadDomain Security

In the field, I’m seeing multiple customers that are struggling to implement the DownloadDomain feature. It does require a little prep work and it is not as simple as just running a single command in Exchange to flip the setting on.

In order to mitigate and issue with OWA, it is necessary to create an additional CAS namespace that will be used for downloading attachments from OWA.  This will require planning and potentially collaboration with multiple teams in the organisation.  For example, if there is a reverse proxy appliance in front of Exchange then that appliance will need to be re-configured.  The new CAS namespace will need to be added.  Potentially a new TLS certificate may need to be installed on the appliance, but that will depend on the original CAS namespace and certificate configuration.

The issue is documented in CVE-2021-1730 where it states:

A spoofing vulnerability exists in Microsoft Exchange Server which could result in an attack that would allow a malicious actor to impersonate the user.

This update addresses this vulnerability.

To prevent these types of attacks, Microsoft recommends customers to download inline images from different DNS domains than the rest of OWA.  The Download Domains feature helps to mitigate Cross Site Request Forgery (CSRF) attacks since the OWA and Download Domains URLs are separate domains.  A call to attachments.owa.tailspintoys.ca that was initiated from owa.tailspintoys.ca is treated as a cross-site request and cookies are sent under certain conditions.

Process Overview

As noted above, we need to create an additional CAS namespace.  For example these are the things you will need:

• ensure you fully understand the starting CAS namespace configuration, determine f separate naemspaces are used internally vs externally
• create a new internal namespace for the download domain feature.  Repeate if a separate one is used externall, else you can use the same with a split-namepspace
• in the example below it is called attachments.owa.tailspintoys.ca
• document the new namespace
• create the internal DNS entry for the namespace
• create the external DNS entry for the namespace
• add the namespace to the TLS certificate.  This will mean re-issuing the certificate (if you do not have a wildcard cert)
• Update all servers with the new certificate
• Update all load balancers, reverse proxy or security appliances with the new certificate
• Update OWA virtual directories with the DownloadDomains internal and external namespace
• Update all publishing infrastructure so it is aware of the namespace
• Set OrganizationConfig DownloadDomains to $True

Note that the suggested domain of attachments.owa.domain.com or downloaddomain.owa.domain.com is just a suggestion.  Though chances are it will go the same way as legacy.contoso.com from the Exchange 2003 to 2010 migration days and the name is used literally.  The same applies for BESAdmin service accounts.  I still see those zombie accounts out there!

If you do have a wildcard certificate, ensure that your new CAS namespace is covered.  Wildcard certificates are not like the movie inception and descend many levels deep.  Far from it.

As an example, if we issue this wildcard certificate for  *.contoso.com  it will cover these namespaces:

• mail.contoso.com
• autodiscover.contoso.com
• attachments.contoso.com
• downloads.contoso.com

It will NOT cover the next level of inception.  These namespaces will NOT work with the *.contoso.com certificate:

• mail.emea.contoso.com
• downloads.mail.contoso.com
• attachments.mail.contoso.com

As always, CAS is 95% planning and 5% implementation.

Lab Starting Point

In the below screenshots you see the Tailspintoys Canada lab.  This is an Exchange 2019 and 2016 based lab. All servers have the latest CU and Exchange security updates installed at the time of writing.

For this environment the OWA URL is owa.tailspintoys.ca.

The new DownloadDomains URL will be attachments.owa.tailspintoys.ca.

Let's start by reviewing the existing configuration.

First up, the Organization Configuration is shown so we can see if the EnableDownloadDomains feature is configured.  It is not enabled by default.

Get-OrganizationConfig | FL *domain*

Then we can check for the actual URL which is configured on the servers.

Get-OwaVirtualDirectory | Select Server, ExternalDownloadHostName

Alternatively to view both internal and external DownloadHost names:

Get-OwaVirtualDirectory | Select Server, ExternalDownloadHostName, InternalDownloadHostName

Note that neither the internal or external DownloadHostName is populated by default.

Implementing The Change

Update TLS Certificate

First up, we need to create the new TLS certificate.  This assumes you are NOT using a certificate with a sub domain that could be easily reused on the existing certificate.  Follow your regular process to request and install the certificate.

Ensure the new certificate is installed correctly on all Exchange servers.

Note that this may mean that you have to replace the current certificate on other devices such as a reverse proxy or load balancer.  This will depend upon your environment, so check your build documentation etc.  You may also need to re-run the Exchange Hybrid Wizard.

Create DNS Records

In this example we are using split DNS with the same namespaces internally and externally.  This means that we need to create the new record in both the internal and external DNS zones.  That way the name is resolved correctly if the user is inside or outside the firewall.

In this lab the new CAS namespace that will be used for DownloadDomains will be:

attachments.tailspintoys.ca

Once that has been created, ensure that the name resolution is in place.

Update OWA Virtual Directories

Now that we have the new TLS certificate installed, and associated DNS record we can update the individual virtual directories on Exchange.  Since the Set-OwaVirtualDirectory cmdlet has poor filtering, this is why the Get-OwaVirtualDirectory is used to pipe all instances to the Set cmdlet.

As noted earlier, they are $Null by default and are empty.

We will set the ExternalDownloadHostName then the InternalDownloadHostName values.

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -ExternalDownloadHostName attachments.owa.tailspintoys.ca

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InternalDownloadHostName attachments.owa.tailspintoys.ca

Then finally enable the feature at the organization level using

Set-OrganizationConfig –EnableDownloadDomains $True

Apply Change

Since the configuration has changed, we need to ensure that AD has replicated then get IIS to process the change.  Since most organisations want change to occur in defined windows, we do not want to hang around and wait for the change to eventually be applied.  Let’s force the change to be processed so we can control the change and have the opportunity to test and verify it during the defined maintenance window.

There are a few ways we could get IIS to process the change.  For example:

• Restart server
• IISReset
• Restart OWA App pool

You chose what you prefer.

Then we need to ensure the change has taken effect.

Verify Change

There are a couple of ways to determine in the change was successful.

If we open up a OWA for a mailbox, and select an email which has an in-line attachment then we can view the URL used to render the attachment.  If all went well, this will feature our new download domain.

Option 1

We will inspect the source of the message, and as expected you can see that the image source is the new namespace.

Option 2

You can also view the image URL by using the browser’s “copy image link” feature.
Same as above, find a message that has an in-line attachment and copy the URL .

Then you can paste it into notepad and ensure that it uses the new CAS namespace.

This is an example from the tailspintoys.ca  lab for the above box shot.  The new namespace is highlighted.

https://attachments.owa.tailspintoys.ca/owa/Local-1@tailspintoys.ca/service.svc/s/GetFileAttachment?id=AAM<sniped>

Bootnote

If you obtained a new TLS certificate ensure that you replace all of the existing instances of that certificate.  That will include all Exchange servers, but there may be other devices that will also need to be updated.

The Exchange admins may not have access to devices such as load balancers, Web Application Firewalls, reverse proxy appliances etc.  and if the  certificates are not updated this can lead to issues.  Ensure that you work with those teams to make sure that the necessary changes are made to allow any new namespace to function.  If not, then the user experience will be impacted.

Cheers,
Rhoderick