Credit: Dreamstime
Security researchers warn that a design issue in how the Microsoft Exchange Autodiscover feature works can cause Outlook and other third-party Exchange client applications to leak plaintext Windows domain credentials to external servers.
The risk is significantly higher for devices that are 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 to configure their connection to Exchange automatically. To do this, they rely on a remote configuration file hosted on what is intended to be a company domain.
However, because of a design issue that has been highlighted in the past as well, the protocol can end up searching for the configuration on external domains that are or can be registered by anyone.
Researchers from 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 organisations around the world that were sent by client applications to their web server automatically.
What causes the problem?
"The Exchange Autodiscover service provides an easy way for your client application to configure itself with minimal user input," Microsoft's documentation says. "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.
"For Exchange Web Services (EWS) clients, Autodiscover is typically used to find the EWS endpoint URL, but Autodiscover can also provide information to configure clients that use other protocols. Autodiscover works for client applications that are inside or outside firewalls and will work in resource forest and multiple 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 the Active Directory Domain Services (AD DS).
If that's not available because the client does not have access to AD or can't access it, the protocol will construct Autodiscover URL candidates based on the domain of the email address input 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
Up to this point, all seems fairly safe if we consider that example.com is the company's domain name.
But if there's no response from either of them, the protocol's aggressive URL search routine will keep trying to construct URL candidates and can end up trying Autodiscover + the TLD + the path: Autodiscover.com for the above example 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 registered some of these domains and some have been registered by other parties for several years, Amit Serper VP of security research at Guardicore told CSO. That was likely after a 2017 research paper by researchers from Shape Security that highlighted the same Autodiscover domain collision problem while investigating Samsung's mail client for Android and Apple's iOS Mail app.
"This is a problem with both the design of how Microsoft initially implemented that [protocol] and also a problem in how third parties are implementing it," Serper said. "It's a two-fold issue: It's both a design issue and an implementation issue.
Serper said that Guardicore's web server didn't receive only requests from Microsoft Outlook, but also third-party applications that interface with Exchange and are not email clients. Guardicore is still engaged in the responsible disclosure process with the developers of some of those applications and declined to name them until they had a chance to patch their implementations.
Plaintext credentials and downgrade attacks
Another aspect is that many of the requests observed by Guardicore included plaintext credentials encoded in base64 without the server even prompting for authentication.
"The interesting issue with a large amount of the requests that we received was that there was 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," the researchers said.
"Usually, the way to implement such a scenario would be to first check if the resource that the client is requesting is valid, since it could be non-existent (which will trigger an HTTP 404 error) or it may be password protected (which will trigger an HTTP 401 error code)."
Microsoft Outlook sometimes attempts to authenticate with a token instead of a username and password, but the rogue server can perform a downgrade attack where it tells the client that tokens are not accepted.
This will force an authentication prompt on the client and, if the server doesn't have a trusted TLS certificate, it will generate a warning. However, the warning can be easily fixed by an attacker by obtaining a free certificate for the domain they own from Let's Encrypt.
Using basic HTTP authentication with plaintext credentials is a serious security issue if the attacker can sniff traffic over the same network as the user or they can launch a DNS poisoning attack.
The researchers saw credentials coming from various versions of Outlook, but when they tried to replicate the behaviour in the lab, they weren't always successful without resorting to the downgrade attack.
"I assume that it's some sort of configuration [on those systems], Serper told CSO. "Let's say that you work from your office with your laptop and you're within the corporate network and all of these servers are accessible to you and then you take your laptop home because you work from home.
"So, you take your laptop home and you're either not connected to the VPN or for some reason these servers aren't accessible from where you are and then this task just runs in the background, trying to connect to the server and ending up leaking passwords."
Mitigation
To protect their users, especially roaming ones, companies 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 those domains from resolving via DNS.
Furthermore, when deploying Exchange, administrators should make sure that HTTP basic authentication is disabled so that plaintext credentials are not sent over the network.
Finally, the developers of applications that implement the Exchange Autodiscover protocol should make sure that the protocol doesn't "fail upwards" and end up constructing candidate URLs on Autodiscover.TLD domains, the researchers said.
Microsoft did not immediately respond to a request for comment.
