EEMS - Exchange Emergency Mitigation Service

Mit den Exchange Updates im Sep 2021 hat Microsoft einen weiteren Dienst zum Schutz von OnPremises-Servern umgesetzt, den ich hier beschreibe. Microsoft hat am 24. Sep 2021 berichtet:

Noch ein Tool?

Warum noch ein Dienst, noch eine Software, noch mehr URLs, werden Sie sich vielleicht fragen. Die großen Sicherheitsprobleme von Microsoft Exchange im Jahr 2021 haben bei Microsoft zu der Erkenntnis geführt, dass selbst nach Hafnium Exploit es immer noch zu viele Exchange Server gibt, die nicht so betreut werden, wie es sein müsste. Ich vergleiche das gerne mit dem Autofahrer, der regelmäßige Inspektionen und Reifenwechsel auslässt und sich dann beschwert, wenn er liegen bleibt oder im Straßengraben landet. Aber selbst aktuelle Server sind nicht davor geschützt, eine unerkannte Lücke zu haben, für die es am Anfang noch nicht mal einen Patch gibt.

In dem Umfeld gibt es mit EEMS nun eine weitere Komponente zum sicheren Betrieb eines Exchange Server. Diese sind:

  • Aktuelles Betriebssystem und Software
    Natürlich müssen Sie auch zukünftig ihren Server möglichst zeitnah mit verfügbaren Updates und Patches versehen. Ich würde hier nicht länger als 1 Woche warten oder sogar schneller aktualisieren.
  • Virenscanner
    Wenn eine Malware den Weg auf den Server findet, dann kann ein lokaler Virenscanner entweder eine bekannte Malware schon erkennen oder das nächste Pattern-File kann eine aktive Malware hoffentlich schnell genug blocken. Das gelingt sogar sehr oft.
  • Sichere Konfiguration
    Natürlich sollten Sie alle Register des Betriebssystems ziehen, z.B. getrennte Admin-Konten, Arbeiten mit wenig Rechten, Beschränkung auf notwendige Software, Applocker und SmartScreen, PowerShell ExecutionPolicy etc. um das System zu härten.
  • EEMS
    Mit EEMS kommt nun ein weiterer Dienst dazu, der sehr oft von Microsoft eine Liste von "Konfigurationsanpassungen" abfragt und diese sehr schnell umsetzt.

EEMS ist also ein weiterer Baustein in der Kette zur Verteidigung eines Exchange Servers gegen externe und interne Angriffe. Wenn Microsoft über eine neue Lücke oder einen Angriff informiert wird, und die Auswirkungen durch schnelle Konfigurationsanpassungen verhindert werden können, dann sollte das schnell passieren. Womit wir wieder bei den Exchange Servern sind, die von ihren Besitzern eher lieblos behandelt werden. Hier hilft dann EEMS, indem es eigenständig ohne Neustart entsprechende Anpassungen umsetzt.

Exchange Telemetrie

Mit dem Updates und EEMS spendiert Microsoft den OnPremises Exchange Servern eine weitere Funktion, die sogar richtig deutlich sichtbar bei den Kommandozeilenparametern für die "Unattended Installation" wird:

Parameter Bedeutung
/IAcceptExchangeServerLicenseTerms 

Damit konnte ein Administrator beim Aufruf die Antwort bei der sonst erscheinenden Rückfrage nach den Lizenzbedingungen vorgeben. Dieser Parameter entfällt und muss durch einen der beiden folgenden Parametern ersetzt werden

/IAcceptExchangeServerLicenseTerms_DiagnosticDataOn 

Der Lizenz wird zugestimmt und die Übermittlung von Diagnosedaten erlaubt

/IAcceptExchangeServerLicenseTerms_DiagnosticDataOff

Der Lizenz wird zugestimmt und die Übermittlung von Diagnosedaten verboten

Damit stellt sich natürlich die Frage, welche Daten Microsoft damit einsammelt. Laut Microsoft sind das:

  • Exchange Version (Buildnummer)
  • Status des Exchange Mitigation Service
  • Eindeutige DeviceID des Servers und OrgID der Installation
  • Angewendete Updates durch EEMS
  • Blockierte Updates durch EEMS

Ich finde es eher erstaunlich, dass diese Daten nicht schon früher im Rahmen einer allgemeinen Telemetrie gesammelt wurden und nun erst explizit erfasst werden. Microsoft hatte bis zum Sep 2021 Update quasi keinen Überblick über die bei Kunde installierten Exchange Versionen. Dann fehlt eigentlich nur noch die Angabe einer "Kontaktperson", die bei Probleme automatisiert angesprochen werden kann.

Wobei spätestens seit dem Hafnium Exploit klar sein muss, das ein eigener Exchange Server aktiv betreut werden muss (Selbst oder per Dienstleister) oder Sie besser einen Hosted Service wie Exchange Online nutzen. In beiden Fällen wird auch ein Monitoring und Telemetrie genutzt.

Funktionsweise

Der Dienst fragt jede Stunde beim "Office Configuration Service" nach entsprechenden Lücken nach. Die URL ist nicht geheim und kann auch einfach per PowerShell abgefragt werden, z.B.

PS C:\> (Invoke-RestMethod https://officeclient.microsoft.com/getexchangemitigations).EOCS.config

id            : M0
desc          : Mitigation M0
EndVersions   : EndVersions
BeginVersions : BeginVersions
Roles         : Roles
ActionList    : ActionList

id         : PING0
desc       : EEMS Heartbeat probe. Does not modify any exchange settings.
ActionList : ActionList

Die URL können Sie auch im Browser öffnen. Hier nur ein Auszug.

Diese XML-Datei ist noch ein Muster, welche keine erforderlich Aktivitäten enthält. Wenn der lokal installierte EEMS-Service jede Stunde die Konfiguration bekommen, dann kann er folgende Aktionen ausführen:

  • IISRewrite-Rules addieren
    diese Modul im IIS erlaubt es umfangreiche "Umschreibungen" für HTTP-Request anzuwenden. Das ist die erste Verteidigungslinie, mit der ein Web-Administrator die dahinterliegenden Webapplications schützen kann. Es ist eine kleine eingebaute Firewall, mit der Anfragen analysiert, bewertet und ggfls. auch abgelehnt werden können.
  • Exchange IIS-AppPool stoppen
    Der IIS kennt das Modell der AppPools, um bestimmte Funktionen dauerhaft zu instanzieren, so dass die Umgebung nicht bei jedem Request neu initialisiert werden muss. Sollte daher ein Code-Teil eine Lücke aufweisen, die EEMS nicht über eine URL-Rewrite-Regel beheben kann, dann kann EEMS den AppPool stoppen. Damit ist dann natürlich auch die damit verbundene Funktion bestört-
  • Exchange Dienste beenden
    Das ist dann wohl die härteste Methode, dass ein Dienst komplett beendet wird, um die Ausnutzung einer Lücke zu unterbinden. Angeblich betrifft dies aber nur Exchange Dienste. Die Lücken im Windows Spooler Dienst, die auch in 2021 zu Problemen geführt hat, würde EEMS wohl nicht korrigieren.

Er wendet diese "Korrekturen" aber auch jede Stunde wieder an. Die Änderungen durch den EEMS passieren ohne Reboot. Es kann aber schon sein, dass bestimmte Korrekturen von Anwendern natürlich bemerkt werden. Ein gestoppter AppPool wird sicher die damit verbundene Funktion unterbrechen.

Einrichtung

Die Installation des EEMS ist Teil der Exchange Installationsroutine im September 2021 Update oder neuer. Allerdings sind zwei Voraussetzungen erforderlich, die das Setup selbst aktuell nicht sicherstellt aber drauf hinweist:

Hier muss der Administrator vor dem Setup noch nachbessern.

Konfiguration

Die erfolgreiche Installation finden Sie natürlich auch an mehreren Stellen:

  • Windows Service "MSExchangeMitigation"
  • PowerShell Get-ExchangeServer
    Auch in der Exchange PowerShell können Sie sehen, ob und wie der Dienst aktiv ist. Dazu gibt es bei "Get-ExchangeServer" neue Properties:
  • Ein/Ausschalten per PowerShell
    Sie können die Anwendung der Mitigations global oder pro Server steuern.

    Diese Änderungen werden natürlich wie jeder andere PowerShell-Befehl im AdminAuditLog des Exchange Server protokolliert.

Hinweise für den Betrieb

EEMS wird durch den Administrator über die normale Installationsroutine auf den Server gebracht. Für den Einsatz gibt es aber einige Randbedingungen, die sie beachten sollten:

  • Exchange muss "surfen" können
    d.h. Proxy-Server und Authentication müssen berücksichtigt werden, damit EEMS auch die aktuellen Hinweise erhalten kann. Ich kann mir aber vorstellen, dass Sie in einer "High Secure"-Umgebung vielleicht die Information auch extern abholen und intern unter einer eigenen URL bereitstellen können.
  • Microsoft kann tracken
    Genau genommen sieht Microsoft natürlich den HTTP-Request ihres Servers und je nach Informationsumfang kann man zumindest die Source-IP auf einen Kunden zuordnen.
  • Erst nach Update
    Die Funktion erhalten natürlich nur die Server, die auch das Update vom Sep 2021 erhalten haben. Die tausende Exchange Server, die auch 6 Monate nach Hafnium Exploit immer noch nicht gepatched sind, werden auch die neue EEMS-Funktion nicht bereitstellen.
  • Öffentliche URL für Monitoring
    Was sollte sie daran hindern, diese URL über ihr Monitoring regelmäßig zu prüfen, um über den Weg aktiv eine Information zu erhalten. Wenn Microsoft über EEMS eine Konfigurationsänderung veröffentlich, dann möchte ich das als "Exchange Verantwortlicher" gerne umgehend erfahren.

Get-Mitigations und andere

Microsoft legt im "Exchange Scripts"-Verzeichnis auch eine "Get-Mitigations.ps1" ab, welches die angewendeten Fixes anzeigt:

[PS] C:\>'C:\Program Files\Microsoft\Exchange Server\V15\scripts\Get-Mitigations.ps1'

Server      : NAWEX16
Version     : Version 15.1 (Build 2375.7)
ID          : PING1
Type        : Ping
Description : EEMS Heartbeat probe. Does not modify any exchange settings.
Status      : Applied

Monitoring

Der Schutz ist natürlich nur gegeben, wenn der Dienst läuft, Updates von Microsoft erhalten und diese auch anwenden kann. Daher ist eine generelle Überwachung wichtig. Hier gibt es mehrere Ansatzpunkte:

Check Beschreibung

URLREwrite

Der Exchange Emergency Mitigation Services erfordert die Installation des URLRewrite-Tools. Die Existenz kann über die Registrierung geprüft werden

PS C:\> Get-Item "HKLM:\SOFTWARE\Microsoft\IIS Extensions\URL Rewrite"

    Hive: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS Extensions

Name                           Property
----                           --------
URL Rewrite                    Install : 1
                               Version : 7.2.1993

Entsprechend können Sie dies prüfen

if ((Get-Item "HKLM:\SOFTWARE\Microsoft\IIS Extensions\URL Rewrite\").getvalue("Install") -eq 1){
   "OK IIS URLRewriteInstalled"
}
Else {
   "FAIL IIS URLRewrite Not Installed"
}

Dienst gestartet?

EEMS ist als eigener Windows Dienst umgesetzt. Daher kann die Existenz und der Zustand geprüft werden

Das kann auch einfach per PowerShell geprüft werden. Weitere Check auf CPU-Last oder RAM-Bedarf sind ebenfalls möglich.

(Get-Service  MSExchangeMitigation -ErrorAction SilentlyContinue).status -ne "running"

if (Get-Process "Microsoft.Exchange.Mitigation.Service") {
   "Running"
}
else {
  "EEMS not running"
}

Perfmon

Ich habe keine Windows Performance Counter für EEMS gefunden, die man schnell überwachen könnte. Das ist eigentlich ungewöhnlich

Eventlog

Wenn Sie als Administrator oder eine Überwachungslösung einen per EEMS gestoppten Dienst oder App-Pool wieder startet oder als Alarm meldet und die von Hand oder automatisch eingreifen, dann wiederholt sich das Spiel immer wieder.

Als Administrator sollten Sie also auf jeden Fall ein Monitoring umsetzen, der z.B. aus dem Eventlog die Aktivitäten des EEMS ermittelt. Ein "Custom View" auf "MSExchange Mitigation Service" kann hier helfen. Achtung: Es gibt einen zweiten Eintrag "MSExchangeMitigation"

Der "MSExchange Mitigation Service" protokolliert z.B. den Start und Stop des Diensts:

Ich bin gespannt, ob angewendete Mitigations mit einer anderen Eventlog-Quelle protokolliert werden.

(Get-EventLog -LogName Application -Source "MSExchange Mitigation Service")

Eine Monitoring-Lösung könnte z.B. die Anzahl der Events in den letzten 5 oder 60 Minuten zählen und insbesondere bei "Errors" darauf hinweisen. Besser wäre hier aber ein Eventlog-Sammeldienst

WebService

Wenn ihre Monitoring-Lösung auch als "Local System" läuft und auch den gleichen Internet-Ausgang/Proxy nutzt, dann könnten Sie auch die gleiche HTTP-Anfrage stellen, mit der der Mitigation Service die Informationen abholt. Der Folgende Aufruf sollte nicht nur eine vertrauenswürdige HTTPS-Verbindung aufbauen sondern auch einen "200 OK" liefern.

(Invoke-RestMethod https://officeclient.microsoft.com/getexchangemitigations).EOCS.config.count

Eine Veränderung des Count ist natürlich schon zumindest ein Warnsignal.

Exchange PowerShell

Wenn die Monitoringlösung sowieso eine Exchange PowerShell gestartet hat, kann Sie acuh den Status mit Get-ExchangeServer abfragen:

(Get-ExchangeServer).MitigationsEnabled
True

(Get-ExchangeServer).MitigationsApplied.count
1

Aktiver Test

Die Krönung wäre natürlich ein Testsystem, welches sich die Mitigations lädt, daraus entsprechend "böse" URLs formuliert und gegen den Exchange Server prüft. Allerdings sehe ich noch nicht, ob der Test dann das Ergebnis unterscheiden kann.

Die Zeit wird zeigen, wie wir weitere Überwachungen aktivieren können, um die Anwendung der Mitigations zu erkennen. Wenn man all das dann zusammenfasst, bekommt man ein kleines PS1-Script, welches die Werte einfach liefert.

Test-EEMS

Das Skript prüft die oben genannten Einstellungen und gibt sie einfach als Ausgabe zur Weiterverarbeitung aus.

Info für Hacker

Eine öffentlich anonym erreichbare URL, die automatisiert "Korrekturhinweise" für Sicherheitslücken bereitstellt, interessiert natürlich auch die "bösen Jungs/Mädels". Denn wann veröffentlicht ein Hersteller über eine URL eine JSON-Datei mit Anweisungen zum "Patchen". Selbst wenn der Inhalt nicht nur signiert sondern verschlüsselt wäre, könnte ich einen eigenen Exchange Server mit installiertem EEMS betreiben, und bei Änderungen umgehend schauen, was Microsoft hier wie korrigiert oder verhindert.

Das Risiko ist natürlich geringer, wenn irgendwann alle OnPremises Exchange Server ebenfalls mit EEMS ausgestattet sind und nicht nur aus dem Internet erreichbar sind, sondern auch zumindest die OCS-URL erreichen können. Dann dürfte die 60 Minuten als Zeitfenster schon sehr kurz sein, eine Lücke zu analysieren und einen Angriff zu fahren.

Vielleicht gibt es irgendwann die ersten Firewall-, Loadbalancer- und Webproxy-Hersteller, die ebenfalls diese Information einbinden.

Signatur/Sicherheit

Wenn Exchange im Internet eine "Handlungsanweisung" zur Anpassung von Konfigurationen abruft, dann muss ich natürlich sicherstellen, dass kein Angreifer diese Daten verfällt und damit meinen Exchange Betrieb stört oder sogar eigene "Regeln" addiert, die dann eine Hintertür öffnen. Microsoft sichert den Service über mehrere Funktionen ab:

  • HTTPS-Übertragung
    Der Zugriff auf den Office Configuration Service erfolgt per HTTPS. Damit ist ab "Abhören" der Verbindung erschwert aber nicht wirklich kritisch, da die Informationen eh anonym erreichbar sind
  • HTTPS-Zertifikatspinning
    Aktuell habe ich noch nicht geprüft, ob der EEMS-Service das ausgelieferte Zertifikat prüft.
  • Signiertes XML
    Neben dem Transport wird aber auch die Information selbst digital signiert. Das Zertifikat samt Chain können Sie aus der XML-Datei einfach extrahieren und ist auf die "Microsoft Exchange XML Signing" ausgestellt

    Auch hier muss ich aber noch prüfen, wie streng der EEMS-Dienst die Prüfung nimmt.

Entsprechende Prüfungen der "Sicherheit" stehen noch aus

Andere OnPremises Server?

Schön, dass das Exchange Team mal wieder seine Hausaufgaben macht und die OnPremises Plattform weiter entwickelt. Aber neben Exchange gibt es ja auch noch SharePoint, Skype for Business und andere "OnPremises"-Services auf Basis on Microsoft. Die "Printer Nightmare"-Problematik im Sommer 2021 hat gut aufgezeigt, dass selbst grundlegende Dienst wie der "Spooler" nicht fehlerfrei sind und als schnelle Lösung z.B. die Deaktivierung des Spooler-Diensts genannt wurde oder auch nur ein paar Registrierungsschlüssel den Schutz verbessert haben.

Da kommt natürlich der Gedanke auf, dass EEMS in ähnlicher Form auch in anderen Produkten umgesetzt wird oder es vielleicht sogar zu einem "Microsoft Update Realtime"-Dienst kommen könnte. Exchange war ja schon Vorreiter bei der Nutzung der PowerShell oder RBAC - Role Based Access Control und es würde mich nicht überraschen, wenn abhängig von den Erfahrungen mit EEMS die Funktion nicht auch bei anderen Diensten adaptiert wird. Wir leben nun mal in einer schnelllebigen Welt.

Ich weiß nicht, ob Microsoft auch in Exchange Online mit EEMS arbeitet. Ich vermute aber, dass hier Updates und Konfigurationsänderungen aktiv "durchgedrückt" werden und man sich hier nicht drauf verlässt, dass ein lokaler Dienst vielleicht Änderungen liest und umsetzt.

Weitere Links