Exchange Emergency Mitigation (EM) ist, wie bereits in diesem Artikel 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 nimmt also den Admins nicht die Installation der Exchange Updates ab, kann aber vor dem Ausnutzen einer Sicherheitslücke schützen, indem der Angriffsweg blockiert wird. Die Installation der Updates ist natürlich weiterhin erforderlich.
EM kann drei verschiedene Aktionen durchführen um einen Angriff zu verhindern:
- Anwenden von IIS URL Rewrite Regeln, dies kennen viele von Apache Webservern (mod_rewrite). Mittels Rewrite-Regeln können schädliche HTTP-Anfragen blockiert werden. Da die meisten Exchange Protokolle über den IIS-Webserver bereitgestellt werden, kann mit einem entsprechenden Regelwerk sehr effektiv auf Angriffe reagiert werden
- Deaktivieren von angreifbaren Exchange Diensten. EM kann angreifbare Exchange Dienste deaktivieren und so vor der Ausnutzung einer Schwachstelle schützen. Dies kann natürlich Einfluss auf die Verfügbarkeit bestimmter Exchange Funktionen haben.
- Deaktivieren von IIS Application Pools. EM kann, ähnlich wie bei den Exchange Diensten, bestimmte IIS App Pools deaktivieren. Auch dies kann einfluss auf die Verfügbarkeit von bestimmten Funktionen haben.
Voraussetzungen für Exchange Emergency Mitigation (EM)
Neben den aktuellen CUs für Exchange Server 2016/2019 benötigt Exchange Emergency Mitigation das IIS URL Rewrite Modul, welches hier runtergeladen werden kann:
Das URL Rewrite Modul kann einfach via Web Plattform Installer installiert werden:
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
Von den Exchange Servern lässt sich der Zugriff einfach via Browser testen, dazu kann die folgende URL aufgerufen werden:
Hier sollte dann bereits ein entsprechendes XML angezeigt werden:
Zusätzlich gibt es im Exchange Scripts Verzeichnis (C:\Program Files\Microsoft\Exchange Server\V15\scripts\) das Script „Test-MitigationServiceConnectivity.ps1“:
Dieses Script testet ebenfalls, ob die oben angegebene URL vom Exchange Server erreicht werden kann.
Einstellungen für Exchange Emergency Mitigation
Nach der Installation der entsprechenden CUs für Exchange ist EM automatisch für alle Exchange Server in der Organisation aktiv.
EM lässt sich allerdings für alle Server oder auch nur für bestimmte Server aktivieren oder deaktivieren. Um EM für alle Exchange Server in der Organisation abzuschalten, kann der folgende Befehl verwendet werden:
Set-OrganizationConfig -MitigationsEnabled $false
Um EM nur für bestimmte Server zu deaktivieren, kann der folgende Befehl verwendet werden:
Set-ExchangeServer -Identity SERVERNAME -MitigationsEnabled $false
In einer größeren Exchange Umgebung kann es sinnvoll sein, EM nur für die Server aktiviert zu lassen, welche auch aus dem Internet erreichbar sind.
Der folgenden Befehle können verwendet werden, um den Status von EM zu prüfen:
Get-OrganizationConfig | fl MitigationsEnabled
Get-ExchangeServer | ft Name,MitigationsEnabled
Um EM für alle Exchange Server in der Organisation zu aktivieren (wenn es vorher deaktiviert wurde), können die folgenden Befehle verwendet werden:
Set-OrganizationConfig -MitigationsEnabled $true
Set-ExchangeServer -Identity SERVERNAME -MitigationsEnabled $true
Anwenden oder Blockieren von 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:
Dabei handelt es sich um einen Test, welcher keine Aktionen durchführt oder Konfigurationen ändert. Microsoft plant Mitigations zu veröffentlichen, wenn Exchange Server aktiv angegriffen werden, ähnlich wie das bei der HAFNIUM Schwachstelle der Fall war. In diesem Fall kann EM helfen, Workarounds möglichst schnell umzusetzen und somit weitreichende Angriffe verhindern, bis alle Exchange Server aktualisiert wurden.
Die Mitigations, welche durch EM angewendet werden, lassen sich anzeigen und (wenn nötig) auch blockieren. Der folgende Befehl zeigt die angewendeten und blockierten Mitigations an:
Get-ExchangeServer | fl Name,Mitigations*
Mit dem folgenden Befehl lassen sich Mitigations blockieren, somit werden diese nicht mehr automatisch von Exchange angewendet:
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 @()
Man muss ein bisschen aufpassen, wenn Mitigations zu Blocked Liste hinzugefügt werden, erst nach dem nächsten Durchlauf, wird die Mitigation aus der Applied Liste entfernt, solange ist die Mitigation unter MitigationsBlocked und MitigationsApplied zu sehen:
Auch ist es nicht ganz so schön gelöst, dass es keine Prüfung gibt, ob die MitigationID auch existiert, hier kann man einfach nach belieben Werte eintragen:
Auch die Ausgabe von „Get-Mitigations.ps1“ ist hier wenig hilfreich, wenn man sich mal verschrieben hat:
Die Ausgabe ist erst wieder korrekt, wenn ein erneuter EM Durchlauf durchgeführt wurde, dies kann aber bis zu 60 Minuten dauern. Wenn der Dienst neu gestartet wird, dauert es nur 10 Minuten.
Hinweis: Wenn Mitigations blockiert werden, werden diese nicht mehr durch Exchange Server angewendet (bei der stündlichen Suche), allerdings werden auch die URL Rewrite Regeln nicht zurückgenommen, nachdem eine Mitigation blockiert wurde, muss also manuell die ggf. vorhandene URL Rewrite Regel entfernt werden:
Gleiches gilt auch, wenn die Exchange Server aktualisiert wurden, die angewendeten Mitigations werden nicht automatisch zurückgenommen. Wenn eine Mitigation also nicht mehr erforderlich ist, weil die Schwachstelle mit einem Update geschlossen wurde, wird zwar die entsprechende ID aus der Liste der angewendeten Mitigations entfernt, evtl. bestehende URL Rewrite Regeln müssen aber manuell gelöscht werden.
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:
Ein weiteres detailliertes Logfile wird in den folgenden Pfad geschrieben:
C:\Program Files\Microsoft\Exchange Server\V15\Logging\MitigationService
In diesem Log finden sich detaillierte Informationen, welche Aktionen von EM angewendet wurden. Auch das Admin Audit Log kann hilfreich sein, wenn es mal zu Problemen in Zusammenhang mit Mitigations kommen sollte.
Hinweis: EM wird über den Dienst „Microsoft Exchange Emergency Mitigation Service“ bereitgestellt:
Bleibt zu hoffen, dass der Emergency Mitigation Service nicht allzu häufig eingreifen muss.