Guardicore security researcher Amit Serper discovered a severe flaw at Microsoft self discovery—The protocol that allows automatic configuration of an email account with only the required address and password. The flaw allows attackers who purchase domains called “autodiscover”, for example autodiscover.com or autodiscover.co.uk, to intercept the clear text account credentials of users who are having difficulties with the network (or whose administrators configured DNS incorrectly).
Guardicore purchased several of these domains and operated them as proof-of-concept credential scams 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 are also duplicated as Windows Active Directory domain credentials, in clear text. The credentials are sent from clients requesting the URL.
/Autodiscover/autodiscover.xml, with an HTTP Basic authentication header that already includes the Base64-encoded credentials of the unlucky user.
Three main flaws contribute to the overall vulnerability: the autodiscovery protocol’s “rollback and escalation” behavior when authentication fails, its failure to validate autodiscover servers before handing over user credentials, and its willingness to use insecure mechanisms. as HTTP Basic in the first place. .
Fail up with automatic discovery
The real job of the autodiscovery protocol is simplifying account setup; Perhaps you can trust a normal user to remember your email address and password, but decades of computing have taught us that asking them to correctly remember and enter details like POP3 or IMAP4, TLS or SSL, TCP 465 or TCP 587, and the addresses from the actual mail servers are several bridges too far.
The auto-discovery protocol allows normal users to set up their own email accounts without help, storing all non-private parts of the account settings on publicly accessible servers. When you set up an Exchange account in Outlook, you give it an email address and password: for example,
[email protected] with password
Armed with the user’s email address, Autodiscover sets up lookup for configuration information in a published XML document. It will test HTTP and HTTPS connections to the following URLs. (Note:
contoso it is a microsism, representing an example domain name instead of a 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 who is allowed to put resources in
example.contoso.com or his
Autodiscover subdomain has been explicitly trusted by the owner of
example.contoso.com itself. Unfortunately, if these initial connection attempts fail, automatic detection will fall back and try to find resources in a top-level domain.
In this case, the next Autodiscover step would be to search
contoso.com himself as well as
Autodiscover.contoso.com. If this fails, the automatic detection fails up one more time, 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 person or organization using GoDaddy’s WHOIS privacy shield.
In the roughly four months that Guardicore ran its test credential trap, it collected 96,671 unique sets of clear text email usernames and passwords. These credentials come from a wide range of organizations: publicly traded companies, manufacturers, banks, power companies, and more.
Affected users do not see HTTPS / TLS errors in Outlook, when autodiscover protocol fails from
Autodiscover.com.br, the protection provided by
contosoownership of your own SSL certificate disappears. Who bought
Autodiscover.com.br—In this case, Guardicore— simply provides its own certificate, which satisfies TLS warnings despite not belonging to
In many cases, Outlook or a similar client will offer your user’s credentials initially in a more secure format, such as
NTLM. Unfortunately, all that is needed is a simple HTTP 401 from the web server requesting HTTP Basic Authentication instead, whereupon the client using Autodiscover will comply (usually without error or warning to the user) and send the credentials in text Base64 encoded raw format. fully readable by the web server responding to the autodiscovery request.
The real bad news here is that, from the perspective of the general public, there are it is there is no mitigation strategy for this autodetect bug. If your organization’s autodiscovery infrastructure is having a bad day, your client will “float up” as described, potentially exposing their credentials. This flaw has not yet been fixed; According to Microsoft Senior Director Jeff Jones, Guardicore disclosed the flaw publicly before informing Microsoft.
If you are a network administrator, you can mitigate the problem by rejecting DNS requests for autodiscover domains; If all requests are blocked to resolve a domain that begins at “Autodiscover”, the autodiscover protocol will not be able to filter credentials. Even then, you should be careful: you might be tempted to “block” such requests by returning
127.0.0.1But this could allow a savvy 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 app developer, the solution is simpler: don’t implement the faulty part of the autodiscover spec first. If your application never tries to authenticate against an “upstream” domain in the first place, it will not filter your users’ credentials through automatic detection.
Image listing by Just_Super via Getty Images