Note: this post is getting frequent updates; please keep checking back. Last update: 3/19/2021
Microsoft has released a set of out of band security updates for vulnerabilities for the following ver...
Updated Mar 19, 2021
Version 44.0
Blog Post
Hi,
Please clarify this statement:
"The initial attack requires the ability to make an untrusted connection to Exchange server port 443"
The media seems interprets this as being able to make an untrusted HTTP (aka not encrypted) connection to an HTTPS port.
Many of us use SSL-offloading/SSL-bridging reverse Proxies (F5 Big-IP, Citrix Netscaler, Kemp, nginx, Apache, HAProxy.....and also some cloud services as Azure Application Proxy or be it also CDNs like Cloudflare etc.) to get Exchange hooked up to the internet and do SSL bridging.
By nature these technologies prevent HTTP connections to HTTPS ports.
Or, do you mean by "untrusted connections" that the user is not authenticated?
If yes:
Many of us also use these technologies to do pre-authentication before anyone can access anything anonymously on port 443 (there was also a question about ADFS some posts before, I might add the question what if we do pre-authentication with Azure AD?).
Are these users protected, or does this issue concern those web API connections to EWS/OAB/ECP/ActiveSync where we have to turn off pre-authentication since this would break those services?
Just asking out of curiosity, I know the vulnerability still exists of anyone can access the server directly from LAN.
Also, because everybody around me is hyping/freaking out, even though many have such technologies in place.
I guess nobody with will hook up an Exchange server to the Internet just by Port-forwarding the port 443 on the firewall directly to the server, or by configuring a public IP address on the server's network interface and connect it directly to the provider switch, at least not in the last 10 years. (Hell, we were doing that since ISA 2000).
Marc