back to article Microsoft snubs alert over Exchange hole

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 …

  1. Anonymous Coward
    Anonymous Coward

    weird

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

    1. Anonymous Coward
      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. oldcoder

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

    1. Anonymous Coward
      Anonymous Coward

      Re: office365 does this...

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

  3. Anonymous Coward
    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.

    1. Tom 38

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

      1. Anonymous Coward
        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. bombastic bob 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)

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

      1. CrazyOldCatMan 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?

    3. a_yank_lurker

      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.

    4. Hans 1
      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 ?

      1. Marco van Beek

        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.

    5. oldcoder

      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.

  4. Ben Liddicott

    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?

    1. lansalot

      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.

      1. Ben Liddicott

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

    2. JohnEdwards

      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.

      1. Ben Liddicott

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

    3. Naselus

      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. Robert Helpmann??
        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.

        1. Jamie Jones 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. Richard 12 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.

      2. oldcoder

        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.

  5. Zippy's Sausage Factory
    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.

    1. Anonymous Coward
      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. Anonymous Coward
        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

        1. razorfishsl

          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.

      2. Hans 1

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

      3. oldcoder

        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.

  6. depicus

    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. Anonymous Coward
      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).

      1. depicus

        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.

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

    1. oldcoder

      Re: So, in simple terms

      It stupidity to assume the network itself is secure.

      Passing any password in plaintext is a MASSIVE mistake.

    2. Marco van Beek
      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.

      1. Marco van Beek
        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

POST COMMENT House rules

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

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like