Story of the creds-leaking Exchange Autodiscover flaw – the one Microsoft wouldn’t fix even after 5 years

Microsoft Exchange clients like Outlook have been supplying unprotected user credentials if you ask in a particular way since at least 2016. Though aware of this, Microsoft’s advice continues to be that customers should communicate only with servers they trust.

On August 10, 2016, Marco van Beek, managing director at UK-based IT consultancy Supporting Role, emailed the Microsoft Security Response Center to disclose an Autodiscover exploit that worked with multiple email clients, including Microsoft Outlook.

“Basically, I have discovered that it is extremely easy to get access to Exchange (and therefore Active Directory) user passwords in plain text,” he wrote. “It doesn’t necessarily require any breach of corporate security, and at its most secure, is only as secure as file level access to the corporate website.”

His report received a case number from Microsoft and a reference number from US-CERT.

His proof-of-concept exploit code, which affected Outlook (both Mac and PC), default email apps for Android and iOS, Apple Mail for Mac OS X, and others, consisted of 11 lines of PHP, though he insisted the exploit probably could have been reduced to three lines.

He attached an explanatory PDF with his note, which described the behavior of Microsoft Autodiscover protocol when email client software tries to add a new Exchange account.

Five years on

Last week, security firm Guardicore offered its take on the problem with the Autodiscover protocol, explaining that the “back off” mechanism for resolving domain names makes it trivial to set up servers on Autodiscover TLDs to intercept hundreds of thousands of credential transmissions from systems that haven’t been properly secured.

“What I found was that there were a bunch of email clients including Outlook that were more than happy to pass over their credentials to a web server within your domain tree and what Guardicore found was that in many cases it kept going up the tree to the TLD, meaning you were no longer just worrying about your own web server (or the server that hosted your domain),” explained van Beek in an email to The Register.

He found that if an Outlook client invokes the Autodiscovery protocol to configure itself and the server responds with a WWW-Authenticate response instead of, say, a 404 not found error, the client software answers by transmitting – in Base64-encoded plain text – the username (the full email address and/or the local part of the email address) and the password that the user entered as part of the email client set-up wizard.

“All Exchange clients (from about 2007 onwards) use a method called Autodiscover to get their settings automatically,” he said. “If they are outside an Active Directory network (or a non-Active Directory aware device, like a smartphone), they will first contact the SSL port on the root A address.”

“This may not even go to their website if they are on a shared server,” he explained. “There is no way to prevent this behavior, so if someone gets into wherever that traffic goes, they will be able to plant the code and site back and wait.”

Van Beek said that Serper and he found the same problem with exposed credentials.

“The main difference is that he found a way to get them away from the primary email domain, whereas I stopped when I realized most email clients didn’t even check the SSL certificate before handing over the goodies,” he explained.

He added that while Serper had to force the authentication from Digest Access Authentication to Basic Authentication, he always saw credentials in Basic.

“I don’t know if that was what they did at the time, and Digest has been introduced since, or if Apache just asked for Basic Authentication,” he said. “I suspect the latter.”

Not a problem says Redmond

In any event, Microsoft acknowledged on August 11, 2016, that it had reproduced the issue in van Beek’s report. Then on August 30, 2016, the Windows titan responded to van Beek by saying the report doesn’t describe a genuine vulnerability:

“This response casually forgets to consider that a hacked web server still retains a perfectly valid certificate – it just happens to use that trusted tunnel to serve up problems,” said van Beek. “Also, I have only found one Exchange client so far which actually checks the hostname against the certificate, which is Microsoft’s own test tool.”

Van Beek said he thought it was incredible that Microsoft confirmed the behavior he reported within hours but does not consider it to be a problem. He suggested three mitigations: changing the order of operations so that DNS gets checked first; never accepting an SSL certificate without a matching host name; and reviewing why and when clients respond to authentication requests.

The Register asked Microsoft via email whether, in light of van Beek’s 2016 report and Guardicore’s report last week, the IT giant plans to take any steps to address credential exposure and whether it believes its guidance adequately addresses the problem.

“We are continuing to investigate the specific scenario shared by the researcher,” a Microsoft spokesperson responded. ®

READ MORE HERE