Exchange zero day and WG reverse proxy

edited March 9 in Firebox - Proxies

Would the Watchguard reverse proxy have protected an Exchange server from the new zero day exploit?

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @Greg

    All of the current batch of exploits requires connecting to the server via port 443 to initiate the attach. Based off what was released by Microsoft, if the server can't accept untrusted connections via port 443, then it's safe.

    Access portal (and by extension, reverse proxy) requires the user(s) to authenticate. So long as their authentication means aren't compromised and there was no other way to access the server on port 443, reverse proxy and access portal would in theory protect a server.

    It's important to keep in mind that an overall strict security posture is important in protecting from attacks. For example, a bot'ed computer won't be able to access something protected in a way like access portal. However, a customer's PC at home that VPNs in and is also infected now has unfettered access to the network if the VPN policy is wide open to allow access to anything.

    The best course of action (aside from protecting your server via strict access rules) is to patch the server per Microsoft's guidance.

    You can read more about the exploit here:
    https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/

    -James Carson
    WatchGuard Customer Support

  • Already patched the day it came out and luckily doesn't appear we were compromised. Thinking though I should setup a reverse/access portal to try to prevent anything new like this.

  • You know it would be nice if Watchguard would put out a video about how this protects Exchange and how to configure it. Thanks.

  • these attacks came from specific ip's it is a complete shame that those addresses still have not been added to ips, or botnet or any other of the total security suites many services. What is the point if you cant expect updates in a very very fast manner on something so critical and widespread. this is a huge miss. Fortinet already covers with their IPS

  • Yes the IPS updates are really too slow. It also would have been nice if Microsoft had gotten together with firewall vendors back in January to try to create mitigation for this.

  • For sure on Microsoft, but to not update an ip list for the subscription service is really unacceptable. its the entire point of the service.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    I'm happy to announce that the IPS updates have gone live.

    You'll want to run a manual update to get the latest IPS definitions from your subscription services tab of FSM, or Front Panel -> Subscription Services in the WebUI if you don't have automatic updates turned on.

    The version that has the definitions is:
    18.137 -- Fireboxes running 12.6.x or better.
    4.1132 -- Fireboxes running 12.5.x or lower

    The definitions for the Exchange vulnerabilities are:
    1138767 WEB Microsoft Exchange Server Remote Code Execution Vulnerability -1 (CVE-2021-26855)
    1138774 WEB Microsoft Exchange Server Remote Code Execution Vulnerability -2 (CVE-2021-26855)
    1138775 WEB Microsoft Exchange Server Remote Code Execution Vulnerability -3 (CVE-2021-26855)
    1138776 WEB Microsoft Exchange Server Remote Code Execution Vulnerability -4 (CVE-2021-26855)

    -James Carson
    WatchGuard Customer Support

  • I don't think we have any web shells installed, but would the IPS signature block access to them?

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @Greg
    Assuming that whatever attempts access tries one of those four exploits, yes. Keep in mind that there could be more exploits that are released if/when Microsoft is made aware of them. Ensuring that access is closed via some means (VPN, Access Portal/reverse proxy) or protected with policies with IPS and other security services on them helps make sure that the servers stay protected.

    -James Carson
    WatchGuard Customer Support

  • edited March 10

    @Greg be sure to check the following

    look on disk for the presence of ASPX files at the following paths:

    \inetpub\wwwroot\aspnet_client\ (any .aspx file under this folder or sub folders)

    \exchange install path\FrontEnd\HttpProxy\ecp\auth\ (any file besides TimeoutLogoff.aspx)
    \exchange install path\FrontEnd\HttpProxy\owa\auth\ (any file or modified file that is not part of a standard install)
    \exchange install path\FrontEnd\HttpProxy\owa\auth\Current\
    \exchange install path\FrontEnd\HttpProxy\owa\auth\\

  • Thanks, but I have checked and doubled checked those directories as well as others.

  • off topic
    Glad that I have migrated all Exchange 2007 mailboxes to cloud. It's no longer my problem to maintain unsupported server.

  • @Ron said:
    off topic
    Glad that I have migrated all Exchange 2007 mailboxes to cloud. It's no longer my problem to maintain unsupported server.

    I just wonder why this attack didn't work against Microsoft 365 servers. Or DID it?

    Gregg Hill

  • edited March 16

    Well MS did know about this back in January and could do mitigation for the O365 stuff.

  • Not sure but I believe 365 Exchange servers were also affected at some point.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @Ron You'd need to query Microsoft on that. Based on what they've published it seems Exchange Online (offce365) is fine.

    Their article states:
    "The vulnerabilities affect Exchange Server versions 2013, 2016, and 2019, while Exchange Server 2010 is also being updated for defense-in-depth purposes. Exchange Online is not affected."

    https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/

    -James Carson
    WatchGuard Customer Support

Sign In to comment.