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
0
Sign In to comment.
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/
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.
... 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
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/*
what i found regarding Article ID :000019376
iphones owa/activesync fails without Request Method "options"
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.
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.