Microsoft Exchange Autodiscover protocol found leaking hundreds of thousands of credentials A flaw in Microsoft's Autodiscover protocol, used to configure Exchange clients like Outlook, can cause user credentials to leak to miscreants in certain circumstances. The upshot is that your Exchange-connected email client may give away your username and password to a stranger, if the flaw is successfully exploited. In a …
I'll offer up that the team that originally implemented it either: a) didn't know what they were doing at the time; b) made bad assumptions based on how the internet was designed at the time; or c) knew about the issue, tried valiantly to put in a proper fix that wouldn't overly break things, was overruled by manglement in favor of getting the product shipped, and left in disgust shortly thereafter with the junior varsity team to try and untangle their code.
My personal opinion is that it's a combination of all three.
Also, I don't think it's Exchange Server, but the implementation for Autodiscover on the client side that has the issue. If anything, I don't think the original authors of the protocol dreamed it would be implemented over the internet. Also, the internet was a slightly more trust-worthy place back then. Slightly.
Yep, nothing to do with an organisation's Exchange setup at all. The client works through the predefined list of connection addresses/methods to try until it gets a response and there's no way to change that from the server (since the client hasn't yet reached the server!). If for instance you're using the SRV record method for autodiscover you can't magically make that the first thing that is tried from the server. You can edit the registry on each machine to adjust which methods are used, but that's nothing to do with Exchange.
I think you're giving them too much credit. MS has known their software is security swiss-cheese since the mid 1990's, before Exchange and Outlook were even much of a thing. So they've had at least 20 years to figure out that "the Internet is Bad" and code accordingly. But they haven't learned that lesson yet, in spite of the thousands of vulnerabilities discovered in their various softwares. I mean if this was a vulnerability in a version of Outlook released in 2000, yeah, maybe I could let them slide. But this bugaboo exists in even their most recent version. Hard to cut them any slack for that.
It's even more nefarious than that... if you have your primary domain hosted on something other than on Microsoft's servers then where do the auto discover requests go to?
For example, theregister.com - not hosted on Azure/Microsoft 365
Microsoft Outlook running for an @theregister.com email address will request (require) configuration from autodiscover.theregister.com, theregister.com/autodiscover/<blah> and so on.
While it's possible to configure DNS such that autodiscover.theregister.com refers to a Microsoft Exchange server, it's not convenient and is beyond most organisations.
The whole crappy process was invented when Microsoft was still stupidly instructing* admins to set up the dumb ".local" domain names, and that says it all really.
* Microsoft have since edited history to make it appear that they said something quite different.
"Microsoft Outlook running for an @theregister.com email address will request (require) configuration from autodiscover.theregister.com, theregister.com/autodiscover/<blah> and so on.
While it's possible to configure DNS such that autodiscover.theregister.com refers to a Microsoft Exchange server, it's not convenient and is beyond most organisations."
Umm, well that's the way you do it. If the staff of said company are not competent enough to do this then they should hire some one who is.
It has been like this for a very long time.
Yes, there's how to do it and then there's how it's done. Often different. Even more of a mess in a hybrid environment, particularly a hybrid older environment.
It could have been done in a simple, transparent and wholly documented manner... unfortunately this was Microsoft and it was created at a time when they were still intentionally screwing with and obfuscating their own file formats to ensure that competing software couldn't use them.
In some situations, such as when you've hardened the server because of, I don't know, Hafnium attacks, you have to enable basic auth. There is even a setting for it buried deep in the windows proxy extensions. I think the idea is to force everyone on to a domain and thence to Azure and then all your e-mail are belong Satya.
There are other, simpler and more reliable ways of doing the initial handshake but they use open protocols…
to remember sendmail config with less loathing. Perhaps instead of "user friendly" or error tolerant programmers could revert to GOTO ERROR-EXIT. Making everything idiot proof seems to be just helping companies sell more junk software. Mines the one with Line Noise for Beginners in the pocket
I think when it comes to the trauma inflicted by manually editing sendmail.cf before the m4 processor, sendmail.cf still has the edge.
That said, you must be a masochist or a consultant milking it for money to recommend Exchange as a reliable email facility - it is anything but.
Cryptolockers only work in a windows configuration that is identical to *nix admins running everything as root. Windows doesn't have to be run this way; the tools to change this are available free of charge out of the box. The problem is simply that people don't bother to use them.
If people can't be assed to figure out how to secure a windows installation then I suspect you'd find that if Microsoft went out of business then the same people wouldn't bother to figure out how to secure a *nix installation either, and the problem would just move between vendors with the users.
Well, "yes and no". A cryptolocker requires root access to encrypt things. It doesn't necessarily follow that it needs a user logged in with admin permissions. I'm sure there are plenty of 0-day privilege escalation exploits out there. Like, for instance, that recent one where you plugged in a Razer mouse and the installer got hijacked.
Escalation exploits don't only exist in Windows systems, for example, that SUDO flaw in *nix that was reported earlier this year.
A cryptolocker does require that the user be willing to allow any piece of arbitrary code to run on their machine.
If you set a software restriction/applocker policy to only allow programs installed in %program files% to run for normal user accounts then immediately users become incapable of being able to run any form of trojan. And the baseline requirement for the cyber essentials minimum standard is that you approve executables by an MD5 hash, not just by path.
Because they have managers who are sufficiently unaware of tech consequences to be deluded by glossy magazines and expensive lunches. In addition, keeping it actually alive is not their problem, it's yours.
And thus, the perfect storm, and a company that has remained in business despite delivering code that would not pass the most basic security check if it were ever publicaly audited (at least, that's what the never ending stream of patches suggest).
You must give them this, though, what their devs lack in talent, their sales and marketing people more than make up for it. It's not called S&M for nothing..
/s
No, you properly configure your DNS records for AutoDiscovery. Any Exchange Administrator who has worked with Exchange any time in the last 15 years should know this.The problem is so may do not.
When I was a consultant fixing AutoDiscover was one of the most often things done when contracted to work on Exchange.
The whole autodiscover via DNS/HTTP setup was always broken and a sign of a company that neither understood the Internet nor cared about it. The assumption was everyone would use Outlook with Exchange, and therefore spamming anyone who didn't with irrelevant requests was acceptable.
Whoever designed and implemented it should be taken out and shot. Twice.
A few requests that return 404 is fine. If your servers are loaded so heavily that they can't handle that, they'll struggle anyway.
It's not any significant load beyond the NODOMAIN response from a DNS query.
What would be better would be an option to attempt autodiscovery or not - that would've saved me a lot of time over the years waiting for it to try the various methods before allowing me to enter the correct details manually.
...what the rather opaque "autodiscover" was doing when used in code to connect to an Exchange mailbox.
Now that I know, I have to say, I'm not very impressed at how shoddily it has been designed. Both with the "failing upward" to attempt to authenticate against a fixed TLD (I mean, just WHY?), and to being designed so that the initial connection attempt contains credentials...
I suppose I shouldn't be that surprised, given that the "protocol" if you can call it that, came about from the people who wrote MS Exchange.
With a correct Exchange configuration at the time of configuring the client, Outlook won't fall back on legacy authentication or even try the old autodiscover mechanisms responsible for the vulnerability. It's only if the system was configured prior to the introduction of newer mechanisms that the vulnerability exists and even then, to mitigate it, you can enable Security Defaults, forcing folks to set up fresh profiles which reject old mechanisms regardless.
This is like pointing out that Windows has gaping security holes in VPN functionality because the system supports PPTP.
It's all by design.to keep older systems working, even if it's less secure to do so.
But the rub is, all these guys did was just register some domain names and setup a webserver, and suddenly scores of random clients started flinging (nearly) clear-text passwords at them. The world-at-large is apparently teeming with MS clients who just can't wait to send credentials to unknown and unverified servers that happen to match a name pattern. That's the bad part.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
