Autodiscover Vulnerability FUD or Not?

Social media exploded when an ISV who specializes in security released a blogpost about a vulnerability they found in Autodiscover, the protocol that is used by mailclients to discover Exchange configuration and configure themselves. Outlook is the client that uses Autodiscover the most, but mobile clients and third party applications can use Autodiscover as well.

The security ISV states that a known bug in the Autodiscover process makes it possible to capture user credentials, and they have captured 372,072 Windows domain credentials and 96,671 unique credentials between April 2021 and August 2021. That’s quite a statement and when true points to a significant security issue with the Autodiscover protocol.

After one and a half days with a lot of discussions going on, I am still not convinced it’s a bug in Exchange, Outlook or the Autodiscover protocol. Unfortunately, the researcher  fails to give sufficient and detailed information on how they got to this result, and why this is an issue in these products. Sure, they have seen something and makes a lot of noise, but they didn’t explain how they come to this conclusion. Another thing is, when you find a security issue and you can reproduce it, why not report it to Microsoft first and give them the opportunity to reproduce it and take appropriate action? If you do, you still get all the credit for discovery and maybe get the $ 100,000 reward as well. As Andrew Higginbotham, one of the contacts in my network said, “this is the equivalent of the local tire shop tossing nails on the road when business is slow.”

But back to Autodiscover. I have written about Autodiscover in two previous articles here on ENow:

• The Autodiscover dilemma: steps to take if you encounter it - https://www.enowsoftware.com/solutions-engine/autodiscover-dilemma
• The Autodiscover dilemma (part 2) - https://www.enowsoftware.com/solutions-engine/autodiscover-dilemma-part

In short, there are a series of steps to take (that can be clearly seen when testing Outlook or using the Remote Connectivity Analyzer)in the Autodiscover process when trying to configure:

• SCP records in Active Directory for domain joined clients
• Root domain discovery (contoso.com/Autodiscover/Autodiscover.xml)
• Autodiscover FQDN (Autodiscover.contoso.com/Autodiscover/Autodiscover.xml)
• Autodiscover redirect (Autodiscover.contoso.com using HTTP/302 redirect to another Autodiscover FQDN)
• Autodiscover SRV records (_autodiscover._tcp.contoso.com pointing to a valid Autodiscover FQDN)
• Autodiscover redirect to Office 365 (Autodiscover.outlook.com)

When all steps fail, the Autodiscover process stops and the client is not configured at all. This is documented on the Microsoft site and can be found on Autodiscover service in Exchange Server | Microsoft Docs.

So how can the researcher conclude that the so called “back-off” process ends up on FQDN’s like Autodiscover.com, Autodiscover.fr or Autodiscover.xyz? Unless Microsoft comes up with a good explanation, this is not following the normal Autodiscover process and certainly not the default Outlook client behavior. Several fellow MVP colleagues have extended experience with Autodiscover and all sorts of clients, and no one has seen this before or was able to reproduce this.

With some ‘reverse thoughts’, how do you end up on an FQDN Autodiscover.com? Theoretically when using an email address like jaap@com, Autodiscover should construct the URL Autodiscover.com/Autodiscover/Autodiscover.xml. Theoretically, since my Outlook 2010 client did not accept jaap@com as a valid email address. When looking at the information available at this point, maybe Amit was using scripts with the Exchange Web Services (EWS) DLL and found strange results with WireShark and the various Autodiscover sites which is unknown at this point. If so, this could lead to strange Exchange server side behavior, something that Microsoft must validate. But at this point this is also an assumption.

Domain joined clients on the internal network will never get external information from unknown sites since they retrieve the Autodiscover URL from the Service Connection Point. Outlook click-to-run clients against Office 365 will contact Autodiscover.outlook.com directly without any steps, so these are not impacted as well. I am still wondering how the researcher got so many unique credentials on the sites he mentioned.

What we also do not know is what the researcher did with DNS. If you control DNS, or when DNS is compromised you are screwed either way, Autodiscover bug or not. The same is true when your corporate website is compromised. It is the same situation as the bad guy has physical access to your domain controller, bad things will happen as well.

What we do know is that the researcher keeps referring to an issue that was reported in 2017 and that this issue is known for years. For more information, you can read this report from the Blackhat Asia here. What we also know right now is that Microsoft has been registering lots of Autodiscover.tld domains that last week. This does not prove anything by itself, but it helps spreading more FUD unfortunately.

And, if you read that Microsoft started to decommission Basic Authentication this week (Basic Authentication and Exchange Online – September 2021 Update) because of this Autodiscover vulnerability, that’s again more FUD. Microsoft has been working on that for years, it has only been delayed because of the COVID pandemic.

Summary

Every reported security incident must be treated carefully and investigated and documented properly, from a reader, a vendor and a researcher perspective. In the security ISV's Autodiscover case, this is clearly not the case. The researcher failed to document properly and failed to follow the regular path when finding a security breach, something you might expect from a security researcher and failed to answer any question he got related to his report.

At this moment, it is more like the researcher found some information they believe is a security breach (please notice his company sells security products) and starts to cry wolf. The entire community starts retweeting the information and helps spread incomplete information and sometimes even worse, misinformation.

Unless the researcher or Microsoft comes up with a valid explanation what exactly is going on and validates his story, I am not convinced about this so called “bug” and security incident. There might be something going on, but with the information available it is like smoke and fire, and I don’t think Exchange is on fire. Time will tell.

Just before publishing, the following news was released the security ISV - The Zero Trust Powerhouse - was acquired. This makes me wonder about the validity of the story at all . . . .

Exchange Hybrid and Office 365 Monitoring and Reporting

On-premises components, such as AD FS, PTA, and Exchange Hybrid are critical for Office 365 end user experience. In addition, something as trivial as expiring Exchange or AD FS certificates can certainly lead to unexpected outages. By proactively monitoring hybrid components, ENow gives you early warnings where hybrid components are reaching a critical state, or even for an upcoming expiring certificate. Knowing immediately when a problem happens, where the fault lies, and why the issue has occurred, ensures that any outages are detected and solved as quickly as possible.

Access your free 14-day trial of ENow’s Exchange Hybrid and Office 365 Monitoring and Reporting today!