Exchange/Outlook autodiscover bug exposed 100,000+ email passwords
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:
- Autodiscover.com.br
- Autodiscover.com.cn
- Autodiscover.com.co
- Autodiscover.es
- Autodiscover.fr
- Autodiscover.in
- Autodiscover.it
- Autodiscover.sg
- Autodiscover.uk
- Autodiscover.xyz
- Autodiscover.online
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, bob@example.contoso.com with password Hunter2.
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.)
- http(s)://Autodiscover.example.contoso.com/Autodiscover/Autodiscover.xml
- http(s)://example.contoso.com/Autodiscover/Autodiscover.xml
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 /Autodiscover/Autodiscover.xml on 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 autodiscover.com itself.
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.
Guardicore’s results
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.contoso.com.br to 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.
Conclusions
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.
For more technical detail, we highly recommend Guardicore’s own blog post as well as Microsoft’s own Autodiscover documentation.
Listing image by Just_Super via Getty Images