Microsoft Exchange Autodiscover flaw reveals users’ passwords

Researchers have been able to get hold of 372,072 Windows domain credentials, including 96,671 unique credentials, in slightly over 4 months by setting up a Microsoft Exchange server and using Autodiscover domains.

The credentials that are being leaked are valid Windows domain credentials used to authenticate to Microsoft Exchange servers.

What is Autodiscover?

From Microsoft’s site we learn that “the Autodiscover service minimizes user configuration and deployment steps by providing clients access to Exchange features. For Exchange Web Services (EWS) clients, Autodiscover is typically used to find the EWS endpoint URL. However, Autodiscover can also provide information to configure clients that use other protocols. Autodiscover works for client applications that are inside or outside firewalls and in resource forest and multiple forest scenarios”.

Which boils down to a feature of Exchange email servers that allows email clients to automatically discover email servers, provide credentials, and then receive proper configurations. Designed to make the user’s life easier while forgetting that such designs need to be done with security in mind. Because cybercriminals love such features and use them for their own purposes.

How can it be abused?

The protocol’s goal is to make an end-user be able to completely configure their Outlook client solely by providing their username and password and leave the rest of the configuration to Microsoft Exchange’s Autodiscover protocol.

To accomplish this the Autodiscover protocol looks for a valid Autodiscover URL in these formats, where the example.com is replaced by the domain name (the part after the @) in the users’s email address:

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

This means that to start with, Autodiscover is looking for a URL at a domain or subdomain that is owned by the organization the user belongs to, so mistakes are contained and unlikely to cause problems. But, and here it comes, if none of the above send a valid response the process gets wonky, where it should probably have given up.

If those attempts fail, the next attempt to build an Autodiscover URL drops the example.com part that confines lookups to the user’s organization and looks here:

http://autodiscover.com/Autodiscover/Autodiscover.xml

This gives whoever owns the domain autodiscover.com a huge opportunity.

And the same is true for other Autodiscover top-level domains (TLDs) too, such as autodiscover.es, which will receive requests from all unresponsive .es domains.

To complete the mess, there is no login procedure required on the server side. The unsuspecting user trying to set up their Exchange account is just sending their credentials to an unknown server. There is also no attempt on the client’s side to check if the resource is available, or even exists on the server, before sending an authenticated request.

How bad is it?

It is important to understand that since Microsoft Exchange is part of the Microsoft domain suite of solutions, the credentials that are necessary to login to an Exchange-based inbox are in most cases the same as their domain credentials. The possible consequences of a domain credential leak at such a scale are enormous, and can put entire organizations in danger. Especially in the light of the ongoing ransomware attacks that are daily news. What easier way could an attacker ask for than to gain entry into an organization by using legitimate and valid credentials?

A quick search on my part learned that in most of the big TLDs the autodiscover domains have already been picked up.

Some of the most dangerous ones have been registered by the researchers to do their testing.

Detection and mitigation

Organizations can protect themselves by establishing their own Autodiscover domains, and blocking Autodiscover.TLD domains at the firewall or in their local DNS. Users can block Autodiscover.TLD domains in their hosts file.

Software vendors and developers who are implementing the Autodiscover protocol in their products should make sure that they are not letting it “fail upwards”, meaning that domains such as autodiscover. should never be constructed by the “back-off” algorithm.

When deploying or configuring Exchange server setups, organizations should also make sure that support for basic authentication is disabled. Using HTTP basic authentication sends credentials in clear text, making them easy to intercept.

When a user is being redirected to an Autodiscover.TLD server trying to make use of the leak, a security alert might pop up if it doesn’t have a security certificate, or if it has one that is self-signed. This could easily be avoided by the attacker if they deploy a valid TLS certificate though.

Microsoft was not informed of the problem before the credential harvesting was set in motion and the results were already published, so they are still investigating and promised to take appropriate steps to protect customers.

Stay safe, everyone!

The post Microsoft Exchange Autodiscover flaw reveals users’ passwords appeared first on Malwarebytes Labs.