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).

Microsoft is disappointed not to have been warned of a vulnerability beforehand
Figure 1: Microsoft is disappointed not to have been warned of a vulnerability beforehand

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.

Fiddler trace of Autodiscover interactions reveals a failure
Figure 2: Fiddler trace of Autodiscover interactions reveals a failure and no back up

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.

About the Author

Tony Redmond

Tony Redmond has written thousands of articles about Microsoft technology since 1996. He is the lead author for the Office 365 for IT Pros eBook, the only book covering Office 365 that is updated monthly to keep pace with change in the cloud. Apart from contributing to Practical365.com, Tony also writes at Office365itpros.com to support the development of the eBook. He has been a Microsoft MVP since 2004.

Comments

  1. Wlodzimierz

    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

    1. Robin

      And 16.0.9029 in another screenshot

    2. Tony Redmond

      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…

  2. harald

    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.

    1. harald

      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.

    2. Tony Redmond

      That’s interesting… how did you discover that very important point?

      1. harald

        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)

        1. Tony Redmond

          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).

    1. Tony Redmond

      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.

      1. Cary Wagner

        Probably someone just looking for their 15 minutes of fame.

        1. Tony Redmond

          Well, we’ll see when they reveal the data they have and the mechanisms used to capture the information…

Leave a Reply