It’s helpful when security researchers such as Guardicore shed light on flaws in Microsoft Exchange. Last week, Tony provided insight into this and tested to see whether Outlook exhibits the purported flaws. Even though it seems so far, the issue is hard to replicate, it shouldn’t distract you from similar issues that aren’t new – and more importantly, the work you need to do to protect your organization from the underlying reason why people want your credentials.
The Autodiscover protocol isn’t mean to have the “fail-up” flaw
One key point is that the purported flaw – a “fail up” behaviour – isn’t how Exchange Autodiscover is meant to function, pointing th a bug in implementation rather than the design of the protocol itself.
The developer documentation on the Autodiscover protocol is clear. After querying Active Directory for a Service Connection Point (defined Autodiscover URLs contained within each server object in the Configuration Container) the next step should be two standard endpoints based only upon the domain name part of the user’s email address.
From there, the client should try alternatives including an unauthenticated GET request to a HTTP endpoint, with an expectation of a 302 redirect response (as Exchange Online uses as part of the autodiscover process) and finally attempting a DNS query for SRV records. Modern Outlook clients for Exchange Online go one step further and use the Direct Connect for Office 365 feature to bypass Autodiscover when a mailbox exists in the cloud.
Therefore, unless a user enters an email such as steve@com or steve@autodiscover.com, it should not attempt to query the TLD.
So, the most obvious conclusion is that a developer has built an Autodiscover implementation that “fails up” – or potentially even recursively fails up. There could be seemingly valid reasons why someone would do this as a workaround – such as for cases where the User Principal Name didn’t match the email address (for example, a UPN of steve@corp.practical365.com versus an email address of steve@practical365.com).
Why is a recent Outlook build shown in Guardicore’s logs?
As most Exchange administrators know, but not all email clients (especially those on mobile devices) following Microsoft’s standards to the letter is incredibly important. In particular, the SRV lookup is often missed, and non-Microsoft clients can ultimately do whatever they want. It wouldn’t be surprising to find third-party applications implementing fail-up or recursive behaviour in their applications, but not in Outlook itself.
In the log excerpt Guardicore provided, a build of Outlook is shown – 16.0.13901, dated approximately one month before the logs were recorded in May 2021. However, as demonstrated last week, Outlook doesn’t appear to perform the “fail up” behaviour described when observing traffic using Fiddler to log actual HTTP and HTTPS requests issued by a standard, up to date, Outlook client.
Last week, Tony provided some insight into what might be happening, as clearly unusual behaviour was observed. As Tony says, without technical information describing the affected configuration, it’s difficult to say.
It’s also disappointing that this information hasn’t been shared publicly so organizations can resolve any underlying misconfiguration – but I’d suspect that the researcher doesn’t have access to the client environments sending credentials to perform some troubleshooting.
What should you do to protect your organization?
In short, make sure you do as Tony recommended last week:
“Check your Autodiscover settings to make sure that they comply with Microsoft guidance. And make sure that you know what clients consume Autodiscover, just in case there’s a real flaw lurking here that attackers can exploit across a range of Exchange server versions and clients.”
If you have correctly configured Autodiscover records, then the “fail-up” behaviour should never be used, even if a particular add-in, client library or configuration setting can cause it.
However – if you do have concerns, then you can attempt to evaluate whether you have clients within your network sending credentials to a TLD containing an Autodiscover domain. If you have a firewall, cloud access security broker or proxy service in use, then you can consider reviewing log files for such requests.
Should you find anything suspicious, then investigate the clients affected using similar methods such as Tony used – with a tool like Fiddler – to determine the software or add-in that is responsible. Naturally, should you find you are affected, please provide a comment on this article.
Security issues surrounding DNS-based discovery protocols aren’t new, and aren’t limited to Exchange Autodiscover
If you control the network that a device connects to it is trivial to override the DNS responses that a device receives. That’s one reason why certificate authorities who go to long lengths validating the ownership of a domain are so crucial to the security of communications.
So, if you’ve ever connected to a public Wifi access point, then you’ll be aware most initially override DNS responses to force users to register via a captive portal. You’ll also probably be aware that this behaviour causes a security alert in Outlook because the captive portal doesn’t have a valid certificate for either Autodiscover, or other web services Outlook attempts to connect to.
As described above though, Autodiscover has a fallback for attempting a connection over HTTP. In theory you could operate a fake access point in somewhere like your local Starbucks – set up a HTTP-only site and create a DNS zone including the Autodiscover records for your specific target domain with records that direct users at the HTTP-only site. Then you could perform a 302 redirect to a site with a valid HTTPS certificate that then attempts to collect credentials. With Outlook though – this won’t work automatically. Outlook has a built-in Autodiscover redirect warning that will require the user to select Allow before it then continues. It’s not perfect, but it’s good enough because Microsoft has already put some thought into securing the experience in the clients they have control over.
The approach which doesn’t rely upon the “fail-up” behaviour could also be applied to many other services on the internet – such as any open-source email service implemented alongside DNS records using a similar automatic discovery method based on RFC 6186.
That being said, I’m not trying to spread fear, uncertainty and doubt. The point is simple – worrying about a fail-up behaviour and simply making sure your Autodiscover records are OK and then moving on isn’t enough.
Don’t let this distract you from the underlying issue
When flaws like this are found, or vulnerabilities are disclosed the focus is on fixing the issue at hand. As IT professionals, we often must put out fires, but we would rather plan to avoid the situation in the first place.
The issue with credential leaks and Autodiscover isn’t simply that a threat actor could use those credentials to read someone’s email. Usually, the credentials will be more useful to gain access to your network and using standard credentials, use lateral movement to find more valuable assets or escalate their credentials.
If you just mitigate against this potential flaw, then you’ll only be waiting for the next one to catch you out. The September 2021 Cumulative Updates for Exchange will allow for automatic mitigation of actual vulnerabilities in Exchange Server which is helpful, and in October 2022, Microsoft will disable legacy authentication against Exchange Online permanently – although you can and should do that sooner.
But even Modern Authentication won’t protect you against the underlying reason why threat actors want your users’ credentials.
Implementing fundamental protections
Many organizations who’ve bought Microsoft 365 E3 or E5 will be looking at the suite as a wider solution for implementing a zero-trust model, and I won’t cover those specifics here. But from an account credential and access perspective though, you need to consider implementing some fundamental protection as part of the wider picture.
Firstly, you need to use multi-factor authentication. If your senior executives don’t like MFA and are rejecting its use, then you should re-evaluate how you deployed the supporting technologies (like Azure AD Join, Intune, Authenticator, Windows Hello etc) to make sure that MFA with Microsoft 365 and Azure AD is a straightforward process for users, and they aren’t prompted multiple times as they use different applications.
As an IT administrator, you should absolutely not be signing in as a Global Administrator (or any other account with standing access to admin privileges) and you should definitely consider licensing Azure AD Privileged Identity Management for IT users at the minimum. And rather than simply using MFA with Azure AD, you also disable App Passwords, if you’ve left legacy authentication enabled by exception. If it’s an old application that needs legacy authentication, or an app password – begin the process to deal with it now. Easier said than done, but nonetheless – it needs to be done.
Even better than simply using multi-factor authentication though, is to move to passwordless authentication.
Passwordless authentication
Remember, it isn’t simply Exchange that will be useful for an attacker, even if you have MFA enabled. It will be other services your users log in to that don’t have MFA enabled for, or services like remote web access or virtual private networks. An attacker will use the credentials with other services that are less securely configured.
Moving to a passwordless model means that the credential won’t be exposed inadvertently due to a legacy auth prompt issued by a rogue Autodiscover service – the user won’t be expecting to input or even have a password to provide. Going one step further, a final mitigation you should have in-place is to restrict the ability for users to grant consent to applications.
This week’s focus might be a worry that an Autodiscover flaw might prompt a user to enter legacy authentication protocols – but, as organizations move to modern authentication, multi-factor and passwordless authentication, the next step for a threat actor is to begin to create applications that request consent to Microsoft 365 or other application data governed by Azure AD application consent.
If you let users consent so they can unwisely use modern authentication on the native Apple mail app on iOS for example – then there’s little from stopping a threat actor who’s designing a scenario that potentially uses techniques like DNS redirection. This will prompt a user to sign-in using their credentials legitimately to Azure AD, and instead of harvesting credentials, requests consent.
Whilst that consent might now allow lateral movement or exploitation of a legacy system – it could have serious consequences and allow for unknown, ongoing access to high-value targets in your organization.
All of that is a lot to take in – but if you’re a regular Practical 365 reader, then these components will be familiar to you, and it’s crucial to see them in the bigger picture and consider how you’d gain access to your organization if you had to.
Think about how a simple set of credentials or a consent can be misused elsewhere, should they be exposed in an Exchange-related flaw, then how you can be proactive and mitigate against this by gradually implementing better controls.
