reader comments
55 with 37 posters participating, including story author
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.
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.
blog post as well as Microsoft’s own Autodiscover documentation.
Listing image by Just_Super via Getty Images
