Contents:
A discovery that discloses a Microsoft Exchange Autodiscover bug has been made recently. The vulnerability found in the Autodiscover feature led to massive data leakage of 100 000 Windows domains’ credentials.
The Guardicore’s AVP security researcher, by his name Amit Serper, addressed this bug in a new report, revealing what the cause of the data leakage is: the Autodiscover protocol’s improper implementation.
The background of this issue can be traced back to 2017 when Shape Security researchers published a paper, detailing how implementations in the Autodiscover in the email clients on email phones can lead to such leaks of information. It is about CVE-2016-9940, CVE-2017-2414 patched backed then. As Amit Serper mentions in his report:
The vulnerabilities disclosed by Shape Security were patched, yet, here we are in 2021 with a significantly larger threat landscape, dealing with the exact same problem only with more third-party applications outside of email clients. These applications are exposing their users to the same risks. We have initiated responsible disclosure processes with some of the vendors affected. More details on that aspect will be released as a second part to this paper.
What Is Microsoft Exchange Autodiscover?
The Autodiscover is basically a feature present in the Microsoft Exchange. What this makes is to enable the automatic configuration of a user’s email client with the settings of their company that are predefined.
What is an email client? Briefly described, it can also be named email reader or MUA (message user agent) and stands for that computer program that allows the access and management of a user’s email. For instance, Microsoft Outlook.
Therefore, the process chain follows this order: an Exchange user inserts his credentials into the mail client to connect and what the mail client does next is the authentication attempt to different URLs of Exchange Autodiscover.
And this is the moment when the credentials, during this process of authentication, are also redirected automatically to those Autodiscover URLs. These URLs are basically generated from that e-mail address used for configuration in the e-mail client.
According to the researcher, who tested the Autodiscover feature, the process behind stays like this:
The client parses the email address supplied by the user – amit@example.com.
The client then tries to build an Autodiscover URL based on the email address with the following format:
- https://Autodiscover.example.com/Autodiscover/Autodiscover.xml
- http://Autodiscover.example.com/Autodiscover/Autodiscover.xml
- https://example.com/Autodiscover/Autodiscover.xml
- http://example.com/Autodiscover/Autodiscover.xml
In the case that none of these URLs are responding, Autodiscover will start its “back-off” procedure. This “back-off” mechanism is the culprit of this leak because it is always trying to resolve the Autodiscover portion of the domain and it will always try to “fail up,” so to speak.
Microsoft Exchange Autodiscover Bug: Detailing How the Leak Happens
According to BleepingComputer, this back-off procedure the researcher mentioned, in order to make the authentication possible, tries to create supplementary URLs to authenticate to. For example autodiscover.[tld] domain (in this the TLD comes from the domain of the user).
This is where the Microsoft Exchange Autodiscover Bug lies, as the feature is incorrectly implemented making mail clients perform authentications to domains that are not trustworthy.
And since the company related to the email user is not the owner of this domain and the fact that, as I mentioned above, when trying to authenticate, the URLs automatically receive the user’s credentials, these two things will allow the domain owner to access and gather the names and passwords sent to those URLs.
Meaning, the result of the next attempt to build an autodiscover URL would be: http://autodiscover.com/autodiscover/autodiscover.xml. This means that whoever owns autodiscover.com will receive all of the requests that can’t reach the original domain.
Putting the Theory to Test
Researchers validated the theory above described in Serper’s report by buying some domains: Autodiscover.com.br – Brazil, Autodiscover.com.cn – China, Autodiscover.com.co – Columbia, Autodiscover.es – Spain, Autodiscover.fr – France, Autodiscover.in – India, Autodiscover.it – Italy, Autodiscover.sg – Singapore, Autodiscover.uk – United Kingdom, Autodiscover.xyz and Autodiscover.online.
They attributed these purchased domains to a web server that was in their control and they could observe how Autodiscover endpoint requests came from different IP addresses, clients, and domains.
Mitigation Measures
In his report, Serper made some recommendations on how companies can reduce the threat of this Microsoft Exchange Autodiscover bug.
Organizations should make devices unable to connect to Autodiscover.[tld] domains by blocking them. Access rules can be created by making use of this text file the researcher made. This consists of all Autodiscover domains which can be utilized to create this access.
Basic authentication should be also disabled.
From Microsoft’s side, the one who addressed the issue was Jeff Jones, Sr. Director, who declared that:
We are actively investigating and will take appropriate steps to protect customers. We are committed to coordinated vulnerability disclosure, an industry standard, collaborative approach that reduces unnecessary risk for customers before issues are made public. Unfortunately, this issue was not reported to us before the researcher marketing team presented it to the media, so we learned of the claims today.
Hi! My name is Andra and I am a passionate writer interested in a variety of topics. I am curious about the cybersecurity world and what I want to achieve through what I write is to keep you curious too!
The improper implementation is in the client. The client is the one attempting to reach the Exchange server. Amit from Guardicore did not discover this; he simply tested for what was already known since 2016/17: https://www.blackhat.com/docs/asia-17/materials/asia-17-Nesterov-All-Your-Emails-Belong-To-Us-Exploiting-Vulnerable-Email-Clients-Via-Domain-Name-Collision-wp.pdf
And he did not improperly disclose a vulnerability, as some have claimed, this has had a CVE since 2016/17.