Research released by security outfit Guardicore on Wednesday US time, said the flaw, in an implementation of the Autodiscover protocol based on the POX XML protocol, would leak Web requests to Autodiscover domains outside a user's domain, but within the same top-level domain.
The Autodiscover protocol allows users of mail clients like Outlook to authenticate to a server after inputting a username and password; the remainder of the credentials needed for authentication would be supplied by the Exchange server.
But, as Guardicore's Amit Serper found, Windows domain credentials could be easily captured, something he achieved by setting up multiple Autodiscover domains with a TLD suffix that connected to a Web server controlled by Guardicore.
"This is a severe security issue, since if an attacker can control such domains or has the ability to 'sniff' traffic in the same network, they can capture domain credentials in plain text (HTTP basic authentication) that are being transferred over the wire," he wrote.
"Moreover, if the attacker has DNS-poisoning capabilities on a large scale (such as a nation-state attacker), they could systematically siphon out leaky passwords through a large-scale DNS poisoning campaign based on these Autodiscover TLDs."
No. That's exactly the point. It makes no sense.— Amit Serper (@0xAmit) September 22, 2021
He said since Exchange was part of Microsoft's domain suite of solution, the credentials that were needed to access the mail server were generally the domain credentials.
"The implications of a domain credential leak in such scale are massive, and can put organisations in peril. Especially in today’s ransomware-attacks ravaged world, the easiest way for an attacker to gain entry into an organisation is to use legitimate and valid credentials," Serper pointed out.
Four years ago, researchers from Share Security shared details of how Autodiscover implementations for mobile email clients could cause such leaks.
The flaws that were disclosed were patched, but "here we are in 2021 with a significantly larger threat landscape, dealing with the exact same problem only with more third-party applications outside of email clients", Serper noted.
He explained the process of authentication that occurred behind the scenes, by using a hypothetical email address: amit @ example.com
- First, the email client would parse this address.
- Then, the client would try to build an Autodiscover URL based on the email address with the following format:
- 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
"In the case that none of these URLs are responding, Autodiscover will start its 'back-off' procedure," Serper explained. "This 'back-off' mechanism is the culprit of this leak because it is always trying to resolve the Autodiscover portion of the domain and it will always try to 'fail up', so to speak.
Not good. pic.twitter.com/6Q3xQj41Ne— Amit Serper (@0xAmit) September 22, 2021
"Meaning, the result of the next attempt to build an Autodiscover URL would be: https:// Autodiscover.com/Autodiscover/Autodiscover.xml. This means that whoever owns Autodiscover.com will receive all of the requests that cannot reach the original domain."
To test out his findings, Serper registered 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
All these domains were allocated to a Web server owned by Guardicore and soon torrents of Web requests started to arrive.
"The most notable thing about these requests was that they requested the relative path of /Autodiscover/Autodiscover.xml with the Authorisation header already populated with credentials in HTTP basic authentication," Serper noted.
"Generally, Web requests should not be sent blindly pre-authenticated, but rather by following the HTTP authentication process:
- "A client requests access to a protected resource;
- "The Web server returns a dialog box that requests the username and password (in accordance with the supported authentication methods; in our case, basic authentication);
- "The client submits the username and password to the server; [and]
- "The server authenticates the user and returns the requested resource."
He said that with the majority of requests received on the Web server, there was no attempt from the client side to check if the resource was available or even existed on the server.
"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)," Serper pointed out.
Comment has been sought from Microsoft.