Lack of Technical Detail Undermines Researcher’s Report
A certain amount of hot air has been expelled following the publication of an article by Guardicore researcher Amit Serper describing how the company gathered the credentials of 96,671 unique Windows domain credentials by exploiting a purported Autodiscover flaw. On a practical level, I am sanguine about the report because:
- I have been unable to reproduce the reported behavior using Outlook for Windows (click to run) against Exchange Online using either Outlook’s Autodiscover test feature or when adding a new account to Outlook. I can’t find a single other person whom I would consider an expert in Exchange technology who has replicated the issue either.
- The foundation of the argument appears to be based on a research paper presented at Black Hat Asia in 2017 which describes flaws in the Samsung and Apple iOS mail clients. These problems were fixed years ago. The article says that the “exact same problem” exists but for “more third-party applications outside of email clients.” This implies that Microsoft software is not involved.
- The lack of technical information in the article describing the exact configurations used for testing and the details of the vulnerable clients used by those people whose domain credentials were captured.
Given these relevant facts, we don’t know whether this is a problem relating to a single email client (or family of clients) with a flawed implementation of Autodiscover or a general problem affecting all clients which use Autodiscover. We don’t know if the researcher tested if the problem affects Exchange Server on-premises or Exchange Online. And in the case of Exchange Server, what versions (including cumulative updates) were tested and does the version of Windows make a difference?
The article notes that the author’s company has “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.”
According to a tweet from Catalin Cimpanu, Microsoft was blindsided by the disclosure as they only learned about it when Guardicore published their article (Figure 1).
We shall have to wait for the next round of attention-seeking publicity from Guardicore to learn who are the culpable parties. No doubt a similar amount of hyperbole will erupt.
Exchange Online Unaffected
The use of the term “domain credentials” and “Microsoft’s Exchange server” in the report makes me think that the work is based on on-premises servers. Without comprehensive technical details about the client and server configuration used to reproduce the reported weakness, it’s impossible to prove that the issue is real in both a practical and theoretical sense.
All we can do is observe the network traffic created when clients use Autodiscover. The report said that credentials were gathered from “Microsoft Outlook, mobile email clients and other applications,” so let’s see what happens using Outlook for Windows version 2109 (build 14430.20148). I used the standard option to add a new account to an Outlook profile. The attempt failed when Autodiscover could not locate the service for the account’s domain (Figure 2). There’s no evidence I can see of any “back off” algorithm taking any action after Autodiscover found that the domain doesn’t exist.
The same happens when running Outlook’s Autodiscover test. A failure as expected.
What Might Be Happening
It could be the case that a particular DNS configuration for Autodiscover is required to open the door to the vulnerability which is then exposed by specific builds of clients (including Outlook add-ons). The reference to third-party applications points to ISV products which use Autodiscover. Most third-party email clients consume Autodiscover to discover the URLs they need to use to connect to a user’s mailbox, so that could be a long list (probably but not definitely excluding Samsung and Apple, who fixed the problem reported in 2017). The simple fact is we don’t know because of the remarkable lack of detail about the tested configuration revealed by Guardicore. All of which makes me think that this report is simply intended to highlight Guardicore’s Centra product. No more and no less.
If you’re running Exchange server on-premises, you should check your Autodiscover settings to make sure that they comply with Microsoft guidance. And make sure that you know what clients consume Autodiscover, just in case there’s a real flaw lurking here that attackers can exploit across a range of Exchange server versions and clients.
Thank you for your great article Tony.
I can only confirm that also, we were unable to open up a similar autodiscover behavior in our network environment with outlook 2010 – 2019. As well, we checked the connection logs from our outlook programs on firewalls. We did not find any trace of connection with the domains autodiscover.com or autodiscover.pl in our case. We also tested some mobile clients, here also no traces of the “back-off” procedure.
I think that autodiscover “back-off” could be just a big fake and rumour 🙂
Regards,
IT Specialist
For client, one of their screenshots of logs did say this version. But yes, not much detail.
(Windows+NT+10.0;+Microsoft+Outlook+16.0.13901;+Pro)
https://www.guardicore.com/labs/autodiscovering-the-great-leak/
And 16.0.9029 in another screenshot
Yep. But we don’t know if the Outlook client is connected to Exchange Online or on-premises. We also don’t know the configuration of the Outlook client (what add-ins are loaded and if those add-ins might use EWS to interact with Autodiscover). We also don’t know the repro steps. i.e. is this something an average user might do or is it something that you need to take very precise steps in a certain order with a specific software configuration…
there is a problem: the lengthy article fails to mention you have to use a email like a.b@fr.
If the user uses a address with only a top level domain part.
I did not use an outlook client but the Microsoft.Exchange.WebServices.dll and only checked in wireshark.
I do not check how real outlook clients behave.
That’s interesting… how did you discover that very important point?
I worked backwards. I simply thought: how can such a request be created.
I suspect the domain information was deduced from the ip address of the request.
So the problem seems to be:
user enters a false mail domain
you own the mail domain
you have the credentials of the user (if the user uses basic authentication)
The interesting thing here is that your finding might point to a flaw in EWS that has been incorporated into third-party products (like Outlook add-ins, and indeed, some Outlook components) to create the issue. I am going to contact Microsoft to advise them of this and we’ll see what they say (probably a response that they’re checking things out).
I asked him this question on Twitter, and… radio silence. https://twitter.com/joesuffceren/status/1441003406865358858?s=19
I like to think the best of everyone, but the lack of detail in the article is just so disappointing in terms of understanding what’s really going on here.
Probably someone just looking for their 15 minutes of fame.
Well, we’ll see when they reveal the data they have and the mechanisms used to capture the information…