Does anyone have any mitigation content for CVE-2022-41040, the new Exchange Zero day that came out overnight?
We have over 100 on prem exchange servers.
We are working on it but was hoping we were not the only ones.
Weāve had some internal discussion around this, but at this point I donāt think weāre expecting to publish content based on the workaround (expecting Microsoft to have an official patch out shortly, likely before we could fully test a workaround).
I am however exploring this āin my spare timeā and Iād be happy to collaborate on it here. Thus far I see a few steps to do, let me know if Iām on the right track -
- Detect Exchange is installed
- Find the IIS configuration
- Find the URL Rewrite extension is installed
- Find the workaround URL Rewrite rule is applied (probably in web.config for the Default Web Site)
ActionScript should
5) Install the URL Rewrite Extension if itās not installed.
6) Add a URL Rewrite rule if itās not present for the Default Web Site.
I donāt expect #1, āDetect Exchangeā to be difficult, but I donāt have an Exchange server handy. Is there a static service name used for Exchange?
I have been working on #2 and #3 for a bit. Iāve reproduced the setup on a non-Exchange IIS server and I think this relevance should work - this is all one relevance statement that Iāve wrapped for readability, so it should work in the āSingle Clauseā tab of the Fixlet Debuger, or in an Analysis, but youād have to remove the newlines to work in the QNA tab or QNA.exe command line
not exists selects "//configuration/system.webServer/rewrite/rules/rule" whose (
node value of attribute "patternSyntax" of it = "Wildcard" and node value of attribute "stopProcessing" of it = "true"
and exists child nodes whose (node name of it = "match" and node value of attribute "url" of it = "*" ) of it
and exists child nodes whose (
node name of it = "conditions"
and exists child nodes whose (
node name of it = "add" of it
and node value of attribute "input" of it = "{REQUEST_URI}"
and node value of attribute "matchType" of it = "Pattern"
and node value of attribute "pattern" of it = ".*autodiscover\.json.*\@.*Powershell.*"
and node value of attribute "ignoreCase" of it = "true"
and node value of attribute "negate" of it = "false"
) of it
) of it
and exists child nodes whose (
node name of it = "action"
and node value of attribute "type" of it = "CustomResponse"
and node value of attribute "statusCode" of it = "403"
) of it
) of xml documents of files "web.config" of native folder (expand environment string of (it as string) of value "PathWWWRoot" of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp" of native registry)This is very much pre-Alpha, but if you have good test machines, youāre confident in your backups, and youād like to try some content at the very edge, hereās a fixlet to apply the Microsoft workaround for CVE-2022-41040 at my GitHub page (Iāll upload it to bigfix.me after we have more success confirmations)
Please let me know your experience if you try it out.
This Fixlet doesnāt actually test whether Exchange is installed, but it does check for IIS installed without the āURL Rewriteā plug-in installed or this workaround rule applied - which means it should be easy to test on any IIS server, with or without Exchange installed.
If the URL Rewrite plug-in is not installed, it will download the MSI package from Microsoft and install it. If the Default Web Site has no web.config file, one will be created with only this rule in it. If there is an existing web.config file, this fixlet will generate & execute a PowerShell script to create the Rewrite rule within the existing web.config file.
It also has an āaction requires rebootā instruction. Strictly-speaking, Iām not sure whether a restart is required, but I expect that at least restarting IIS should be necessary to pick up the new configuration file and plugin.
1 Like
I will run this past my exchange engineers and see what they say. If we test it and it works, I will let you know.
1 Like
Your fixlet worked on our test system.
We added an IIS reset and will test again on another server.
waithidden cmd.exe /c IISReset
1 Like
Added a backup of the web config.
copy "{pathname of native folder (expand environment string of (it as string) of value "PathWWWRoot" of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp" of native registry)}\web.config" "{pathname of native folder (expand environment string of (it as string) of value "PathWWWRoot" of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp" of native registry)}\web.config.old"
2 Likes
Iām seeing some indications of the cyber community judging that Microsoftās guidance may be too narrow and there may be some ways around this mitigation because the regular expression they block is too specific. https://www.bleepingcomputer.com/news/security/microsoft-exchange-server-zero-day-mitigation-can-be-bypassed/
Microsoft hasnāt responded or updated their guidance yet. Iām not planning to update the fixlet (yet), but you can judge your risk factor and consider whether you want to change to a more general regular expression to block (itās just an update in the Relevance and ActionScript). My concerns are that I canāt really anticipate whether a broader regular expression would be more likely to break functionality, and whether weāll see an even broader regular expression tomorrow.
If MS updates their guidance, Iāll update the fixlet on GitHub; Iām still hoping for a real patch for the issue, rather than this workaround, to be released soon enough that we donāt have to change the workarounds.
I see that Microsoft has updated their guidance on the workaround and is now recommending a broader regular expression (and also accounts for handling URL-encoded strings that bypassed the first mitigation). I plan to update the fixlet on GitHub shortly.
Iāve posted an update to the test fixlet at the same URL on github.
@D.Dean Thank you, Iāve added your valuable feedback on backing up the existing web.config and issuing an IISReset. This updated fixlet will issue an IISReset by default (which can be disabled by changing a parameter in the actionscript).
This updated version will add the new Microsoft guidance dated 2022-10-06 (their third version) and remove the earlier version of the mitigation (assuming the earlier mitigation was applied by BigFix, as Iām assuming the rule name that I used earlier)
I wanted to update everyone on what we decided to doā¦
MS changed the mitigation several times this week and this created a mess.
First, we have implemented all other IOCs for this issue. The machine level changes were just a failsafe for us.
Every change MS made required me to update my analysis to determine if the system was mitigated. I had a hard time keeping up but I noticed that some systems were showing as mitigated already, even though we did not make those changes. I learned that those servers had the EEMS service installed and running.
We require change controls for changes that we make such as this, and if MS changes the language in the mitigation another change would be required. So we shifted focus from implementing changes to the config file with BigFix to enabling the EEMS service and if a system does not support that, we will mitigated via the config file as we planned.
This is version 5 of our mitigation detectionā¦
if (exists selects "//configuration/system.webServer/rewrite/rules/rule" whose ( node value of attribute "stopProcessing" of it = "true" and exists child nodes whose (node name of it = "match" and node value of attribute "url" of it = ".*" ) of it and exists child nodes whose ( node name of it = "conditions" and exists child nodes whose ( node value of attribute "input" of it = "{UrlDecode:{REQUEST_URI}}" and node value of attribute "pattern" of it = ".*autodiscover\.json.*Powershell.*" ) of it ) of it and exists child nodes whose ( node name of it = "action" and node value of attribute "type" of it = "AbortRequest" ) of it ) of xml documents of files "web.config" of native folder (expand environment string of (it as string) of value "PathWWWRoot" of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp" of native registry)) Then "Mitigated" else "Not Mitigated"
Is the URL Rewrite installed?
exists keys whose (value "DisplayName" of it as string starts with "IIS URL Rewrite Module 2") of keys "HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall" of native registry
Is the EMSS service installed and what is itās stateā¦
IF (exists service whose (service name of it as string as lowercase = "msexchangemitigation")) THEN (state of it & " - " & version of it as string) of service whose (service name of it as string as lowercase = "msexchangemitigation") ELSE "Not Installed"
This is information from MS about the EMSS serviceā¦
2 Likes