Microsoft Exchange clients like Outlook have been providing unprotected user credentials if you request it in a particular way since at least 2016. While aware of this, Microsoft’s advice continues to be that customers should not communicate only with trusted servers.
On August 10, 2016, Marco van Beek, managing director of a UK-based IT consultancy, Supporting Role, emailed Microsoft Security Response Center to disclose an Autodiscover exploit that worked with multiple clients messaging, including Microsoft Outlook.
“Basically, I’ve found that it’s extremely easy to access Exchange (and therefore Active Directory) user passwords in plain text,” he wrote. “It doesn’t necessarily require a breach of corporate security, and in its most secure form, it’s only as secure as file-level access to the corporate website. “
His report received a file number from Microsoft and a reference number from US-CERT.
Its proof of concept exploit code, which affected Outlook (both Mac and PC), the default email apps for Android and iOS, Apple Mail for Mac OS X and others, consisted of 11 lines of PHP, although he insisted that the exploit was probably could have been reduced to three lines.
He attached an explanatory PDF to his memo, which described the behavior of the Microsoft Autodiscover protocol when email client software attempts to add a new Exchange account.
Five years later
Last week, security firm Guardicore offered its take on the Autodiscover protocol problem, explaining that the back-off mechanism for resolving domain names makes it trivial to configure servers on Autodiscover TLDs to intercept hundreds of thousands of transmissions of credentials from systems that have not been properly secured.
“What I found was that there were a bunch of email clients, including Outlook, that were more than happy to pass their credentials to a web server in your domain tree and what Guardicore found was that in many cases it kept moving up the tree all the way to the TLD, meaning you no longer just care about your own web server (or the server that was hosting your domain), “van Beek explained in an email to The register.
He discovered that if an Outlook client invokes the Autodiscover protocol to configure itself and the server responds with a
WWW-Authenticate Instead of, say, a 404 not found error, the client software responds by passing – in Base64 encoded plain text – the username (the full email address and / or the local part of the email address). mail) and the password that the user enters as part of the mail client setup wizard.
“All Exchange customers (from around 2007) use a method called Autodiscover to get their settings automatically,” he said. “If they are outside of an Active Directory network (or a device that does not support Active Directory, such as a smartphone), they will first contact the SSL port of the root A address.”
“It may not even go to their website if it’s on a shared server,” he explained. “There is no way to prevent this behavior, so if someone gets in where this traffic is going, they can reinstall the code and the site and wait.”
Van Beek said he and Serper found the same issue with the exposed credentials.
“The main difference is that he found a way to get them away from the primary email domain, so I stopped when I realized that most email clients don’t even verify the SSL certificate before handing them over. gifts, ”he explained.
He added that even though Serper had to force authentication from Digest Access Authentication to Basic Authentication, he still saw the credentials in Basic.
“I don’t know if that’s what they did at the time, and Digest has since been introduced, or if Apache just asked for basic authentication,” he said. “I suspect the latter.”
No problem says Redmond
In any case, Microsoft admitted on August 11, 2016 to have reproduced the problem in the van Beek report. Then, on August 30, 2016, the Windows titan responded to van Beek saying that the report does not describe a true vulnerability:
“This answer carelessly forgets to consider that a hacked web server always keeps a perfectly valid certificate – it just happens to be using that tunnel of trust to troubleshoot problems,” van Beek said. “Additionally, I have so far only found one Exchange client that actually checks the hostname against the certificate, which is Microsoft’s own testing tool.”
Van Beek said he thought it was incredible that Microsoft had confirmed the behavior it reported within hours, but didn’t see it as a problem. He suggested three mitigating measures: changing the order of operations so that the DNS is checked first; never accept an SSL certificate without a corresponding host name; and examine 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 action to address the exposure of credentials and s’ he believed that his directives solved the problem correctly.
“We are continuing to investigate the specific scenario shared by the researcher,” replied a Microsoft spokesperson. ®