[BreachExchange] Exchange Autodiscover feature can cause Outlook to leak credentials

[Sophia Kingsbury]

https://www.csoonline.com/article/3634388/exchange-autodiscover-feature-can-cause-outlook-to-leak-credentials.html

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 organizations 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 at 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 at 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 behavior 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20210923/232427bc/attachment.html>