Exchange Emergency Mitigation (EM) is, as already mentioned in this article erwähnt, ab CU 11 für Exchange 2019 und CU 22 für Exchange 2016 verfügbar. Die Funktionsweise ist so einfach wie effektiv: Die Exchange Server prüfen stündlich, ob es ein neues Regelwerk für die Schadenbegrenzung einer Schwachstelle gibt. Dazu wird stündlich ein signiertes XML Dokument von „Office Config Service (OCS)“-Servern von Microsoft abgerufen. In der XML-Datei finden sich je nach Schwachstelle bestimmte Aktionen oder Konfigurationen, welche von den Exchange Servern automatisch angewendet werden um eine Schwachstelle abzumildern bis entsprechende Updates installiert wurden.
Exchange Emergency Mitigation therefore does not relieve admins of the task of installing Exchange updates, but can protect against the exploitation of a security vulnerability by blocking the attack path. The installation of updates is of course still necessary.
EM can perform three different actions to prevent an attack:
- Applying IIS URL rewrite rules, which many people know from Apache web servers (mod_rewrite). Malicious HTTP requests can be blocked using rewrite rules. As most Exchange protocols are provided via the IIS web server, an appropriate set of rules can be used to respond very effectively to attacks
- Disable vulnerable Exchange services. EM can deactivate vulnerable Exchange services and thus protect against the exploitation of a vulnerability. This can of course affect the availability of certain Exchange functions.
- Deactivating IIS application pools. EM can deactivate certain IIS app pools, similar to the Exchange services. This can also affect the availability of certain functions.
Requirements for Exchange Emergency Mitigation (EM)
In addition to the current CUs for Exchange Server 2016/2019, Exchange Emergency Mitigation requires the IIS URL Rewrite Module, which can be downloaded here:
The URL Rewrite Module can be easily installed via the Web Platform Installer:
Nach der Installation findet sich im IIS Manager der Punkt „URL Rewrite“:
Zusätzlich müssen die Exchange Server den „Office Config Service“ per HTTPS (Port 443) erreichen können. Diese URL muss also ggf. an der Firewall freigegeben werden:
- officeclient.microsoft.com
Access from the Exchange servers can be easily tested via a browser by calling up the following URL:
A corresponding XML should already be displayed here:
Zusätzlich gibt es im Exchange Scripts Verzeichnis (C:\Program Files\Microsoft\Exchange Server\V15\scripts\) das Script „Test-MitigationServiceConnectivity.ps1“:
This script also tests whether the URL specified above can be reached by the Exchange Server.
Settings for Exchange Emergency Mitigation
After installing the corresponding CUs for Exchange, EM is automatically active for all Exchange servers in the organization.
However, EM can be activated or deactivated for all servers or only for certain servers. To disable EM for all Exchange servers in the organization, the following command can be used:
Set-OrganizationConfig -MitigationsEnabled $false
To deactivate EM for specific servers only, the following command can be used:
Set-ExchangeServer -Identity SERVERNAME -MitigationsEnabled $false
In a larger Exchange environment, it may make sense to leave EM activated only for the servers that are also accessible from the Internet.
The following commands can be used to check the status of EM:
Get-OrganizationConfig | fl MitigationsEnabled
Get-ExchangeServer | ft Name,MitigationsEnabled
To enable EM for all Exchange servers in the organization (if it was previously disabled), the following commands can be used:
Set-OrganizationConfig -MitigationsEnabled $true
Set-ExchangeServer -Identity SERVERNAME -MitigationsEnabled $true
Applying or blocking mitigations
Mit dem PowerShell Script „Get-Mitigations.ps1“ kann man sich eine Übersicht der verfügbaren Workarounds für Schwachstellen anzeigen lassen. Das Script befindet sich ebenfalls im Exchange Script Verzeichnis und zeigt aktuell nur eine Mitigation mit der ID „PING1“ an:
This is a test that does not perform any actions or change any configurations. Microsoft plans to publish mitigations when Exchange servers are actively attacked, similar to the HAFNIUM vulnerability was the case. In this case, EM can help to implement workarounds as quickly as possible and thus prevent far-reaching attacks until all Exchange servers have been updated.
The mitigations that are applied by EM can be displayed and (if necessary) blocked. The following command displays the applied and blocked mitigations:
Get-ExchangeServer | fl Name,Mitigations*
The following command can be used to block mitigations so that they are no longer automatically applied by Exchange:
Set-ExchangeServer -Identity <SERVERNAME> -MitigationsBlocked @("PING1")
„PING1“ ist dabei die ID, welche von „Get-Mitigations.ps1“ oder „Get-ExchangeServer | fl Name,Mitigations*“ geliefert wird. Um eine Mitigation wieder zu aktivieren, kann der folgende Befehl verwendet werden:
Get-ExchangeServer | Set-ExchangeServer -MitigationsBlocked @()
You have to be a bit careful when adding mitigations to the Blocked list, only after the next run, the mitigation is removed from the Applied list, as long as the mitigation is visible under MitigationsBlocked and MitigationsApplied:
It is also not a very nice solution that there is no check whether the MitigationID also exists, here you can simply enter values as you wish:
Auch die Ausgabe von „Get-Mitigations.ps1“ ist hier wenig hilfreich, wenn man sich mal verschrieben hat:
The output is only correct again once a new EM run has been performed, but this can take up to 60 minutes. If the service is restarted, it only takes 10 minutes.
Note: If mitigations are blocked, they are no longer applied by Exchange Server (in the hourly search), but the URL rewrite rules are not reset after a mitigation has been blocked, so any existing URL rewrite rule must be removed manually:
The same also applies if the Exchange servers have been updated, the applied mitigations are not automatically revoked. If mitigation is no longer required because the vulnerability has been closed with an update, the corresponding ID is removed from the list of applied mitigations, but any existing URL rewrite rules must be deleted manually.
Logs
Logs werden durch den „MSExchange Mitigation Service“ in das Eventlogs des Servers geschrieben. Die EventID 1005,1006 und 1008 sind für EM relevant:
Another detailed log file is written to the following path:
C:\Program Files\Microsoft\Exchange Server\V15\Logging\MitigationService
This log contains detailed information on which actions were used by EM. The Admin Audit Log can also be helpful if problems occur in connection with mitigations.
Note: EM wird über den Dienst „Microsoft Exchange Emergency Mitigation Service“ bereitgestellt:
Let's hope that the Emergency Mitigation Service doesn't have to intervene too often.