[German]Security researchers at Guardicore have discovered a design flaw in Microsoft Exchange autodiscover protocol that allows attackers to use external autodiscover domains to harvest domain credentials. This is possible because autodiscover domains outside the user's domain (but still in the same TLD) can be abused. Here are some details about this flaw.
Advertising
Security researcher Amit Serper of security vendor Guardicore has published his new findings in the blog post Autodiscovering the Great Leak. I became aware of the issue via the following tweet.
Autodiscover in Exchange
Autodiscover is a protocol used by Microsoft Exchange to automatically configure the email accounts used by clients such as Microsoft Outlook. The goal of the protocol is to allow an end user to fully configure their Outlook client by simply providing their username and password and leaving the rest of the configuration to Microsoft Exchange's Autodiscover protocol.
When setting up access for a Microsoft Exchange mailbox, the mail app sends the credentials (username, password) to the server, and then gets the valid configuration reported back. With this, the client is then submitted for the Exchange Server access in question. The protocol was already introduced in Outlook 2007. A short description can be found here and Microsoft has described the implementation of Autodiscover here.
Note: Often, credentials for an Exchange-based inbox are also used as domain credentials. If an attacker succeeds in stripping the credentials for an Exchange inbox via a vulnerability, they will subsequently also have access to the organization's domain. The attacker then has valid credentials with which to gain access to an organization's network.
The Autodiscover design flaw
When setting up an Exchange mailbox account within a mail app, the mail app sends a ping with the mailbox credentials (username, password) to various addresses of the type:
Advertising
- 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
The example.com domain is determined from the @example.com e-mail address specified for the Exchange mailbox. If none of these URLs respond, Autodiscover starts its "back-off" procedure. This "back-off" mechanism tries to resolve the Autodiscover part of the domain and in the next attempt would return a URL of the type:
http: // autodiscover.com/Autodiscover/Autodiscover.xml
would be requested. The domain here consists of the name autodiscover and the top-level domain of the mailbox to be configured (.com, .de, .fr, etc.). Now, the design flaw in Exchange autodiscover is that the pings are not limited to the domain of the mailbox to be checked (e.g. borncity.com). Rather, various top-level domains are conceivable for autodiscover.
If a third party succeeds in registering the domain autodiscover.com, autodiscover.de, etc., the requests with the access data would be pinged to this domain. The security researchers were able to grab and register the following domains:
- Autodiscover.com.br – Brazil
- Autodiscover.com.cn – China
- Autodiscover.com.co – Columbia
- Autodiscover.es – Spain
- Autodiscover.fr – France
- Autodiscover.in – India
- Autodiscover.it – Italy
- Autodiscover.sg – Singapore
- Autodiscover.uk – United Kingdom
- Autodiscover.xyz
- Autodiscover.online
The domains registered in this way were assigned to a web server controlled by Guardicore security researchers. Then the security researchers waited for web requests to arrive for various autodiscover endpoints. To their surprise, the Guadicore folks found that a significant number of requests were coming in from various domains, IP addresses and clients to the controlled Autodiscover endpoints.
The most notable thing about these requests was that they requested the relative path /Autodiscover/Autodiscover.xml with the authorization header. And that's where the credentials for HTTP basic authentication were stored.
What was alarming about a large number of the requests was that the made no attempt to first check if the resource was even available or even existed on the server (triggers an HTTP 404 error). Rather, the credentials were sent right along with the first request.
From April 16 to August 25, 2021, security researchers using their Autodiscover honeypot received hundreds of requests with thousands of credentials from users who were trying to set up their email clients, but their email clients could not find the correct Exchange mailbox Autodiscover endpoint. Companies and organizations from various sectors were affected. Not only were credentials in plain text, but so were OAuth tokens.
The warning about self-signed certificates, which may appear on the client, could also be suppressed with a LetsEncrypt certificate. The security researcher has summarized the details in this blog post. There he also gives hints on how the problem could be mitigated.
- Those using Exchange-based technologies such as Outlook or ActiveSync (Microsoft's mobile Exchange synchronization protocol) must ensure that Autodiscover domains (such as Autodiscover.com/Autodiscover.com.cn, etc.) are actively blocked in a firewall.
- When deploying/configuring Exchange setups, ensure that basic authentication support is disabled. Using HTTP basic authentication is the same as sending a password over the wire in clear text.
Further, software developers/vendors implementing the autodiscover protocol in their products would have to implement it in such a way that the credentials are not sent with the first request. And Microsoft would have to revise the requirements for the Autodiscover protocol.
Addendum: See now my blog post Microsoft tries to register autodiscover domains.
Similar articles:
Security updates for Exchange Server (July 2021)
Cumulative Exchange CUs June 2021 released
Exchange Server Security Update KB5001779 (April 13, 2021)
Exchange isues with ECP/OWA search after installing security update (March 2021)
Exchange security updates from July 2021 breaks ECP and OWA
Exchange 2016/2019: Outlook problems due to AMSI integration
Wave of attacks, almost 2,000 Exchange servers hacked via ProxyShell
Exchange Server 2016-2019: Custom attributes in ECP no longer updatable after CU installation (July 2021)
Exchange Server: Authentication bypass with ProxyToken
Exchange vulnerabilities: Will we see Hafnium II?
