** This doesn’t concern Exchange Online in any way, only on-premise versions **
Today Guaricore lab team discovered on-premises Exchange autodiscover vulnerability. I want to call my blog post “Autodiscovering the Great Leak” but that seems like too much as I didn’t invent that. But it was an excellent topic though.
But first let’s find out what autodiscovery is for Exchange clients and how it works.
Table of Contents
Autodiscover purpose
Autodiscover will give the users their email server settings automatically based on the prefix. It will finally discover the xml file located inside Exchange thru Exchange Web Service interface.
Client will try methods in this order.
SCP (Service Connection Point) in Active Directory
If the user is inside the network where the Exchange is, it will find Service Connection Points from AD schema configuration.
Root Domain check
Clients are inside the network and using the domain either with in a workgroup or in the domain.
Autodiscover DNS check
But typically the clients will find their settings with autodiscover DNS if they didn’t already get it from Service Connection Point.
Local Autodiscover.xml file.
Like c:\windows\system32\drivers\etc\hosts file this can force your client to get settings that you force for them. You will add XML and create a reg dword for the location, outlook starts and it will locate the file.
HTTP Redirect
HTTP redirect will be used ito redirect request to different address that it originally came to. And as SSL cannot be created to SSL it has to http -> https.
SRV DNS records check
SRV DNS will instead be used if you example only have one FQDN certificate for your Exchange services but you have multiple email domains for users. So user has UserPrincipalName as firstname.lastname@primarydomain.fi but has email address as firstname.lastname@secondarydomain.fi or you just have users with multiple PrimarySmtpAddresses for your users.
Cached URL in the Outlook profile
When autodiscover was successful Outlook will cache the result and use that one as long your email settings don’t change or you aren’t adding a Shared mailbox etc. to your profile.
Exchange Hybrid autodiscover redirect
This isn’t a method for autodiscover rather it’s a result of successful autodiscover action after mailbox migration but I wanted to explain this coz I love this process. With Exchange Hybrid configuration the user autodiscover checks TargetAddress attribute and sent’s the user on it’s way to Exchange Online and then modify the settings based on that attribute to EXO until the end of time or migration back to on-premises.
In an Exchange Hybrid the autodiscover redirect also works for Mobile clients and provides them new mailbox settings after the migration so it’s just excellent, no need for third party tools when source is Exchange, no matter what version as you can put a new Exchange server version between the old that has the DB’s and EXO. The last version that was free to use with Hybrid key was Exchange 2016 for 2019 and up you need to buy a license.
Now when we covered Autodiscover function, we can cover the leakage.
Autodiscovering the Great Leak
Guardicore identified two possible scenarios.
The credentials that are being leaked are valid Windows domain credentials used to authenticate to Microsoft Exchange servers. The source of the leaks is comprised of two issues:
- The design of Microsoft’s Autodiscover protocol (and the “back-off” algorithm, specifically).
- Poor implementation of this protocol in some applications.
It’s kind of ironical that the features that Microsoft provided for the end-user experience to be easier turn against them selves.
Like Guardicore is saying in their announcement that the Back-Off feature (Not official name for this feature, but close enough) will start from users FQDN email domain name and then try same the domain with http.
After that one it will “fail” to https with only domain name and if that fails it tries http with domain name only.
And this flow makes end-users happy when they can connect the their mailbox.
Below you see the downgrade to Basic Auth.
The mitigation for the leak
The fix is simpler thank you think. It will add for all the discoverable domains an localhost ip of 127.0.0.1
There has been a lot happening with Exchange server exploits during these two years.
Hopefully you have rolled-up to newest Cumulative update and needed patches because some one could moving laterally inside your environment and wouldn’t even known it.
To find the movement you could use Defender for Identity.
Like I said in the beginning ** This doesn’t concern Exchange Online in any way, only on-premise versions **
Cheers and bye,
RSS - Posts