Microsoft Knew of Exchange Autodiscover Flaw Five Years Ago

Thomas Claburn writes via The Register: 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 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. 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: "Our security engineers and product team have reviewed this report and determined that it is not a security issue to be serviced as part of our monthly Patch Tuesday process. 'Never accept an SSL certificate without a matching host name' is already recommended for clients in the doc cited by your report: [link]. Before you send a request to a candidate, make sure it is trustworthy. Remember that you're sending the user's credentials, so it's important to make sure that you're only sharing them with a server you can trust. At a minimum, you should verify: That the endpoint is an HTTPS endpoint. Client applications should not authenticate or send data to a non-SSL endpoint. That the SSL certificate presented by the server is valid and from a trusted authority." "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. When asked if the company plans to take any steps to address credential exposure and whether it believes its guidance adequately addresses the problem, a Microsoft spokesperson said: "We are continuing to investigate the specific scenario shared by the researcher."

Read more of this story at Slashdot.

from Slashdot https://ift.tt/3ohhn1W

Share on FacebookPlus on Google+

SUBSCRIBE TO OUR NEWSLETTER