Mit dem September-2021-Update von Exchange hat Microsoft mit dem Cumulative Update 11 für Exchange 2019 und dem Cumulative Update 22 für Exchange 2016 den Exchange Emergency Mitigation Service (EEMS) als neue Sicherheitsfunktion in Exchange eingebaut. EEMS prüft stündlich, ob es ein neues Regelwerk für eine Schwachstelle gibt und wendet diese Regel lokal an, um Lecks nach Möglichkeit schnell abzudichten. Die Informationen werden über den Office Config Service (OCS) mittels einer XML-Datei veröffentlicht, die sich auch direkt über das Internet aufrufen lässt [1].

In der XML-Datei finden sich bezogen auf eine vorhandene Schwachstelle bestimmte Aktionen oder Konfigurationen, die Exchange dann automatisch anwendet, um eine Schwachstelle abzumildern, bis ein entsprechendes Update veröffentlicht wird. Die Aktionen sollen also nur die Ausnutzung einer Lücke und den Angriffsweg verhindern, sie schließen diese Lücke aber nicht. Welche Aktionen Exchange dabei ausführt, klären wir im Laufe des Artikels. Zu beachten ist, dass dabei ganze Services von Exchange deaktiviert werden können, was dann natürlich Auswirkungen auf die Nutzer hat. EEMS nimmt Exchange-Admins nicht das Einspielen von Updates ab – sie müssen Fixes nach Veröffentlichung auch weiterhin händisch einspielen.

Mit der Installation der CUs vom September 2021 oder später haben sich auch die Lizenzbedingungen geändert. So wird nun abgefragt, ob Exchange Diagnosedaten an Microsoft senden darf. Übermittelt werden dabei die Exchange-Server-Version, der Status des Mitigation-Dienstes, die eindeutige Identifikationsnummer des Servers, die Org-ID sowie angewendete und blockierte Mitigations. Zwingende Voraussetzung ist die Übermittlung für die Nutzung von EEMS allerdings nicht, sodass sich die Übertragung mit dem PowerShell-Befehl Set-ExchangeServer -Identity <Server> -DataCollectionEnabled $false nachträglich wieder deaktivieren lässt.

Zur Absicherung von Exchange stehen mit EEMS drei verschiedenen Aktionen zur Verfügung. Über IIS-Rewrite-Regeln lassen sich schädliche HTTPS-Anfragen direkt blockieren. Da viele Exchange-Protokolle über den IIS-Webserver bereitgestellt werden, ist dies ein effektiver Weg, um auf Angriffe zu reagieren und diese abzufangen. Sollte eine URL-Rewrite-Regel nicht ausreichen, lassen sich im IIS weitere virtuelle Verzeichnisse und der AppPool stoppen. Dies hat bereits größere Folgen für Exchange und betroffene Funktionen sind für Nutzer nicht mehr verfügbar. Die härteste Aktion, um die Ausnutzung einer Sicherheitslücke zu unterbinden, ist das Beenden von Exchange-Diensten, was wiederum den größten Einfluss auf die Funktionsfähigkeit von Exchange hat.

Um das neue Sicherheitsfeature zu nutzen, reicht es nicht, nur die Updates von Exchange zu installieren. Es sind zwei Vorrausetzungen nötig, damit EEMS seine Arbeit verrichten kann. Zunächst benötigt der Exchange-Server Zugriff auf den "Office Config Service" über das Internet mit Port 443. Aus diesem Grund müssen Sie die bereits erwähnte URL [1] gegebenenfalls auf der Firewall freigeben. Ein Test ist über den Aufruf der Seite im Browser schnell durchgeführt. Alternativ steht nach dem Update das Skript "Test-MitigationServiceConnectivity.ps1" im Skriptverzeichnis von Exchange unter "C:\Program Files\Microsoft\Exchange Server\V15\scripts\" zur Verfügung.

Als weitere Voraussetzung muss das "IIS URL Rewrite Modul" [2] für den IIS vorhanden sein. Ist dies bei der Installation des Exchange-Updates nicht der Fall, erscheint eine entsprechende Fehlermeldung bei den Voraussetzungen. Ob das Modul installiert ist, erkennen Sie auch über den neuen Eintrag "URL Rewrite" im "Internet Information Service (IIS) Manager".

Sind die Bedingungen erfüllt, lässt sich das Exchange-Update installieren. Der neue EEM-Dienst ist im Anschluss als Windows-Dienst angelegt und wacht zukünftig über aufkommende Lücken. Im Englischen hört der Dienst auf den vollen Namen "Microsoft Exchange Emergency Mitigation Service", während es im Deutschen nur zu dem etwas umständlichen Namen "Microsoft-Notfallrisikominderungsdienst" gereicht hat.

Ist das Exchange-Update erfolgreich installiert, ist EEMS automatisch aktiviert. Sichtbar wird die neue Funktion neben dem neuen Windows-Dienst auch an verschiedenen Stellen in den Exchange-Properties, die Informationen zum Status liefern. In das Exchange Admin Center (EAC) hat es EEMS allerdings nicht geschafft, weshalb Sie zur Konfiguration die PowerShell bemühen müssen.

Bei der Einrichtung unterscheidet Microsoft zwischen der organisationsweiten Konfiguration und der Konfiguration am Server. Organisationsweit lässt sich die Konfiguration mit Get-OrganizationConfig |fl MitigationsEnabled nachvollziehen. Über Set-OrganizationConfig -MitigationsEnabled $false deaktivieren Sie EEMS für die gesamte Organisation zentral. Die Nutzung am Server prüfen Sie über den PowerShell-Befehl Get-ExchangeServer |fl *Mitigations*. Auf einem einzelnen Server schalten Sie den Dienst mit dem Kommando Set-ExchangeServer -Identity <Server> -MitigationsEnabled $false aus. In größeren Umgebungen ist es möglich, die Funktion nur bei den internetseitigen Exchange-Servern zu aktivieren. Dabei müssen Sie darauf achten, dass EEMS in der Organisation weiter aktiv ist.

Welche Workarounds aktuell aktiv sind, zeigt das PowerShell-Skript "Get-Mitigations.ps1" an. Es befindet sich im bereits erwähnten Skriptverzeichnis. Aktuell erscheint hier nur eine Mitigation mit der ID "PING1". Bei dieser handelt es sich um einen Test und es erfolgt keine Aktion oder Konfigurationsanpassung. Ein Blick in die Mitigation-Einstellungen eines Servers zeigt unter dem Eintrag "MitigationsApplied" die auf den Server angewendeten Mitigations an. Die Ausführung einer Mitigation lässt sich an einem Server auch unterbinden, sodass diese nicht mehr automatisch zur Ausführung kommt:

Um eine Mitigation wieder zu aktivieren, müssen Sie den Eintrag aus der Liste der blockierten Mitigations mit Get-ExchangeServer | Set-ExchangeServer -MitigationsBlocked @() wieder entfernen. Zu beachten ist dabei, dass blockierte Mitigations zwar keine Anwendung mehr finden, die entsprechenden Konfigurationsänderungen aber nicht automatisch zurückgenommen werden – Sie müssen diese gegebenenfalls manuell zurücksetzen. Gleiches gilt beim Einspielen eines Fixes oder Updates, das ein Lücke schließt. In diesem Fall kommt zwar die Mitigation nicht mehr zur Anwendung, Konfigurationsanpassungen sind hier aber je nach Mitigation manuell zurückzudrehen. In den Hinweisen zu einem Fix sollte Microsoft das Vorgehen dazu genau beschreiben.

In den Eigenschaften eines Servers lässt sich insgesamt mit folgendem Befehl nachvollziehen, welche Mitigations gerade angewendet oder blockiert werden:

Die durch EEMS herbeigeführten Aktionen können Sie in der Windows-Ereignisanzeige des Servers nachvollziehen. Relevant sind dabei die Event-IDs 1005 und 1006, die erfolgreiche Aktionen einer Mitigation mitloggen. So ist im Eventlog abzulesen, dass die Mitigation "Ping1" stündlich abläuft. Die Event-IDs 1001 und 1002 loggen das Starten und Beenden des Dienstes, während die ID 1008 Dienstefehler wie die fehlende Erreichbarkeit des Office Config Service dokumentiert.

Weiter ist auch ein Textlog im Installationsverzeichnis von Exchange unter "C:\Program Files\Microsoft\Exchange Server\ V15\Logging\MitigationService" verfügbar. Das Protokoll wird täglich fortgeschrieben und enthält detaillierte Informationen über die EEMS-Aktionen. So sind Einzelheiten zu den vom EEMS-Dienst durchgeführten Aufgaben, einschließlich des Abrufs von Mitigation, der Anwendung von Mitigation oder Einzelheiten zu den an den OCS gesendeten Informationen zu finden. Darüber hinaus kann das "Admin Audit Log" eine wichtige Anlaufstelle sein.

Mit dem Exchange Emergency Mitigation Service hat Microsoft eine Möglichkeit geschaffen, schnell auf Sicherheitslücken zu reagieren, ohne dass ein Administrator in Aktion treten muss. Die Konfiguration hat es leider nur in die PowerShell und nicht in die EAC geschafft. Allerdings bleibt zu hoffen, dass die Funktion nicht allzu häufig zur Anwendung kommt.