as most Android malware clickbait stories rely on a compromised Windows machine further up the "problem chain"...
Microsoft has downplayed the seriousness of an alleged Exchange auto-discovery vulnerability, saying that it sees no need to patch the reported security weakness. Redmond contends that its existing security advice covers the issue, a point disputed by flaw-finder Marco van Beek. Van Beek explains: “I recently discovered that …
"rely on a compromised Windows machine further up the "problem chain"..."
Usually a compromised Linux machine (e.g. a web server) I think you mean.
This might surprise you, but Windows based systems are statistically about 5 times less likely to be hacked when used as internet facing webservers than Linux based ones (yes that's allowing for market share) !
Just sends your login + password encoded in base64 in every HTTP request... so if someone intercepts your HTTPS connection and providing you click through the 'warning' (who doesn't)... then the attacker doesn't even need to crack anything at all... he has your login/password right there. As it's office365.. just login from anywhere.
.. it's about actually being unable to fix it as this is not an error in code, it's a weakness in the protocol itself.
This is a problem Microsoft can't even fix if it wanted to, because this protocol flaw is part of every single MS Exchange CLIENT out there. Android, iOS,
OSX MacOS, Windows, Linux - to address this requires changing the very protocol every client uses to talk to MS Exchange. What makes this especially ugly is that most companies are well aware of the need to secure their Exchange server, but usually spend less on securing a public webserver, it may not even have the benefit of a firewall in front of it.
The good news is that properly securing the domain website seems to be enough to mitigate the risk, but if that hasn't been done it seems almost trivial to create an exploit for it. *Not* good.
At $JOB, we (IT) maintain ~90% of our websites. The final 10% are those that other departments run because they don't want to go through our processes, eg Marketing want a WordPress site, so they use a WP hosting company, with us providing DNS. Similarly, some of our hosted SaaS providers, like our HR system, payroll etc, use our sub-domains for branding.
This kind of exploit means that even if you secure all your own servers, you are relying on third parties to not be compromised to prevent an attack on your mail server. Not good at all.
Admittedly, we don't use Outlook..
'Virus Outbreak' aka 'Microsoft Outlook' has to be THE biggest security crater ever released by Micro-shaft, EVAR. I can't see any MORE horror (for I.T.) than a shop that actually USES it!
seriously, what GOOD is it REALLY? just use T-bird [and don't view as HTML or insert graphics inline] and be done with it! All that *cruft* is just a waste of bandwidth, and opens you up for spammed viruses and trojans (all those '.docm' and '.zip' etc. attachments, yeah)
".. it's about actually being unable to fix it as this is not an error in code, it's a weakness in the protocol itself."
I disagree about being unable to fix it. They have dropped bad protocols in the past, sure this is a big one but they should fix the protocol and work on fixing the clients and informing other client developers. If they did that there would be some hope that they work a bit harder to minimise attack surfaces in the future, everyone gets burnt by a protocol eventually - it's how you react to being burnt that counts in the long run.
The reported stance of MS indicates that they are quite happy to be burnt along with their platform and their users.
> They have dropped bad protocols in the past,
And, given the fact that they (largely) control the endpoints, it's surely not beyond their capability to engender a new Activesync protocol (activesync-ng) that doesn't have those flaws. Default the new versions to trying that protocol first and a reasonable chink of the problem goes away.
Then they can publish the new standard and all the independent app developers can update their apps.
Yes, the sky is a different colour in my world. A nick cerise-pink in fact. Why do you ask?
Ultimately Slurp has to fix it in some manner. The problem is likely it will cause a lot of problems, money, and possibly customer goodwill to fix it. Refusing to outline how they fix it makes the users a well known, exploitable target. Slurp seems to be relying on how difficult they think flaw is to exploit; badly overestimating its difficulty to use.
This basically means that you can, with any rogue webserver, and DNS or a hosts file entry siphon the credentials of users.
Imagine, Schiphol airport free wifi, with a nice little proxy application, milking the username and password of every traveler, as the bloke from overseas attempts to connect to wifi ... the phone's connections get redirected to the login page, so do the exchange/365 clients ... SCARY! Bloody sure they send the username/password to that thing ... log files anyone ?
" log files anyone ?"
Complete proof of concept and also verified by Microsoft themselves. May have found one version of Outlook (v15 on PC) that doesn't send credentials, but Outlook 15 on Mac does, and I have also seen iPhones, Blackberries and Android devices all display the behaviour.
There are two things that Microsoft should do immediately. 1) Change the order that autodiscover is supposed to use to check DNS first for a SRV record, then for autodiscover.<domain> and then the root domain, and 2) To issue a warning to all Exchange client developers to check the SSL certificate for a valid name and chain, along with the revised protocol.
So it's not a vulnerability as it already requires you to have access in order to take advantage of it.
This is like saying "From the inside of the house I can open the window then go outside and climb in". Sure, but why bother if you are already in?
Web server =! Exchange server. A company could have their own corporate Exchange server, which would hold a lot of important and sensitive data, but contract out the running of their web server to a third party.
A web server might get compromised and normally you would consider the servers at a different location using different authentication to be OK. But with this problem it could lead to the user accounts on your corporate Exchange server are also compromised, along with a lot of your corporate data, and you would not even have a single failed login on your Exchange server because your email programs have the given the correct username and password to the compromised web server.
If you don't think this is problem that could lead to serious consequences then talk to the World Anti-Doping Agency or the Democratic National Committee.
If they can run code as your login they can get your password in approximately a gazillion different easy ways.
Adding a more complicated and difficult method to the list does not make your position worse because your position is already "completely owned".
"This is like saying "From the inside of the house I can open the window then go outside and climb in". Sure, but why bother if you are already in?"
It's a bit more like being able to circumvent the front door once you're already inside tbh. Front doors usually have better security than internal doors do. So getting onto the web server is like breaking in through a window and then being able to get around the house through internal doors, avoiding having to pick the front door's lock.
The point MS is making in response is that maybe the problem here is more we should stop people from smashing the window in the first place, rather than that the internal doors should all be replaced with iron-reinforced triple-locking front doors in case a window IS smashed. And they're basically right. The web server is the vector in this instance, and any 'fix' to this issue should really be applied at that location.
The point MS is making in response is that maybe the problem here is more we should stop people from smashing the window in the first place, rather than that the internal doors should all be replaced with iron-reinforced triple-locking front doors in case a window IS smashed.
This is a false dichotomy. Both approaches are valid and important. Perimeter security is obviously important, but beefing up internal security and compartmentalization also yield better results than doing without. The crab method* of security has long been discredited and should not have any supporters at this time.
* Set up a hard, spiky shell on the outside and leave the soft, tasty inside undefended to anything that manages to get through the first and only layer of security.
I think "domain web server" is the ambiguity here.
As I read it, I think MS are assuming that the means you need to hack the Active Directory server to make it happen. (At that point, you already have bigger problems than password snooping).
I read it as "a web server in the same domain". Which could possibly be spoofed (and I'm sure that's easier than hacking the Active Directory server), and is probably going to go a long way towards hacking your Active Directory server.
Still, a typical Microsoft response: we're right, you're wrong, now shut up.
No, what they mean is a web server that is in the same domain, as in .mydomain.com as the mail server.
This vulnerability requires the attacker to take control of a webserver in the same domain. They then need to setup a site or just compromise a current site that is secured by SSL/TLS, as it requires the connection to be secured for the password to be sent. This occurs because the domain is trusted, like all the other sites that are in your domain that are trusted to take your credentials.
This isn't really a fault with the protocol, it could be reduced by limiting the urls that it will send the passwords to, but then you would have to setup all of those destinations to ensure one isn't taken by an attacker. You could also reduce the chances by only sending the u/p to the server that matches a specific certificate only, but that would require the client to confirm that the certificate is the correct one, which would just be clicked through anyway.
The only real way is to just not trust your own domain for this to be fixed, which well, you don't want to do.
If it was possible to fix this then you could just compromise that corp site that most likely requires authentication and then taking the u/p from the users that connect to that site instead. Which leads back to what the real problem is, that website was able to be compromised.
This isn't really a fault with the protocol, it could be reduced by limiting the urls that it will send the passwords to, but then you would have to setup all of those destinations to ensure one isn't taken by an attacker
I disagree 100%. If I set up a client to talk to a server with as FQDN someserver.mydomain.com, it has in my opinion no business or reason to attempt a chat with a system called mydomain.com which is an ENTIRELY DIFFERENT machine.
That is the exact problem at hand: your precious email client, set up to exclusively talk to machine X is in reality first having a quiet chat with machine Y before it does what you expect it to do.
I'd love to know if this is already out in the wild as this will easily show up on any network analyser.
As DNS hijacking is easier than hacking into a server you'd think that "...provide[ing] a user's password in plain text..." to anything would not be a great idea especially domain passwords. I always thought the password was sent as a hash and then matched on the server and never sent in plain text which seems exceptionally easy to compromise.
"It sounds like MS expect you to control your domain and secure it. To me that doesn't sound massively unreasonable."
Not quite. It relies on HTTPS, not HTTP, so you might have a perfectly secure non-HTTPS website on a shared server (or even behind a firewall with port forwarding) and HTTPS is pointed at a control panel which you do not manage, or have any real sort of access. That's how I found it. We installed fail2ban on our shared web servers and one of our our clients got banned from their own website because someone was setting up a new iPhone and fail2ban was picking up failed login attempts on the control panel.
And not to forget that all of the Exchange clients I have seen don't check the certificate name either. That list is currently:
• Mac OS X/10.10.4 (14E46); ExchangeWebServices/5.0 (213); Mail/8.2 (2102)
• Mac OS X/10.10.5 (14F27); ExchangeWebServices/5.0 (213);
• MacOutlook/188.8.131.52119 (Intel Mac OS X 10.9.5)
• MacOutlook/0.0.0.160109 (Intel Mac OS X Version 10.11.3 (Build 15D21))
• MacOutlook/0.0.0.160212 (Intel Mac OS X Version 10.11.3 (Build 15D21))
• MacOutlook/f.16.0.160506 (Intel Mac OS X Version 10.11.4 (Build 15E65))
• MacOutlook/184.108.40.206709 (Intel Mac OS X Version 10.11.5 (Build 15F34))
• Mac OS X/10.10.3 (14D136); ExchangeWebServices/5.0 (213); Mail/8.2 (2098)
• Mac OS X/10.10.5 (14F27); ExchangeWebServices/5.0 (213); Mail/8.2 (2104)