Microsoft Exchange Autodiscover security implementation

It is unclear if the Microsoft Exchange’s Autodiscover could be called a vulnerability as of now or whether this must be treated as a gap in the best practices for implementation of Microsoft Exchange’s autodiscover feature. In any case, Amit Serper’s detailed study for Guardicore comes as a shot in the arm for Microsoft’s detractors and reinforces the debate about security on the Microsoft products.

We are not here to debate about whether Microsoft did what it did with the Autodiscover implementation. We will try to explain the security gap in Microsoft Exchange’s Autodiscover feature and try to help you mitigate the risk and close the security gaps in implementing the Autodiscover feature on the MS Exchange.

What is the Autodiscover feature on mail servers like Office 365 and Microsoft Exchange?

Autodiscover is a server side implementation that can be used to help setup email clients automatically. Email clients like Microsoft Outlook offer you an option to auto-configure the mail account using the Autodiscover feature. Many of us have used this feature for the sheer convenience it offers. Your email account would get auto-configured in terms of the mail server details, mail server ports and incoming and outgoing email settings based on the Autodiscover feature.

What is the issue with Autodiscover feature, as reported by Amit?

Autodiscover feature looks to get the initial server configuration of the mail server, be it the Exchange server or any other server. The mail client, like Microsoft Outlook, takes in an Autodiscover request and tries to connect to the business’s mail servers for the initial connection. In making this initial connection, the Autodiscover feature will pull in the server details and populate the server configuration in the email client automatically.

To initiate the connection to your business’s mail server, the mail client sends in autodiscover.xml requests. Infact, if you monitor your server or cloud logs closely, you will see that a huge percentage of your server logs would be full of automated autodiscover.xml requests. When the email client will send in an Autodiscover request, it tries to look for the autodiscover.xml file.

The email client tries to look for the autodiscover.xml on the sub-directory or sub-domain of the business domain. For an email address of [email protected], it will look for Autodiscover file on autodiscover.xyz.com or xyz.com/autodiscover/. While this process goes on internally or within your own domain infrastructure, this is not much of a problem. However, if the Autodiscover settings are not found on the domain, then Microsoft’s Autodiscover feature moves on to the next process to locate the Autodiscover settings outside your domain or corporate network housing the Exchange servers. In doing so, it starts with the backoff procedure. The ‘backoff’ procedure involves looking for Autodiscover on FQDN or fully qualified domain names. Given the fact that there are so many domain extensions available, the Autodiscover feature looks to find the autodiscover.xml file on domain names like:

1. Autodiscover.in
2. Autodiscover.com.au
3. Autodiscover.nz

The request for Autodiscover details goes to an external mail server (using Autodiscover FQDNs like autodiscover.il) that could be hosted on an attacker’s domain. The request goes on to different Autodiscover domains, and the attacker’s server may ask you to authenticate before it sends in the mailbox configuration. In a bid to fetch details of the user’s mailbox configuration, the actual mailbox details and authentication will be shared with the attacker by your mail client. So, you are unaware of the autodiscover exchange that caused the email client of your computer to share your mailbox’s details with an external server that could be owned and operated by a threat player.

A one line summary of the problem is that the Autodiscover requests from your systems may end up being maliciously intercepted by an attacker using a FQDN or fully qualified domain name with Autodiscover first name. Once intercepted, the mail client may share email authentication details of the mailbox with an attacker’s server and even the Windows domain user details, thus compromising your mailbox and possibly, the entire corporate network.

What does Microsoft have to say about the Autodiscover security gap?

Microsoft has released a statement that reads like this –

“We are actively investigating and will take appropriate steps to protect customers,” Jeff Jones, Sr. Director at Microsoft said in a statement. “We are committed to coordinated vulnerability disclosure, an industry standard, collaborative approach that reduces unnecessary risk for customers before issues are made public. Unfortunately, this issue was not reported to us before the researcher marketing team presented it to the media, so we learned of the claims today.” 

In the carefully worded statement, Microsoft seems to indicate that the accepted norm for disclosing vulnerabilities publicly is to do so post a fix for the vulnerability has been assigned. Cascading attacks could target the vulnerabilities and impair infrastructure across the globe, given the fact that Autodiscover is a standard feature used by every other email user.

The key words for us is that the company is investigating the issue. I do not think the fix may be as intricate as it may sound. I also hear Amit’s side that claims that the design flaw in autodiscover has been in existence since 2017 and Microsoft is aware of it. That is a correct posture. But, working with Microsoft would have been the best bet before releasing the details of the study publicly. All of us can have one challenge less in terms of the prevailing security scene across the country.

What is the mitigation for the Autodiscover loophole?

Turn off Autodiscover

Do not use Autodiscover in the interim period, until Microsoft releases a security update for this Autodiscover anomaly. Just block it completely at your network level. Use a good login script to configure email addresses on the email clients automatically.

Microsoft uses a series of methods to initiate Autodiscover requests from the mail client. The five steps used by Microsoft are:

• SCP lookup
• HTTPS root domain query
• HTTPS AutoDiscover domain query
• HTTP redirect method
• SRV record query

You could just create a group policy for the Autodiscover node and deploy it on your Microsoft Exchange server. Full steps on how you could create a group policy that disables one or all of the five methods used by Microsoft for Autodiscover feature on Microsoft Exchange server are mentioned on the following link on Microsoft’s website – https://docs.microsoft.com/en-us/outlook/troubleshoot/profiles-and-accounts/how-to-control-autodiscover-via-group-policy

Block Autodiscover domains on your network

If you cannot disable Autodiscover feature for now, the next simplest fix is to not let the Autodiscover requests leave your network or limit it to the external mail server for your own domain. So, we will allow the Autodiscover requests to reach the internal or external network hosted mail server. Beyond that, we just block any requests going on to the Autodiscover domains. A full list of FQDN that you could block on the firewall of your company can be fetched from the GitHub link posted by Guardicore. In a way, you restrict your Autodiscover requests to work between the email client and your self-hosted or Office 365 hosted or Google hosted email servers.

Disable Basic Authentication on Exchange

As part of hardening of Autodiscover process, disable the ‘Basic Authentication’ on Microsoft Exchange for self-hosted email servers. This will ensure that your domain user details do not end up with the attacker in plain text. Here is how you could disable ‘Basic authentication’ and engage in a better and hardened security protocol for authentication: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online.

Summary –

Understandably, the design flaw of Autodiscover feature leaves a security loophole that could be targeted by users or attackers with malicious intent. The easiest workaround suggested by Amit and Guardicore would work well for most companies and businesses. Just make sure that you are blocking root level domains for Autodiscover on your firewall or network’s peripheral security infrastructure.

We are hopeful for a fix to be released by Microsoft soon enough.

You may like to read more about the security updates published by Microsoft for Windows servers and desktops in the following pages:

• Windows Updates for Windows Servers and Windows desktops