Exchange Autodiscover feature may leak Outlook credentials

Security researchers warn that a design issue in the way Microsoft Exchange’s Autodiscover functionality works may cause Outlook and other third-party Exchange client applications to disclose Windows domain credentials in plain text to servers external.

The risk is significantly higher for devices used outside of corporate networks, a common scenario during the pandemic.

The goal of Microsoft’s Autodiscover Protocol for Exchange is to help client applications automatically configure their connection to Exchange. To do this, they rely on a remote configuration file hosted on what is supposed to be a corporate domain.

However, due to a design issue that has also been highlighted in the past, the protocol can end up searching for the configuration on external domains that are or can be registered by anyone.

Researchers at security firm Guardicore registered some of these external domains, and over the course of about a week in August, managed to collect 96,671 unique user credentials from organizations around the world that were automatically sent by client applications to their web server.

What is causing the problem?

“The Exchange Autodiscover service gives your client application an easy way to configure itself with minimal user intervention,” Microsoft documentation states. “Most people know their email address and password, and with those two pieces of information, you can retrieve all the other information you need to be up and running.

“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. Automatic works for client applications that are inside or outside firewalls and will work in resource forest and several forest scenarios.

The Autodiscover protocol will attempt to find the configuration URL in stages. First, it will look in the Service Connection Point (SCP) objects in Active Directory Domain Services (AD DS).

If this is not available because the client does not have or cannot access AD, the protocol will construct candidate autodiscover URLs based on the domain of the email address entered by the user. . For user@example.com, where example.com is the company’s domain name, the service will try to reach:

• 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

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 continue to try to construct candidate URLs and may end up trying Autodiscover + the TLD + the path: Autodiscover.com for the example above or Autodiscover.co.uk if the user’s email is user@something.co.uk 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, vice president of security research at Guardicore. CSO. This was likely after a 2017 research paper by researchers at Shape Security that highlighted the same Autodiscover domain collision issue while investigating Samsung’s email client for Android and iOS Mail app from Apple.

“It’s a problem with both the design of how Microsoft initially implemented that [protocol] and also an issue in how third parties implement it, ”Serper said. “It’s a double problem: it’s both a design problem and an implementation problem.

Serper said Guardicore’s web server not only receives requests from Microsoft Outlook, but also from third-party applications that interface with Exchange and are not email clients. Guardicore is still in the process of responsible disclosure with the developers of some of these apps and has declined to name them until they have a chance to correct their implementations.

Plain-text credentials and demotion attacks

Another aspect is that many of the requests Guardicore observed included base64 encoded clear-text credentials without the server even asking for authentication.

“The interesting problem with a lot of the requests we received was that there was no attempt on the client side to verify if the resource is available, or even exists on the server, before sending an authenticated request. “the researchers said.

Usually the way to implement such a scenario would be to first check if the resource requested by the client is valid, as it might be non-existent (which will trigger an HTTP 404 error) or it might be password protected. password (which will trigger an HTTP 401 error code). “

Microsoft Outlook sometimes tries to authenticate with a token instead of a username and password, but the malicious server may perform a demotion attack where it tells the client that the tokens are not accepted .

This will force an authentication prompt on the client and, if the server does not have a trusted TLS certificate, it will generate a warning. However, the warning can be easily corrected by an attacker by obtaining a free certificate for the domain he owns from Let’s Encrypt.

Using basic HTTP authentication with clear credentials is a serious security issue if the attacker can sniff traffic on the same network as the user or if they can launch an attack. DNS poisoning.

Researchers saw credentials from different versions of Outlook, but when they tried to replicate the behavior in the lab, they were not always successful without resorting to the demotion attack.

“I guess it’s kind of a setup [on those systems], Serper said CSO. “Let’s say you’re working from your desk with your laptop and you’re on the corporate network and all of those servers are accessible to you, and then you bring your laptop home because you’re working from home.

“So you bring your laptop home and you are not connected to the VPN or for some reason these servers are not accessible from where you are and then this task is just running in the background, trying to connect to the server and ending password leaks. “

Mitigation

To protect their users, especially roaming users, organizations should deploy firewall rules on endpoints 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 plain 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 up” and end up building candidate URLs on Autodiscover.TLD domains, the researchers said.

Microsoft did not immediately respond to a request for comment.

MicrosoftOutlook Tags