Microsoft Knew of Exchange Autodiscover Flaw Five Years Ago (theregister.com) 22
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."
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."
"...communicate only with servers they trust." (Score:3, Insightful)
Re: (Score:2)
why you hate chinese????
Because I'm hungry again in two hours.
Re: (Score:2)
How does one trust ANY Microsoft server if they're not able to audit the source code?
They trust them because they are dumbass managers and Microsoft marketing told them it was "secure".
How does one trust ANY Microsoft server ? (Score:3, Insightful)
It's not a flaw... (Score:2)
It's a feature.
Good old MicroShit (Score:2)
Too stupid to get it right and too stupid to learn from mistakes.
Again with this shiz? NotPetya all over... (Score:1)
Expansion of the TLD space? (Score:3)
Isn't this partially a result of the expansion the TLD name space that happened a few years ago?
Re: (Score:3)
I don't completely disagree but... access to add a file to a web server is generally a lot easier to do, with less scrutiny, than access to mess around with Active Directory, Domain Controllers, and other obviously mission-critical tools.
Web server access is commonly given to low rent web developers, often contractors. And being able to escalate a very minor file exploit on a web server up to credential stealing for anyone at the company is a big jump for very little work.
Re: (Score:2)
The one - and ONLY - time I've ever been successfully phished, it was (in large part) because the attacker gained access to a legitimate domain without the owner noticing, and set up a webserver mimicking the MS federated auth login screen on the host's server.
The FQDN was correct, and the cert presented matched, so everything looked proper. (And since somehow everyone and their dog have decided to use embedded iFrames again (despite the x^y vulnerabilties they present), even the auth redirect looked "right
While it's bad, it's not surprising (Score:3, Insightful)
For years, a user could "access" another user's calendar merely by scheduling said person for a meeting, and noting which times they were unavailable. Even though I couldn't browse another user's calendar if it was restricting, obtaining the same information required just a little bit more effort.
It always struck me as a bit insecure, because even though I couldn't see a specific user's meetings, I could figure out when they were scheduled. While I don't really get why you would want to hide your meetings from others in your company, apparently Microsoft thought it necessary, and they failed to secure even something as mundane as a calendar.
Re: (Score:2)
Re: (Score:3, Informative)
What I experienced was that even if a user could prevent me from opening their calendar, I could still obtain roughly the same information by scheduling them for a meeting.
It seems to me that if I wanted to restrict others from seeing my calendar, I wouldn't want them to be able to deduce when I had meetings scheduled, but Outlook allowed exactly that. Maybe that could be changed with another setting, but given that I've seen the same thing at multiple organizations, it was sufficiently obscure that mos
Re: (Score:3)
you're confused, that ability is necessity in company's scheduling software and your employer wants other people to know when you are scheduled for something or available for meeting. No Microsoft failing there, it is one of the purposes of an office meeting scheduler and it's what other competing wares do too.
Re: (Score:1)
Microsoft and MitM (Score:3, Informative)
I'm not surprised at all.
Microsoft's policy with regard to Man-in-the-Middle attacks is that they are _not_ security vulnerabilities, and there is nothing they need to do.
Unless you can carry out the attack _without_ getting on the path through technical means or getting somebody to put you on it (such as in this case), they're not interested.
So there you go.