Security researcher Amit Serper of Guardicore discovered a severe flaw in Microsoft’s autodiscover—the protocol which allows automagical configuration of an email account with only the address and password required. The flaw allows attackers who purchase domains named “autodiscover”—for example autodiscover.com, or autodiscover.co.uk—to intercept the clear-text account credentials of users who are having network difficulty (or whose admins incorrectly configured DNS).
Guardicore purchased several such domains and operated them as proof-of-concept credential traps from April 16 to August 25 of this year:
A web server connected to these domains received hundreds of thousands of email credentials—many of which also double as Windows Active Directory domain credentials—in clear text. The credentials are sent from clients which request the URL
/Autodiscover/autodiscover.xml, with an HTTP Basic authentication header which already includes the hapless user’s Base64-encoded credentials.
Three major flaws contribute to the overall vulnerability: the Autodiscover protocol’s “backoff and escalate” behavior when authentication fails, its failure to validate Autodiscover servers prior to giving up user credentials, and its willingness to use insecure mechanisms such as HTTP Basic in the first place.
Failing upward with autodiscover
The Autodiscover protocol’s real job is the simplification of account configuration—you can perhaps rely on a normal user to remember their email address and password, but decades of computing have taught us that asking them to remember and properly enter details like POP3 or IMAP4, TLS or SSL, TCP 465 or TCP 587, and the addresses of actual mail servers are several bridges too far.
The Autodiscover protocol allows normal users to configure their own email accounts without help, by storing all of the nonprivate portions of account configuration on publicly accessible servers. When you set up an Exchange account in Outlook, you feed it an email address and a password: for example,
firstname.lastname@example.org with password
Armed with the user’s email address, Autodiscover sets about finding configuration information in a published XML document. It will try both HTTP and HTTPS connections, to the following URLs. (Note:
contoso is a Microsoftism, representing an example domain name rather than any specific domain.)
So far, so good—we can reasonably assume that anyone allowed to place resources in either
example.contoso.com or its
Autodiscover subdomain has been granted explicit trust by the owner of
example.contoso.com itself. Unfortunately, if these initial connection attempts fail, Autodiscover will back off and try to find resources at a higher-level domain.
In this case, Autodiscover’s next step would be to look for
contoso.com itself, as well as
Autodiscover.contoso.com. If this fails, Autodiscover fails upward yet again—this time sending email and password information to
This would be bad enough if Microsoft owned
autodiscover.com—but the reality is considerably murkier. That domain was originally registered in 2002 and is currently owned by an unknown individual or organization using GoDaddy’s WHOIS privacy shield.
In the approximately four months Guardicore ran its test credential trap, it collected 96,671 unique sets of email username and passwords in clear text. These credentials came from a wide array of organizations—publicly traded companies, manufacturers, banks, power companies, and more.
Affected users don’t see HTTPS/TLS errors in Outlook—when the Autodiscover protocol fails up from
Autodiscover.com.br, the protection afforded by
contoso‘s ownership of its own SSL cert vanishes. Whoever purchased
Autodiscover.com.br—in this case, Guardicore—simply provides their own certificate, which satisfies TLS warnings despite not belonging to
contoso at all.
In many cases, the Outlook or similar client will offer its user’s credentials initially in a more secure format, such as
NTLM. Unfortunately, a simple HTTP 401 from the web server requesting HTTP Basic auth in its place is all that’s necessary—upon which the client using Autodiscover will comply (typically without error or warning to the user) and send the credentials in Base64 encoded plain text, completely readable by the web server answering the Autodiscover request.
The truly bad news here is that, from the general public’s perspective, there is no mitigation strategy for this Autodiscover bug. If your organization’s Autodiscover infrastructure is having a bad day, your client will “fail upward” as described, potentially exposing your credentials. This flaw has not yet been patched—according to Microsoft Senior Director Jeff Jones, Guardicore disclosed the flaw publicly prior to reporting it to Microsoft.
If you’re a network administrator, you can mitigate the issue by refusing DNS requests for Autodiscover domains—if every request to resolve a domain beginning in “Autodiscover” is blocked, the Autodiscover protocol won’t be able to leak credentials. Even then, you must be careful: you might be tempted to “block” such requests by returning
127.0.0.1, but this might allow a clever user to discover someone else’s email and/or Active Directory credentials, if they can trick the target into logging into the user’s PC.
If you’re an application developer, the fix is simpler: don’t implement the flawed part of the Autodiscover spec in the first place. If your application never attempts to authenticate against an “upstream” domain in the first place, it won’t leak your users’ credentials via Autodiscover.
Listing image by Just_Super via Getty Images