back to article Story of the creds-leaking Exchange Autodiscover flaw – the one Microsoft wouldn't fix even after 5 years

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 …

  1. A random security guy

    Microsoft will not because they can

    Microsoft is back to where it was 20 years ago; arrogant and too big to change.

    So they have NO need to change. Organizations change only when they face pain. Organizations feel pain only when management feels pain. The pain has to be personal; they have to lose their jobs.

    I still remember programming to Windows, Outlook, and exchange API's which crashed at random intervals. There is even a library called Outlook Redemption to help you write somewhat decent software.

    1. Anonymous Coward
      Anonymous Coward

      Re: Microsoft will not because they can


      It never left. It was just better camouflaged for a while.

  2. Anonymous Coward
    Anonymous Coward

    Autodiscover order

    The autodiscover order is boneheaded in that it checks the root domain before checking for autodiscover.domain. This has caused no end of issues where the clients website is on some other hosting. Badly configured cPanel sites are particularly annoying. They return a valid format autodiscover response but with incorrect details. At this point the client just shrugs its shoulders and quits.

    The root domain method is completely useless for anybody on O365 and pretty much useless for anyone else.

    It is possible to disable the various autodiscover methods in Outlook through GPO or reg hacks, so we normally disable everything except autodiscover.domain.

    Microsoft and other client vendors should just drop the root domain check, or at the very least move it down the order so it is checked after every other method has failed.

  3. IGotOut Silver badge

    Hold on...

    MS is being targeted but...

    "What I found was that there were a bunch of email clients including Outlook"

    So is it an Outlook client issue, an MS Windows issue, or a general email client issue?

    1. Anonymous Coward
      Anonymous Coward

      Re: Hold on...

      General client issue for mail clients that use autodiscover, but MS are responsible for creating autodiscover.

    2. Marco van Beek

      Re: Hold on...

      Most of the above.

      Microsoft (I guess the Exchnage team) designed the AutoDiscover mechanism, decided the sequence, and then publicised how to use the protocol. Everybody who wanted an email client that could talk to Exchange then coded up their own version of what that protocol document, including the MS Outlook coders.

      So the original error is in the protocol, further compounded by no coders along the way going "WTF - This looks wrong". Even BlackBerry, those supposed to be the gods of hardened mobiles didn't see a problem with this protocol.

      So the ONLY thing it isn't of the above is a Windows thing. Yes, in the original response to me, they did say that there needed to be a malicious presence along the way or at the web server. Hello? We are talking about the Internet, aren't we?

      1. Anonymous Coward
        Anonymous Coward

        Re: Hold on...

        The original error is not in the protocol. They specifically said it is already recommended for clients to 'never accept an SSL certificate without a matching host name'.

        Van Beek then goes on to confirm that MS' own test tool is the only client which does so. For me, this is a failure on the part of the client developers (including Outlook developers, of course) - but not the protocol team.

        I guess it's just cool to hate on MS

        1. Anonymous Coward
          Anonymous Coward

          Re: Hold on...

          "I guess it's just cool to hate on MS"

          This may be true but has nothing to do with the problem.

          MS stating this is how to do things correctly .... then their *own* Outlook devs getting it wrong, proves that the issue is more than likely out there as obviously the 'right' way is not *obvious' !!!

          How many times have MS & other Big S/W vendors worked to address common errors/issues in code that cause stupid problems that are *not* of their own making.

          As Outlook needs fixing anyway, do the deed and *fix* it and than you can publicise .... yes even MS can make mistakes but it is *now fixed* and the 3rd party e-mail client devs need to follow suit.

        2. Marco van Beek

          Re: Hold on...

          Actually, the problem IS the protocol. The sequence of host names is completely wrong. Why have the option of a DNS or SRV record if you don’t check it first? Why write a protocol that assumes the host name of the Exchange server is on the root of the domain when it is highly unlikely to ever be so?

          And lastly, why not have some sort of handshake in the protocol before just handing over the password. I don’t think people appreciate how big a deal this really is. Every CyberSecurity person will tell you to keep public and private systems separate. But Microsoft designed a protocol that BY DESIGN leaves the safe corporate environment FIRST?

  4. jezza99

    Ignorance of certificate technology

    I used to manage certificate services for my then employer, and as I gained skills became aware of how absolutely critical they are to modern IT security. Including the bit that clients must always fully validate any certificate they receive.

    Yet knowledge of this technology is known to so few systems admins and application developers.

    No wonder practical IT systems, including big name ones, still contain so many security holes.

    1. Gene Cash Silver badge

      Re: Ignorance of certificate technology

      I remember developing client-server SSL certificates for my garage door. Something I'd rather have secured.

      All the posts on stackoverflow were "here's how to disable checking a certificate" so your code doesn't generate any errors. It accepts ANY certificate, but the important part was no errors!

      I know it's stackoverflow, but that's a low enough bar to not even trip over it.

    2. Anonymous Coward
      Anonymous Coward

      Re: Ignorance of certificate technology

      Mail clients will generally check that a certificate is valid to the extent that it is issued by a trusted issuer and in date. That doesn't stop you using a valid cert for dodgy purposes though. If you put a Lets Encrypt cert somewhere (as was done in this case) then the client will accept it without throwing a warning/error.

      CAA records now exist so you can declare which CAs are able to issue certs for your domain using DNS. Haven't seen them used much yet though and I am not sure if mail clients check them.

    3. big_D Silver badge

      Re: Ignorance of certificate technology

      And most systems, including most browsers, ignore certificate revocation or certificate pinning, for example. The former is too much hassle (i.e. it takes time to get a response to see if the certificate has been revoked, so it is usually ignored) and pinning is used by so few people that Google removed it from Chrome.

  5. davef1010101010
    IT Angle

    So what we're really saying is...

    that all those ex-customers of mine who refused to configure an Autodiscover record correctly or at all because it was a security risk are screwed, and those who configured it correctly are fine.

    Where's the I told you so icon?

  6. Pascal Monett Silver badge

    Not a vulnerability

    As long as you play nice and only talk to servers you trust.

    Hey, Borkzilla, did you know there is this thing called hackers ?

    They tend to not play by the rules you dictate.

    But okay, I understand that that is not your problem.

    1. Zippy´s Sausage Factory

      Re: Not a vulnerability

      I agree - it's an odd position for Micros~1 to take. "You can avoid being hacked by making sure you don't talk to hackers in the first place, so it's not a vulnerability". I... I don't think that's how it works...

  7. Uplink


    I would like to chime in and say that this problem isn't really a problem. Stop bothering me and my company.

    Bill Gates

    Lagos, Nigeria

    Sent from my iPhone.

  8. redpawn

    The lockless back door

    is part of the original design, so we consider it secure as you should only associate with trusted neighbors and businesses.

  9. Bartholomew

    broken by design

    From a basic security perspective this 'feature' should be disabled by default, and be a complete and utter nightmare to enable. It is so flawed it was probably designed to be that way by a gagged FISA court order.

    1st problem is that the client tries to connect to the root domain and works it's way back to where it's domain is.

    So does autodiscovery. respond ? yes/no ? If No then try maybe try or or (depending on which domain name the client is in).

    OK well then move back one level closer to where you are.

    2nd problem is that the server can respond in basically plaintext and tell the client "I'm sorry I have no idea what that encrypted gibberish you are trying, can you just base64 encode the username and password (plaintext basically) and send them to me, we will try that"

  10. Anonymous Coward
    Anonymous Coward

    Maybe they now could cough up the bug bounty they avoided then?

    AFAIK, MS ran at the time of that first discovery a fairly substantial bug bounty program. As far as I can tell from the story, it appears Microsoft never paid out for that one and, given the depth and breath of this yes-it's-a-lot-bigger-than-we-admit discovery I think the dosh would be more than due.

    However, I won't hold my breath for it, as that would amount to Microsoft admitting that (a) they grossly underestimated/underplayed the seriousness of what was found and (b) it was actually their fault instead of the usual blaming of long suffering administrators and users for not configuring it right, applying patches within msec of a bug being reported or any other excuse that's used on the golf course to stop executives from looking elsewhere for an operating system they can actually trust.

    Time to actually do some work on security, but this time for real. Vista's "you moved the mouse, allow yes/no" was an example of how NOT to do it.

    1. Marco van Beek

      Re: Maybe they now could cough up the bug bounty they avoided then?

      I can confirm the b%##ers never paid up.

  11. Anonymous Coward
    Anonymous Coward

    It's worse than that, he's dead Jim, dead Jim, dead Jim

    (yes, you recognised it correctly :) ).

    Just in case you didn't pick up on the gravity of this problem, remember that Microsoft uses the combination of email address and password as SSO - one ring to rule them all, so to speak. Once you have that combination you have in principle the keys to the kingdom and it's been handing those off to the well informed for five years now.

    Christ what a mess - after this has been patched it's best to have just about everyone who uses Microsoft products change their password. And no, don't use that app idea, that smells too much like just a new way to track people.

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