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

Redmond reckoned protocol weakness is not a security vulnerability

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 IT consultancy Supporting Role, emailed the Microsoft Security Response Center to disclose an Autodiscover exploit that worked with multiple email clients, including Microsoft Outlook.

"Basically, I have discovered that it is extremely easy to get access to Exchange (and therefore Active Directory) user passwords in plain text," he wrote. "It doesn't necessarily require any breach of corporate security, and at its most secure, is only as secure as file level access to the corporate website."

His report received a case number from Microsoft and a reference number from US-CERT.

His proof-of-concept exploit code, which affected Outlook (both Mac and PC), default email apps for Android and iOS, Apple Mail for Mac OS X, and others, consisted of 11 lines of PHP, though he insisted the exploit probably could have been reduced to three lines.

He attached an explanatory PDF with his note, which described the behavior of Microsoft Autodiscover protocol when email client software tries to add a new Exchange account.

Five years on

Last week, security firm Guardicore offered its take on the problem with the Autodiscover protocol, explaining that the "back off" mechanism for resolving domain names makes it trivial to set up servers on Autodiscover TLDs to intercept hundreds of thousands of credential transmissions from systems that haven't been properly secured.

"What I found was that there were a bunch of email clients including Outlook that were more than happy to pass over their credentials to a web server within your domain tree and what Guardicore found was that in many cases it kept going up the tree to the TLD, meaning you were no longer just worrying about your own web server (or the server that hosted your domain)," explained van Beek in an email to The Register.

He found that if an Outlook client invokes the Autodiscovery protocol to configure itself and the server responds with a WWW-Authenticate response instead of, say, a 404 not found error, the client software answers by transmitting – in Base64-encoded plain text – the username (the full email address and/or the local part of the email address) and the password that the user entered as part of the email client set-up wizard.

"All Exchange clients (from about 2007 onwards) use a method called Autodiscover to get their settings automatically," he said. "If they are outside an Active Directory network (or a non-Active Directory aware device, like a smartphone), they will first contact the SSL port on the root A address."

"This may not even go to their website if they are on a shared server," he explained. "There is no way to prevent this behavior, so if someone gets into wherever that traffic goes, they will be able to plant the code and sit back and wait."

Van Beek said he and Guardicore's veep of US security research Amit Serper separately found the same problem with exposed credentials.

"The main difference is that he found a way to get them away from the primary email domain, whereas I stopped when I realized most email clients didn't even check the SSL certificate before handing over the goodies," he explained.

He added that while Serper had to force the authentication from Digest Access Authentication to Basic Authentication, he always saw credentials in Basic.

"I don't know if that was what they did at the time, and Digest has been introduced since, or if Apache just asked for Basic Authentication," he said. "I suspect the latter."

Not a problem says Redmond

In any event, Microsoft acknowledged on August 11, 2016, that it had reproduced the issue in van Beek's report. Then on August 30, 2016, the Windows titan responded to van Beek by saying the report doesn't describe a genuine vulnerability:

Our security engineers and product team have reviewed this report and determined that it is not a security issue to be serviced as part of our monthly Patch Tuesday process. "Never accept an SSL certificate without a matching host name" is already recommended for clients in the doc cited by your report:

“Before you send a request to a candidate, make sure it is trustworthy. Remember that you're sending the user's credentials, so it's important to make sure that you're only sharing them with a server you can trust. At a minimum, you should verify: That the endpoint is an HTTPS endpoint. Client applications should not authenticate or send data to a non-SSL endpoint. That the SSL certificate presented by the server is valid and from a trusted authority.”

"This response casually forgets to consider that a hacked web server still retains a perfectly valid certificate – it just happens to use that trusted tunnel to serve up problems," said van Beek. "Also, I have only found one Exchange client so far which actually checks the hostname against the certificate, which is Microsoft's own test tool."

Van Beek said he thought it was incredible that Microsoft confirmed the behavior he reported within hours but does not consider it to be a problem. He suggested three mitigations: changing the order of operations so that DNS gets checked first; never accepting an SSL certificate without a matching host name; and reviewing why and when clients respond to authentication requests.

The Register asked Microsoft via email whether, in light of van Beek's 2016 report and Guardicore's report last week, the IT giant plans to take any steps to address credential exposure and whether it believes its guidance adequately addresses the problem.

"We are continuing to investigate the specific scenario shared by the researcher," a Microsoft spokesperson responded. ®

Similar topics

Broader topics

Other stories you might like

  • GPL legal battle: Vizio told by judge it will have to answer breach-of-contract claims
    Fine-print crucially deemed contractual agreement as well as copyright license in smartTV source-code case

    The Software Freedom Conservancy (SFC) has won a significant legal victory in its ongoing effort to force Vizio to publish the source code of its SmartCast TV software, which is said to contain GPLv2 and LGPLv2.1 copyleft-licensed components.

    SFC sued Vizio, claiming it was in breach of contract by failing to obey the terms of the GPLv2 and LGPLv2.1 licenses that require source code to be made public when certain conditions are met, and sought declaratory relief on behalf of Vizio TV owners. SFC wanted its breach-of-contract arguments to be heard by the Orange County Superior Court in California, though Vizio kicked the matter up to the district court level in central California where it hoped to avoid the contract issue and defend its corner using just federal copyright law.

    On Friday, Federal District Judge Josephine Staton sided with SFC and granted its motion to send its lawsuit back to superior court. To do so, Judge Staton had to decide whether or not the federal Copyright Act preempted the SFC's breach-of-contract allegations; in the end, she decided it didn't.

    Continue reading
  • US brings first-of-its-kind criminal charges of Bitcoin-based sanctions-busting
    Citizen allegedly moved $10m-plus in BTC into banned nation

    US prosecutors have accused an American citizen of illegally funneling more than $10 million in Bitcoin into an economically sanctioned country.

    It's said the resulting criminal charges of sanctions busting through the use of cryptocurrency are the first of their kind to be brought in the US.

    Under the United States' International Emergency Economic Powers Act (IEEA), it is illegal for a citizen or institution within the US to transfer funds, directly or indirectly, to a sanctioned country, such as Iran, Cuba, North Korea, or Russia. If there is evidence the IEEA was willfully violated, a criminal case should follow. If an individual or financial exchange was unwittingly involved in evading sanctions, they may be subject to civil action. 

    Continue reading
  • Meta hires network chip guru from Intel: What does this mean for future silicon?
    Why be a customer when you can develop your own custom semiconductors

    Analysis Here's something that should raise eyebrows in the datacenter world: Facebook parent company Meta has hired a veteran networking chip engineer from Intel to lead silicon design efforts in the internet giant's infrastructure hardware engineering group.

    Jon Dama started as director of silicon in May for Meta's infrastructure hardware group, a role that has him "responsible for several design teams innovating the datacenter for scale," according to his LinkedIn profile. In a blurb, Dama indicated that a team is already in place at Meta, and he hopes to "scale the next several doublings of data processing" with them.

    Though we couldn't confirm it, we think it's likely that Dama is reporting to Alexis Bjorlin, Meta's vice president of infrastructure hardware who previously worked with Dama when she was general manager of Intel's Connectivity group before serving a two-year stint at Broadcom.

    Continue reading

Biting the hand that feeds IT © 1998–2022