Microsoft Exchange Autodiscover protocol found leaking hundreds of thousands of credentials
Email clients fail over to unexpected domains if they can't find the right resources
A flaw in Microsoft's Autodiscover protocol, used to configure Exchange clients like Outlook, can cause user credentials to leak to miscreants in certain circumstances.
The upshot is that your Exchange-connected email client may give away your username and password to a stranger, if the flaw is successfully exploited. In a report scheduled to be published on Wednesday, security firm Guardicore said it has identified a design blunder that leaks web requests to Autodiscover domains that are outside the user's domain but within the same top-level domain (TLD).
Exchange's Autodiscover protocol, specifically the version based on POX XML, provides a way for client applications to obtain the configuration data necessary to communicate with the Exchange server. It gets invoked, for example, when adding a new Exchange account to Outlook. After a user supplies a name, email address, and password, Outlook tries to use Autodiscover to set up the client.
As Guardicore explained in a report provided to The Register, the client parses the email address – say, email@example.com – and tries to construct a URL for the configuration data using combinations of the email domain, a subdomain, and a path string as follows:
If the client doesn't receive any response from these URLs – which would happen if Exchange was improperly configured or was somehow prevented from accessing the designated resources – the Autodiscover protocol tries a "back-off" algorithm that uses Autodiscover with a TLD as a hostname. Eg:
"This 'back-off' mechanism is the culprit of this leak because it is always trying to resolve the Autodiscover portion of the domain and it will always try to 'fail up,' so to speak," explained Amit Serper, Guardicore area vice president of security research for North America, in the report. "This means that whoever owns Autodiscover.com will receive all of the requests that cannot reach the original domain."
In an email to The Register, Serper said, "I believe that this was the consequence of careless, or rather, naïve design. [The] same flaws appear in other Microsoft protocols of similar functions."
Sensing a potential problem with making credentials available to any old TLD with Autodiscover, Guardicore acquired several variations on that theme: Autodiscover.com.br, Autodiscover.com.cn, Autodiscover.com.co, Autodiscover.uk, and Autodiscover.online, among others.
After assigning these domains to its web server, Guardicore started receiving numerous requests to Autodiscover endpoints from assorted IP addresses and clients. It turns out a lot of Exchange servers and clients aren't set up very carefully.
... with the Authorization header already populated with credentials in HTTP basic authentication
"The most notable thing about these requests was that they requested the relative path of
/Autodiscover/Autodiscover.xml with the Authorization header already populated with credentials in HTTP basic authentication," said Serper, who observed that web requests of this sort should not be sent blindly pre-authentication.
HTTP basic access authentication is Base64 encoded but is not encrypted, so this amounts to sending credentials in cleartext.
Between April 16, 2021 and August 25, 2021, Guardicore received about 649,000 HTTP requests aimed at its Autodiscover domains, 372,000 requests with credentials in basic authentication, and roughly 97,000 unique pre-authentication requests.
The credentials came from publicly traded companies in China, food makers, investment banks, power plants, energy delivery firms, real estate businesses, shipping and logistics operations, and fashion/jewelry companies.
There were also many requests that used alternatives to HTTP basic authentication, like NTLM and Oauth, that didn't expose associated credentials immediately. To obtain access to these, Guardicore set up a downgrade attack.
So upon receiving an HTTP request with an authentication token or NLTM hash, the Guardicore server responded with an HTTP 401 with the
WWW-Authenticate: basic header, which tells the client that the server only supports HTTP basic authentication. Then to make the session look legit, the company used a Let's Encrypt certificate to prevent an SSL warning and ensure the presentation of a proper Outlook authentication prompt so potential victims enter their credentials with confidence.
- WTF? Microsoft makes fixing deadly OMIGOD flaws on Azure your job
- Microsoft fixes flaw that could leak data between users of Azure container services
- Fix network printing or keep Windows secure? Admins would rather disable PrintNightmare patch
Serper said he has no way of knowing whether anyone has abused this flaw. "However, since these protocol design flaws have been known for a while, I wouldn't be surprised if a threat actor with DNS poisoning capabilities had tried it," he said. "If a threat actor is in the same network as the victim (for example on the same LAN/WLAN), conducting a DNS poisoning attack in order to make the victim leak these credentials is a totally viable scenario."
These Autodiscover problems have persisted despite previous security research that identified related problems. At Black Hat Asia 2017 [PDF], researchers from Shape Security analyzed Autodiscover client implementations in the Samsung Mail app (Android) and the Apple iOS Mail app and found flaws that allowed remote attackers to obtain user credentials via domain name collisions.
Serper in his post advised users of Exchange to disable HTTP basic authentication and suggested adding a list of all possible Autodiscover.TLD domains to a local hosts file or firewall configuration to block unwanted Autodiscover domain resolution. He also urged software vendors to avoid implementing a "back-off" function that fails upwards to an unanticipated domain.
The Autodiscover flaw extends beyond Microsoft to third-party vendors who have implemented the protocol in their own products. Serper said Guardicore is presently working with an unidentified large vendor on this and will publish more details once the remediation process is complete.
Because this issue can be mitigated by proper configuration, it's unlikely Microsoft will treat this as a security issue that demands immediate attention. Serper said it's unclear how the Windows giant will choose to respond. "Microsoft has a track record of dismissing critical issues as features," he said. "With that being said, I can’t imagine why Microsoft wouldn’t address such issues." ®