An Autodiscover feature design issue in Exchange and Outlook and other third-party Exchange client applications can leak Windows domain credentials in clear text to external servers. Here’s what businesses can do right now to mitigate the risk.
Security researchers report that due to a design issue in the Microsoft Exchange Autodiscover feature, Outlook and other third-party Exchange client applications can leak Windows domain credentials in the clear to external servers. The risk is significantly higher for devices used outside of corporate networks, a common scenario during the pandemic. Microsoft’s Autodiscover Protocol for Exchange allows client applications to automatically configure their connection to Exchange.
They do this by relying on a remote configuration file hosted on what is supposed to be a corporate domain. However, due to a design issue already identified in the past, the protocol can end up searching for the configuration on external domains that are or can be registered by anyone. In August, researchers at security firm Guardicore registered some of these external domains, and within a week or so, they managed to collect 96,671 unique user IDs from companies. worldwide and automatically sent by client applications to their web server.
Domains registered for several years
“The Exchange Autodiscover service makes it easy for your client application to configure itself with minimal user input,” Microsoft documentation states. “Most users know their email address and password, and with those two pieces of information, you can retrieve all the other details you need to get up and running,” the documentation says. For Exchange Web Services (EWS) clients, Autodiscover is typically used to find the URL of the EWS endpoint, but Autodiscover can also provide information to configure clients that use other protocols. Autodiscover works for client applications that are inside or outside of firewalls and will operate in an Exchange resource forest (also known as an Exchange dedicated forest) and Exchange cross-forest topology.
The Autodiscover protocol will try to find the configuration URL in stages. First, it looks in Active Directory Domain Services (AD DS) Service Connection Point (SCP) objects. If this is not possible because the client does not have or cannot access AD, the protocol constructs Autodiscover URL candidates based on the domain of the email address entered by the user. For [email protected], where example.com is the company’s domain name, the service will try to reach:
So far, everything seems pretty secure considering that example.com is the company’s domain name. But if there is no response from either, the protocol’s aggressive URL lookup routine will still try to build candidate URLs and may end up trying Autodiscover + the Top Level Domain (TLD ) + the path: Autodiscover.com for the example above or Autodiscover.com if the user’s email address is [email protected] and so on. The problem is, these are public domain names that someone else owns.
“Guardicore has registered some of these domains and some have been registered by other parties for several years,” said Amit Serper, VP of Security Research at Guardicore. This research was likely undertaken after the publication in 2017 of a research paper by researchers at Shape Security in which they identified the same Autodiscover domain collision issue while investigating the email client. from Samsung for Android and Apple’s Mail iOS app. “The issue is both how Microsoft designed the initial protocol, but also how third parties implement it,” said Amit Serper. “So it’s a design and implementation problem,” he added. He also stated that Guardicore’s web server does not only receive requests from Microsoft Outlook, but also from third-party applications that interface with Exchange and are not email clients. Guardicore still lives up to its responsible disclosure commitment with the developers of some of these apps and has declined to name them until they have a chance to patch their implementations.
Plain-text credentials and demotion attacks
Another aspect of the problem is that many of the requests observed by Guardicore included base64 encoded clear text identifiers without the server requesting authentication. “The interesting problem with a lot of the requests we have received is that on the client side nothing is done to check if the resource is available, or even if it exists on the server, before sending. of an authenticated request, ”the researchers said. “Usually the implementation of this kind of scenario would be to first check if the resource that the client is requesting is valid, as it could be non-existent (which would trigger an HTTP 404 error) or be password protected ( which would trigger an HTTP 401 error code) ”.
Microsoft Outlook sometimes tries to authenticate using a token instead of a username and password, but the malicious server may perform a so-called demotion or fallback attack where it says to the customer that tokens are not accepted. The client is then prompted to authenticate and, if the server does not have a trusted TLS certificate, a warning is generated. However, an attacker can easily correct this warning by obtaining a free certificate for the domain he owns from Let’s Encrypt. Using basic HTTP authentication with clear credentials poses a serious security concern if the attacker can sniff traffic on the same network as the user or if they can launch a DNS cache poisoning attack .
The credentials the researchers collected came from different versions of Outlook, but when they tried to replicate this behavior in the lab, they weren’t always successful without the help of the demotion attack. “I guess this corresponds to some sort of configuration [sur ces systèmes] “Said Amit Serper. “For example, the user works from his desk with his laptop. It is connected to the corporate network and has access to all these servers. Then he takes his laptop home to continue working. But he is not connected to the VPN or for some reason these servers cannot be reached from his home. So this task just runs in the background, tries to connect to the server and ends up leaking passwords, ”he explained.
To protect their users, especially mobile workers, companies should deploy endpoint firewall rules that block requests to all Autodiscover.TLD domains. Guardicore has created a list of these risky Autodiscover domains that can be added to a computer’s hosts file, which will prevent these domains from resolving through DNS. Additionally, when deploying Exchange, administrators should ensure that HTTP Basic authentication is disabled so that clear-text credentials are not sent over the network. Finally, application developers that implement the Exchange Autodiscover protocol must ensure that the protocol does not fail upwards, that is, perpetuate itself despite failures, and does not build a URL. candidates on Autodiscover.TLD domains, the researchers further indicate. Microsoft did not immediately respond to a request for comment.