nav search
Data Center Software Security Transformation DevOps Business Personal Tech Science Emergent Tech Bootnotes BOFH

back to article
Microsoft snubs alert over Exchange hole

Anonymous Coward

weird

as most Android malware clickbait stories rely on a compromised Windows machine further up the "problem chain"...

3
13
Anonymous Coward

Re: weird

"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) !

1
3
Silver badge

Re: weird

And yet, it is Windows machines that are hacked. And with the largest (something around 40 billion) cost to the industry every year for Windows servers.

Not linux servers even though there are more of them.

Windows storing passwords in plaintext is so ... 1960s...

2
1
Anonymous Coward

office365 does this...

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.

6
2
Anonymous Coward

Re: office365 does this...

Maybe you're using a proxy server with basic authentication only?

2
0
Anonymous Coward

It's not about Microsoft WANTING to fix it ..

.. 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.

8
1
Silver badge

Re: It's not about Microsoft WANTING to fix it ..

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..

8
1
Roo
Silver badge
Windows

Re: It's not about Microsoft WANTING to fix it ..

".. 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.

9
0
Silver badge

Re: It's not about Microsoft WANTING to fix it ..

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.

2
2
Silver badge
FAIL

Re: It's not about Microsoft WANTING to fix it ..

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 ?

2
0
Anonymous Coward

Re: It's not about Microsoft WANTING to fix it ..

"Admittedly, we don't use Outlook.."

My condolences. I still remember my last job that didn't have Outlook (many years ago) with horror....

1
2
Silver badge

Re: It's not about Microsoft WANTING to fix it ..

Microsoft DOES NOT want to fix it.

If they wanted to fix vulnerabilities, they would have fixed the 19 year old NTLM vulnerabilities...

Microsfot calls it a "feature".

This is the failure of using Microsoft sub-standandard standards.

0
0

Re: It's not about Microsoft WANTING to fix it ..

" 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.

1
0
Silver badge

Re: It's not about Microsoft WANTING to fix it ..

> 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?

0
0
Silver badge
Devil

Re: It's not about Microsoft WANTING to fix it ..

'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)

0
2

it only takes only four lines of code and a local config file

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?

6
4

Re: it only takes only four lines of code and a local config file

Bother because you can potentially grab credentials that will get you to other parts of the infrastructure you don't already have access to.

10
1

Re: it only takes only four lines of code and a local config file

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.

3
0

Re: it only takes only four lines of code and a local config file

Or just read your credentials from where Outlook stores them, or read them by logging keypresses or...

1
4

Re: it only takes only four lines of code and a local config file

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".

0
4
Silver badge

Re: it only takes only four lines of code and a local config file

"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.

1
1
Silver badge
Childcatcher

Re: it only takes only four lines of code and a local config file

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.

2
0
Silver badge
Coat

Re: it only takes only four lines of code and a local config file

Damnit guys. All these analogies, and not one mention of cars.

What gives?

1
0
Silver badge

Re: it only takes only four lines of code and a local config file

It's like keeping the house keys in the car.

So if a miscreant can break into your car they have the keys to your house.

1
1
Silver badge

Re: it only takes only four lines of code and a local config file

Wrong.

Normally a public facing web server is isolated from the network interior...

It is called a DMZ for a reason - it has less security than an internal server.

0
1
Silver badge
FAIL

Um, spoofing a web server?

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.

3
0
Anonymous Coward

Re: Um, spoofing a web server?

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.

1
0
Anonymous Coward

Re: Um, spoofing a web server?

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.

I

3
0
Bronze badge

Re: Um, spoofing a web server?

Yes in China........

There are a number of Hotels I have stayed at that do man in the middle attacks, against email & Apple update server not to mention the 'usual' HTML injection attacks.

1
0
Silver badge

Re: Um, spoofing a web server?

Which part of the following sentence do you not understand ?

"I have only found one Exchange client client so far which actually checks the hostname against the certificate, which is Microsoft's own test tool.”

1
0
Silver badge

Re: Um, spoofing a web server?

The fault is passing the password in in plaintext in the first place.

The second is using unencrypted passwords for anything.

0
0

DNS Hijacking

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.

1
0
Anonymous Coward

Re: DNS Hijacking

DNS Hijacking would probably be easier to do, but then you would need to secure that domain with a certificate trusted by the client.

Exchange supports, OAuth 2.0 (Online), NTLM (on-premises) and Basic (not recommended).

0
0

Re: DNS Hijacking

A Let's Encrypt cert can be issued in a few seconds if you have control of the domain or even just the sub domain.

1
0
Silver badge

So, in simple terms

If exchange sees a domain name in your email address it'll happily send your password in plain text to any web server that that domain resolves to?

It sounds like MS expect you to control your domain and secure it. To me that doesn't sound massively unreasonable.

0
1
Silver badge

Re: So, in simple terms

It stupidity to assume the network itself is secure.

Passing any password in plaintext is a MASSIVE mistake.

0
0
Holmes

Re: So, in simple terms

"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.

0
0
Holmes

Re: So, in simple terms

And not to forget that all of the Exchange clients I have seen don't check the certificate name either. That list is currently:

• RIM-Q5-SQR100-2/10.3.1.2576

• Mac OS X/10.10.4 (14E46); ExchangeWebServices/5.0 (213); Mail/8.2 (2102)

• Android-SAMSUNG-SM-G900F/101.500

• Mac OS X/10.10.5 (14F27); ExchangeWebServices/5.0 (213);

AddressBookSourceSync/9.0 (1579)

• motorola-XT907/1.0

• MacOutlook/14.5.9.151119 (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))

• Microsoft.Outlook.15

• MacOutlook/15.24.0.160709 (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)

• HTC-EAS-HTCOne

• Mac OS X/10.10.5 (14F27); ExchangeWebServices/5.0 (213); Mail/8.2 (2104)

• HTC-EAS-HTCOnedualsim

• Apple-iPhone7C2/1306.69

• Apple-iPhone6C2/1304.15

1
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

The Register - Independent news and views for the tech community. Part of Situation Publishing