Exchange Emergency Mitigation

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:

URL Rewrite Module

Nach der Installation findet sich im IIS Manager der Punkt „URL Rewrite“:

IIS Manager

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:

Emergency Mitigation XML

Zusätzlich gibt es im Exchange Scripts Verzeichnis (C:\Program Files\Microsoft\Exchange Server\V15\scripts\) das Script „Test-MitigationServiceConnectivity.ps1“:

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
Emergency Mitigation aktiviert

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:

.\Get-Mitigations.ps1

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*
Anzeige 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:

Falsche Mitigation in der Ausgabe

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:

URL Rewrite Regeln

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:

Emergency Mitigation Eventlog

Ein weiteres detailliertes Logfile wird in den folgenden Pfad geschrieben:

C:\Program Files\Microsoft\Exchange Server\V15\Logging\MitigationService
Logfile

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:

Microsoft Exchange Emergency Mitigation Service

Bleibt zu hoffen, dass der Emergency Mitigation Service nicht allzu häufig eingreifen muss.

39 Gedanken zu „Exchange Emergency Mitigation“

  1. Danke für die Ausführliche Beschreibung.

    Nur noch ein Hinweis: im Blogeintrag von MS zu den CUs wird explizit erwähnt, dass man die „x64 MSI Version“ vom „IIS URL Rewrite“ Modul installieren soll.

    VG
    Martin

    Antworten
  2. und ich warte jetzt auf den Tag, wo das bei einem unserer Kunden mal kurz IMAP / POP3 / SMTP oder den IIS runterfährt … Das gibt ein schönes Chaos

    Antworten
    • Hi Macros, treffe einfach mit Deinen Kunden schriftliche Vereinbarungen im Vorfeld. Wenn der Kunde lieber einen Domain Highjack riskiert als die Verfügbarkeit, dann kannst Du das Feature ja in seinem Auftrag abschalten. Grüße

      Antworten
    • Hallo Macros,

      es gibt kein Vorfeld (ala Markus) außer Du spürst Verlangen Dich über Microsoft hinwegzusetzen.
      Teile den Benutzer*innen mit, dass Microsoft mit dem zurückliegenden Update einen Remote-Ausschalter integriert hat und dieser standardmäßig seitens Mircrosoft auf EIN gestellt ist und Auswirkungen bis zum Totalverlust haben kann.

      Es gibt Alternativen!

      LG Vanessa

      Antworten
  3. Habe meine Testserver auf CU22 mit den „URL Rewrite Tool“ aktualisiert aber der Dienst „Microsoft Exchange Emergency Mitigation Service“ ist bei mir auf den Servern 2016 nicht vorhanden.

    Antworten
  4. Wenn ich den Technet-Beitrag richtig verstanden habe, werden die Mitigations automatisch angewendet (HTTP-Requests und ggf. Dienste-Deaktivierung), müssen aber durch den Administrator manuell rückgängig gemacht werden, sobald diese nicht mehr benötigt werden.

    Da kann ich nun also im Vorfeld Blogs verfolgen, welche Schwachstellen es gibt (Hafnium!), und die KBs lesen, was alles bei Updates zu beachten ist oder mir bei Fehlern hinterher die Mühe mit der Fehlersuche zu den Mitigations machen, um die gröbsten Kollateralschäden zu beheben. Worauf habe ich wohl mehr Lust?

    Antworten
  5. Also ich hab jetzt zwei Orgs 2019 mittels Get-OrganizationConfig | fl MitigationsEnabled getestet und bekomme bei beiden False zurück. Das widerspricht etwas der Aussage Microsofts, dass es per Default enabled ist. Kann das mal jemand gegenchecken?

    Danke

    Antworten
  6. Hallo NorbertFe,

    bei meinem Server steht der Wert auf True. Am System wurde nur das EX16 CU 22 eingespielt.
    Bei einem EX 19 nur das CU11 installiert steht der Wert ebenfalls auf „True“.

    Antworten
  7. Ohje – eine Funktion bringt das Ende zu Ende!

    Mir zeigte diese Funktion eindeutig, dass der Gesamtsicherheitszustand in der IT immer kritischer wird.
    Bei ZERO Days sind ggf. die Angreifer alle schneller als die Abwehrmaßnahmen. Das hilft keine Firewall mit ContentFiltering oder lokaler Malware Schutz mit CloudUpdates und Verhaltungserkennung und sonstigen Schnickschnack mit DXL, SASE, XDR usw. usw. schlussendlich kommt der Hacker durch und betreibt Destruktion. Ein „Emergency Mitigation“ ist damit für mich nicht der letzte Sicherheitsschrei, sondern nur das Ende vom Ende. Es möge mir mal keiner erzählen, dass die „Emergency Mitigation“ nicht auch durch Dritte vulnerable wäre. Ich bleibe daher bei meiner Auffassung: Technik kann nicht durch noch mehr Technik noch sicherer gemacht werden. Ja und der große Spasss steht uns eh noch ins Haus, wenn nämlich verstärkt die KI Angriffe ggf. per Quantencomputer auflaufen – ich hoffe da bin ich dann längst in Rente.

    Trotzdem vielen lieben Dank @franky für diesen – wie immer – guten Beitrag.

    Antworten
    • Lieber Oliver, eines sehe ich ganz ähnlich wie Du. Es braucht Menschen, die die technischen Security-Bausteine effektiv bereitstellen. Damit lässt sich Geld verdienen. In wessen Geschäftsmodell oder IT Strategie das nicht passt, der kann mit Exchange Online einen leistungsfähigen und sicheren Dienst buchen, der seinerseits einen Administrator nicht überflüssig macht. Ich bin aber optimistisch, dass die AMSI-Integration von Exchange -sobald sich auch Sophos darauf eingestellt hat- und der EM-Dienst die Sicherheitskette -vor allem gegen zero-days effektiver machen.

      Antworten
  8. Hier gibt es aber schon einen Eintrag, dass der Eintrag wohl öfters auf False steht und Sie gerade den Fehler suchen.
    https://techcommunity.microsoft.com/t5/exchange-team-blog/addressing-your-feedback-on-the-exchange-emergency-mitigation/ba-p/2796190

    „We’re currently investigating this issue, but in the meantime, if you see this happen in your environment and you want automatic mitigation to take place, you can easily update the value to True by running the following command:

    Set-OrganizationConfig -MitigationsEnabled $True“

    Antworten
  9. Hallo zusammen,

    gerade CU22 auf einem 2016er installiert.
    Org und Server stehen nach Installation beide auf true und auch sonst alles so wie es sein soll.

    VG!
    Gero

    Antworten
  10. Habt ihr das ernsthaft aktiv auf euren exchange servern? ein system das aus dem internet einfach mal so services stoppen kann und konfigs verändern kann? und vor allem, wenns das mal gemacht hat und ein update kommt, dass das problem behebt, soll der admin mal schauen, wie er den schnellschuss von microsoft wieder rückgängig macht?

    na ich weiss nicht, was das mit sicherheit zu tun hat. bin mal gespannt, wann die „erste mitigation fernab des hauses microsoft“ dann verteilt wird.

    Antworten
  11. Hallo Frank,

    ist es vielleicht sinnvoll Informationen von „Exchange Emergency Mitigation“ als Modul im Exchange Reporter zu integrieren?
    So hätten die Admins es eher im Blick wenn sich etwas geändert hat.

    Nur eine Idee :-)

    Antworten
      • Hallo Frank,

        das ist sehr schön zu hören und ich schätze deinen Exchange Reporter und die Artikel sehr. Wir müssen nur jetzt auch in der Firma den Einsatz des EM bewerten und das wird keine leichte Sache gerade weil es sehr neu ist und Auswirkungen auf den laufenden Betrieb haben kann.

        MfG Paul

        Antworten
  12. Hallo,
    ich bekomme es mit dem Mitigation Service nicht hin.

    ich bekomme folgende Fehlermeldung :
    021-10-14T14:57:35.405Z,WIN-T-EX01VM,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations from https://officeclient.microsoft.com/getexchangemitigations
    2021-10-14T14:57:35.405Z,WIN-T-EX01VM,FetchMitigation,S:LogLevel=Information;S:Message=No diagnostic data sent. DataCollectionEnabled is false
    2021-10-14T14:57:35.562Z,WIN-T-EX01VM,FetchMitigation,S:LogLevel=Error;’S:Message=Exception encountered while fetching mitigations : This XML is not deemed safe to consume since Response xml“s signing cert is invalid or not from microsoft‘;S:Source=Microsoft.Exchange.Mitigation.Service.Mitigations.MitigationEngine

    1. Es gibt kein Webproxy
    2. Ausgehend sind in der FW Port 80 und 443 erlaubt
    3. Das Root Zertifikat liegt im Cert. Store.
    4. Über den Webbrowser komme ich ohne Fehlermeldung auf die Seite https://officeclient.microsoft.com/getexchangemitigations

    Woran könnte es noch liegen ?

    Vielen Dank

    Antworten
  13. Hallo zusammen,
    bei mir funktioniert die .\Test-MitigationServiceConnectivity.ps1 einwandfrei und auch der direkte Zugriff über den IExplore funktioniert.
    ABER: \Get-Mitigations.ps1 liefert:
    WARNUNG: Die Verbindung mit dem Minderungsendpunkt war nicht erfolgreich. Um die Konnektivität zu aktivieren, sehen
    Sie: https://aka.ms/HelpConnectivityEEMS

    In den Event-Logs finde ich ID 1008-Einträge und entweder

    —> (Interne Ausnahme #0) System.Net.Http.HttpRequestException: Fehler beim Senden der Anforderung. —> System.Net.WebException: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. —> System.Net.Sockets.SocketException: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat 52.109.88.177:443

    oder
    —> (Interne Ausnahme #0) System.Net.Http.HttpRequestException: Fehler beim Senden der Anforderung. —> System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten SSL/TLS-Kanal konnte keine Vertrauensstellung hergestellt werden.. —> System.Security.Authentication.AuthenticationException: Das Remotezertifikat ist laut Validierungsverfahren ungültig.

    Wenn jemand da eine Lösung oder hat jemand ähnliche Probleme?

    Antworten
  14. Hallo, der Dienst läuft bei uns soweit.
    Ich würde gerne die passenden Events monitoren und bei Auftreten eine Mail (über einen anderen Maildienst als den Exchange…) senden.
    Allerdings wird ständig diese Test-Mitigation PING1 entweder mit 1005 (Applylist) oder 1006 (Blocklist) getriggert.
    Kann ich PING1 gefahrlos aus der Applylist löschen, damit ich reale Events wie geplant monitoren kann?

    Oder wie würdet ihr vorgehen?

    Antworten

Schreibe einen Kommentar