Exchange/Outlook Autodiscover Bug Exposed $100K Email Passwords

Guardicore Security Researcher, Amit Serper identified a critical vulnerability in Microsoft’s autodiscover- the protocol, which permits for the automatic setup of an email account with only the address and password needed. 

The vulnerability allows attackers who buy domains containing the word “autodiscover,” such as autodiscover.com or autodiscover.co.uk, to capture the clear-text login details of users experiencing network issues (or whose admins incorrectly configured DNS). 

From April 16 through August 25 of this year, Guardicore purchased many similar domains and used them as proof-of-concept credential traps: 

A web server linked to these domains got hundreds of thousands of email credentials in clear text, most of which also operated as Windows Active Directory domain credentials. 

The credentials are sent from clients who request the URL /Autodiscover/autodiscover.xml with an HTTP Basic authentication header that already contains the unfortunate user’s Base64-encoded credentials. 

The various factors contribute to the overall vulnerability like; the Autodiscover protocol’s “backoff and escalate” behaviour when authentication fails, its failure to check Autodiscover servers before giving up user credentials, and its readiness to utilise insecure methods such as HTTP Basic in the first place. 

Failing upward with Autodiscover 

The main task of the Autodiscover protocol is to simplify account configuration—one can depend on a normal user to memorise their email address and password, but years of computing have imparted us that asking them to remember and correctly enter details like POP3 or IMAP4, TLS or SSL, TCP 465 or TCP 587, and the addresses of actual mail servers is several bridges too far. 

By keeping all nonprivate elements of account information on publicly available servers, the Autodiscover protocol enables regular users to configure their own email accounts without assistance. 

When the user creates an Exchange account in Outlook, they provide an email address and a password, such as bob@example.com with password Hunter2.
With the user’s email address in hand, Autodiscover searches for configuration information in a published XML document. It will attempt HTTP and HTTPS connections to the URLs listed below: (Note: contoso is a Microsoftism that refers to a hypothetical domain name rather than a specific domain.)

http(s)://Autodiscover.example.contoso.com/Autodiscover/Autodiscover.xml
http(s)://example.contoso.com/Autodiscover/Autodiscover.xml 

Thus so far, it can be fairly believed that anyone permitted to store resources on example.contoso.com or its Autodiscover subdomain has been given explicit trust by the owner of example.contoso.com. 

However, if these initial connection attempts fail, Autodiscover will back off and attempt to locate resources in a higher-level domain.
In this case, Autodiscover would seek for /Autodiscover/Autodiscover.xml on both contoso.com and Autodiscover.contoso.com. 

If this fails, Autodiscover will attempt to submit email and password information to autodiscover.com itself.
It would be terrible enough if Microsoft controlled autodiscover.com, but the truth is far more complicated. That domain was registered in 2002 and is now held by an unknown individual or organization that is utilizing GoDaddy’s WHOIS privacy shield. 

Guardicore’s Analysis 

Guardicore acquired 96,671 distinct sets of email usernames and passwords in clear text over four months while running its test credential trap. These credentials were obtained from a diverse range of businesses, including publicly listed firms, manufacturers, banks, electricity companies, and others. 

When the Autodiscover protocol fails up from Autodiscover.contoso.com.br to Autodiscover.com.br, the security offered by Contoso’s ownership of its own SSL cert disappears. Whoever purchased Autodiscover.com.br—in this scenario, Guardicore—merely supplies their own certificate, which fulfills TLS warnings despite not being associated with Contoso at all. 

In many situations, Outlook or a similar client will initially present its user’s credentials in a more secure format, such as NTLM. 

Unfortunately, a simple HTTP 401 from the webserver requesting HTTP Basic auth in its place is all that is required, to which the client using Autodiscover will abide (typically without error or warning to the user) and send the credentials in Base64 encoded plain text, completely readable by the web server responding to the Autodiscover request.

Conclusion 

The truly terrible news is that there is no mitigation solution for this Autodiscover issue available to the general public.

If your company’s Autodiscover infrastructure has a bad day, your client will “fail upward,” possibly revealing your credentials. This issue has yet to be patched; according to Microsoft Senior Director Jeff Jones, Guardicore publicly revealed the flaw before reporting it to Microsoft. 

For developers and vendors, the company offered this tip: 

Make sure that when you are implementing the Autodiscover protocol in your product you are not letting it “fail upwards”, meaning that domains such as “Autodiscover.” should never be constructed by the “back-off” algorithm.