How to Mitigate Microsoft Exchange Autodiscover Protocol Flaw That Leaks User Credentials
In this article, I explain how the recently discovered flaw in the Exchange Server Autodiscover protocol can leak user credentials. And how to mitigate the issue in your environment.
Microsoft Exchange Server Autodiscover protocol leaks thousands of user credentials
Researchers at security company Guardicore have released details of a security issue in the Autodiscover protocol that Microsoft Exchange Server clients, like Outlook, use for automatic configuration.
In the paper, Amit Serper reveals how Guardicore purchased multiple Autodiscover domains with a top-level domain (TLD) suffix. Domains purchased by Guardicore included:
The domains were configured to connect to a web server under Guardicore’s control. And between April 16th, 2021 to August 25th, 2021 Guardicore says it captured:
- 372,072 Windows domain credentials in total.
- 96,671 UNIQUE credentials that leaked from various applications such as Microsoft Outlook, mobile email clients and other applications interfacing with Microsoft’s Exchange server.
How the Exchange Server Autodiscover protocol works
When users set up an Exchange email client for the first time, they are asked to provide their email address and password. Using the domain name from the user’s email address, Autodiscover constructs a URL to try and automatically discover the settings required to connect to the user’s Exchange Server.
Autodiscover constructs addresses in the format shown below, hoping to find the Autodiscover.xml file containing settings necessary to connect the email client to the user’s Exchange Server. If a user provides an email address like [email protected], then Autodiscover will construct links like so:
If none of the constructed URLs respond, Autodiscover switches to a ‘back-off’ procedure that attempts to ‘fail-up’. For instance, if http://example.com/Autodiscover/Autodiscover.xml doesn’t work, Autodiscover will try http://Autodiscover.com/Autodiscover/Autodiscover.xml instead.
In short, if you owned Autodiscover.com, you might be able to capture the credentials of users trying to connect to Exchange Server; specifically, those with email clients using the POX XML protocol implementation of Autodiscover.
The HTTP authentication process
Guardicore goes on to say about the requests it intercepted that “The most notable thing about these requests was that they requested the relative path of /Autodiscover/Autodiscover.xml with the Authorization header already populated with credentials in HTTP basic authentication.”
Web requests should follow the HTTP authentication process, which makes sure requests are not sent blindly and pre-authenticated. The client software should request access to secured resources first and then wait for the server to respond before sending authentication information.
Many Exchange Server email clients implement Autodiscover in such a way that there is no check to see if the Autodiscover.xml file is available on the remote server before asking to make an authenticated connection to the server.
When Exchange Server email clients don’t get a successful response from the server, they are downgraded to use HTTP Basic Authentication. This could allow an attacker to see the victim’s credentials in their web server log files.
How to mitigate the Exchange Server Autodiscover attack
While use of HTTP Basic Authentication is an issue, the crux of this attack is the way Autodiscover is often implemented in Exchange Server email clients, including Outlook.
Block Autodiscover domains at the firewall
While Microsoft hasn’t yet issued any mitigation advice, Guardicore recommends blocking Autodiscover domains, like Autodiscover.com and Autodiscover.com.cn, at your firewall.
Add Autodiscover domains to the local hosts file on each endpoint
Another way to block access to Autodiscover domains is to add them to the local hosts file on each of your endpoints; essentially creating a blackhole and ensuring that email clients can’t resolve to rogue Autodiscover domains.
Guardicore has prepared a text file that points all possible Autodiscover domain variations back to the local host (127.0.0.1). You can find the file on GitHub here.
Guardicore recommends developers disable the ‘fail-up’ part of the Autodiscover protocol
Guardicore recommends developers disable the ‘fail-up’ part of the Autodiscover protocol in their products. But while we wait for a response from Microsoft, and for vendors to potentially change the way Autodiscover is implemented in their software, Guardicore has provided a couple of workarounds that should protect against credential theft.
Steve Goodman, Petri contributor and Exchange expert with more than 20 years’ experience says: “So far, reproducing the Autodiscover flaw using Microsoft clients, like Outlook, has proved difficult. Therefore whilst it’s important to check your DNS configuration for Autodiscover is correct, and be mindful of general DNS-based attacks, it is important not to overreact. Better time and focus is spent on making sure the wider issue of credential harvesting is more difficult by adopting multi-factor authentication and better still, passwordless sign-in to either Microsoft 365 or Exchange Server using Hybrid Modern Authentication.”
For more details on the Autodiscover issue, check out Guardicore’s paper here.
More in Exchange Server
Microsoft to Ship Some Exchange Server Security Updates in .EXE Packages
May 11, 2022 | Rabia Noureen
M365 Changelog: Exchange Transport Rule Report moving to the new Exchange Admin Center (EAC) from the Security and Compliance Center
Apr 22, 2022 | Petri Staff
Hive Ransomware Group Attacks Vulnerable Microsoft Exchange Servers
Apr 22, 2022 | Rabia Noureen
M365 Changelog: (Updated) Change to mailbox forwarding behavior coming to Exchange Online
Apr 21, 2022 | Petri Staff
M365 Changelog: (Updated) Microsoft Defender for Office 365: Updates to URL Protection Report
Apr 21, 2022 | Petri Staff
M365 Changelog: Feature update: Modern Dynamic Distribution Groups
Apr 14, 2022 | Petri Staff
Most popular on petri