Reported Zero-day Vulnerabilities in Microsoft Exchange Server on 29 Sept. 2022

Hello!

once again there is a security vulnerability in Exchange. Among other things, this article says the following:

"Authenticated attackers who can access PowerShell Remoting on vulnerable Exchange systems will be able to trigger RCE using CVE-2022-41082. Blocking the ports used for Remote PowerShell can limit these attacks.
HTTP: 5985
HTTPS: 5986"

We have a lot of rules stored in our firewall. Probably the "web rule" is meant here, through which all http or https traffic comes in or is it specifically about the access to the Exchange?

Is there anything else I can set on the Firebox to minimize the risk?

Bernd

Comments

  • By default, TCP port 5985 is not open from the Internet.

    You can add a custom packet filter for TCP port 5985, From: Any-external To: Any, set to denied, to guarantee that this port is closed on external.

    Remote PowerShell uses TCP port 5986
    https://marckean.com/2016/02/08/remote-powershell-ssl-https-5986/

    https://www.speedguide.net/port.php?port=5986

  • Here is the latest from WG on this:

    Two Microsoft Exchange Server Zero-Day Vulnerabilities
    https://www.secplicity.org/2022/09/30/two-microsoft-exchange-server-zero-day-vulnerabilities/

  • edited October 2022

    We setup the Exchange content inspection as described in KB 19376 and working with support we also added URL Paths restriction to only allow access to certain virtual directories and for autodiscover is locked down to autodiscover.mydomain.com/autodiscover/autodiscover.xml. I am pretty sure this would block this attack. Although we have also added the IIS blocking rule as well just to be safe.

  • @Greg said:

    ... we also added URL Paths restriction to only allow access to certain virtual directories and for autodiscover is locked down to autodiscover.mydomain.com/autodiscover/autodiscover.xml. ..

    can you list all required paths

  • edited October 2022

    what about:

    would this reduce attack surface sufficiently ?

  • ..com/autodiscover/autodiscover.xml
    ..com/owa/*
    ..com/ecp/*
    ..com/EWS/Exchange.asmx
    ..com/Microsoft-Server-ActiveSync*
    ..com/OAB/*
    ..com/mapi/emsmdb/*

  • edited October 2022

    what i found regarding Article ID :000019376
    iphones owa/activesync fails without Request Method "options"

  • edited October 2022

    Yes Norm we lock our Autodiscover down just to the xml file. Here is what we originally had:

    ../autodiscover/autodiscover.xml
    /owa
    /owa/*
    /ecp/*
    /ews/*
    /mapi/*
    /microsoft-server-activesync*
    /oab/*

    First we removed /ecp/* as your really don't want remote admin console access externally anyway. But now due to the fact that we don't have MFA enabled yet on Exchange we have removed everything except autodiscover and activesync and using Exchange quarantine to control which devices can access it.

  • @Norman said:
    what i found regarding Article ID :000019376
    iphones owa/activesync fails without Request Method "options"

    We already had Request Method "options" in ours. We did have to add several Content Types to get everything to work. I attached the xml export of what we are using now.

Sign In to comment.