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:

1
Set-OrganizationConfig -MitigationsEnabled $false

Um EM nur für bestimmte Server zu deaktivieren, kann der folgende Befehl verwendet werden:

1
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:

1
2
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:

1
2
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:

1
Get-ExchangeServer | fl Name,Mitigations*
Anzeige Mitigations

Mit dem folgenden Befehl lassen sich Mitigations blockieren, somit werden diese nicht mehr automatisch von Exchange angewendet:

1
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:

1
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.

48 Gedanken zu „Exchange Emergency Mitigation“

  1. Hallo zusammen,

    das PING1 XML-Mitigation-Script wirft seit 09.06.2022 jede Stunde Fehler:
    Jun 13 11:27:48 49152.1008 MSExchange_Mitigation_Service An unexpected exception occurred. Diagnostic information: Exception encountered while fetching mitigations : System.Exception: This XML is not deemed safe to consume since Response xml’s signing cert is invalid or not from microsoft bei Microsoft.Exchange.Mitigation.Service.Common.SignatureVerifierUtils.ThrowIfIntegrityChecksFail(SafeXmlDocument xmlDoc) bei Microsoft.Exchange.Mitigation.Service.Common.SignatureVerifierUtils.GetValidatedDocumentWithoutSignature(SafeXmlDocument xmlDoc) bei Microsoft.Exchange.Mitigation.Service.Common.Utils.FetchDataFromXmlStream[T](Stream stream) bei Microsoft.Exchange.Mitigation.Service.Common.Utils.FetchMitigationsFromUrl[T](String url, RemoteCertificateValidationCallback certValidationCallback, X509Certificate clientAuthCert, Boolean isResponseJson) bei Microsoft.Exchange.Mitigation.Service.MitigationCloudServiceV2.FetchMitigations() bei Microsoft.Exchange.Mitigation.Service.Mitigations.MitigationEngine.FetchAndApplyMitigation()

    Hintergrund ist der, dass die Signatur des PING1-Skripts (https://officeclient.microsoft.com/getexchangemitigations) abgelaufen ist.

    Siehe https://tools.keycdn.com/ssl
    Kopiert dort die Signatur aus dem XML-Dokument rein (im Tag SignatureValue):
    —–BEGIN CERTIFICATE—–
    MIIGCTCCA/GgAwIBAgITMwAAAjqaxD9adf61fAAAAAACOjANBgkqhkiG9w0BAQsFADB+MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3RvbjEQMA4GA1UEBxMHUmVkbW9uZDEeMBwGA1UEChMVTWljcm9zb2Z0IENvcnBvcmF0aW9uMSgwJgYDVQQDEx9NaWNyb3NvZnQgQ29kZSBTaWduaW5nIFBDQSAyMDExMB4XDTIxMDYxMDE4NDQxMloXDTIyMDYwOTE4NDQxMlowfTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEnMCUGA1UEAxMeTWljcm9zb2Z0IEV4Y2hhbmdlIFhNTCBTaWduaW5nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9dM4E6w69Lwq1Rejh0vwyo+v4jnnni9zmRCyv9xxwhCSlCf8UcZtl8e8o5qO7OTlXqkw7JjMxZVC11rym4p1tfvOhBRCJ0gnaMP5728qm5E2g13YZmoMh0V4JxsQnQI3PV28l4MUiMTNCeX/Nvkj+ojnOV8ypbCEZrW9W73oS0LaApigN1LEBVAimt/4kg5lqeUux+Rvdn+M/FlE2C6AFKuPeb8f0YrRgUS5xIcb6LmIBbfNlnlAYcJM6qy+ercj+gYyFjWRdUQZM1tw4eTyXQhX7rtpk+vtPOcCV5pUhQe/6rSUcMFIFDfAu17OZK+oKzKhe+ZNjgo6F+evr8SnvQIDAQABo4IBfzCCAXswIAYDVR0lBBkwFwYIKwYBBQUHAwMGCysGAQQBgjdMOQELMB0GA1UdDgQWBBRrQYqQ4HWN1StB2eYy7NP0NkAxBDBQBgNVHREESTBHpEUwQzEpMCcGA1UECxMgTWljcm9zb2Z0IE9wZXJhdGlvbnMgUHVlcnRvIFJpY28xFjAUBgNVBAUTDTQ2NDg2OCs0NjQ4NzkwHwYDVR0jBBgwFoAUSG5k5VAF04KqFzc3IrVtqMp1ApUwVAYDVR0fBE0wSzBJoEegRYZDaHR0cDovL3d3dy5taWNyb3NvZnQuY29tL3BraW9wcy9jcmwvTWljQ29kU2lnUENBMjAxMV8yMDExLTA3LTA4LmNybDBhBggrBgEFBQcBAQRVMFMwUQYIKwYBBQUHMAKGRWh0dHA6Ly93d3cubWljcm9zb2Z0LmNvbS9wa2lvcHMvY2VydHMvTWljQ29kU2lnUENBMjAxMV8yMDExLTA3LTA4LmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBCwUAA4ICAQARts69VpMn56WbNtOtux5sm62G8+GDsrWYwlOw6VL+k5gJ3pG/XjTniC2yz8STpzyA/KO3RQ+nbXMQFP5do3VnxIprdzFB1LBVIpmCeNKIBeB2BxCbuFEqDVqa/Np6KaXYNLHB56pcpZaU2ZlzZ9HMrD5szWyKPeUxjB7S8uNUWMBA2bJp90s7W7WiaiEt+M2MogPpRa1tzTu5og3mWW+rTD/r9IhC14ynBOEvvBPaL0Iev0uWfqeS0cxxCFIGw9bWPkRyNX08LF5oEEq+PfU9jSTvjhfMU7alGD1D1EGsUqJ5p5ZZZtiWzJBjVY4ovuPocn8LNeDkMS893XBiRBpG8yOyUQB2rD1xLI4vHzFoK967qOz7fCEjFcgiTqocu59GrcnoDg8tLRezt6MuOwerMssBUx0WZvlI4pb8kas3sX2c1RuenIRrK4B0kKUY69Gg6SZqHySxQRe/pMuHe+5z3dLppa+gjzz0l5FJGOZ/mnCyTQtWFhmVegqhEas5Oa1mdwooPLR6n97WAxQgRXAeKfRT4W/4FopL8/Qv9SCkjcdC+KTm2UHMWJn5n984l0gldDSiaUYRbJoVsLN/FtMHbI+IMKww+33nALK2vhjKmKOMI4QN80n5B/8jjoyFTTwNlomVALy0U3cJTYnrHMXIugbwTNxt1v3tAnnmi8PS0g==
    —–END CERTIFICATE—–

    Die dekodierten Signatur-Daten sind dann:

    The certificate has expired (2022-06-09T18:44:12+00:00 ISO 8601).
    1. Subject CN: Microsoft Exchange XML Signing > Issuer CN: Microsoft Code Signing PCA 2011

    Decoded Certificate

    {
    „name“: „\/C=US\/ST=Washington\/L=Redmond\/O=Microsoft Corporation\/CN=Microsoft Exchange XML Signing“,
    „subject“: {
    „C“: „US“,
    „ST“: „Washington“,
    „L“: „Redmond“,
    „O“: „Microsoft Corporation“,
    „CN“: „Microsoft Exchange XML Signing“
    },
    „hash“: „23a28e10“,
    „issuer“: {
    „C“: „US“,
    „ST“: „Washington“,
    „L“: „Redmond“,
    „O“: „Microsoft Corporation“,
    „CN“: „Microsoft Code Signing PCA 2011“
    },
    „version“: 2,
    „serialNumber“: „0x330000023A9AC43F5A75FEB57C00000000023A“,
    „serialNumberHex“: „330000023A9AC43F5A75FEB57C00000000023A“,
    „validFrom“: „210610184412Z“,
    „validTo“: „220609184412Z“,
    „validFrom_time_t“: 1623350652,
    „validTo_time_t“: 1654800252,
    „signatureTypeSN“: „RSA-SHA256“,
    „signatureTypeLN“: „sha256WithRSAEncryption“,
    „signatureTypeNID“: 668,
    „purposes“: {
    „1“: [
    false,
    false,
    „sslclient“
    ],
    „2“: [
    false,
    false,
    „sslserver“
    ],
    „3“: [
    false,
    false,
    „nssslserver“
    ],
    „4“: [
    false,
    false,
    „smimesign“
    ],
    „5“: [
    false,
    false,
    „smimeencrypt“
    ],
    „6“: [
    true,
    false,
    „crlsign“
    ],
    „7“: [
    true,
    true,
    „any“
    ],
    „8“: [
    true,
    false,
    „ocsphelper“
    ],
    „9“: [
    false,
    false,
    „timestampsign“
    ]
    },
    „extensions“: {
    „extendedKeyUsage“: „Code Signing, 1.3.6.1.4.1.311.76.57.1.11“,
    „subjectKeyIdentifier“: „6B:41:8A:90:E0:75:8D:D5:2B:41:D9:E6:32:EC:D3:F4:36:40:31:04“,
    „subjectAltName“: „DirName:OU = Microsoft Operations Puerto Rico, serialNumber = \“464868+464879\““,
    „authorityKeyIdentifier“: „keyid:48:6E:64:E5:50:05:D3:82:AA:17:37:37:22:B5:6D:A8:CA:75:02:95\n“,
    „crlDistributionPoints“: „\nFull Name:\n URI:http:\/\/www.microsoft.com\/pkiops\/crl\/MicCodSigPCA2011_2011-07-08.crl\n“,
    „authorityInfoAccess“: „CA Issuers – URI:http:\/\/www.microsoft.com\/pkiops\/certs\/MicCodSigPCA2011_2011-07-08.crt\n“,
    „basicConstraints“: „CA:FALSE“
    }
    }

    Fazit:
    Das ist der Grund warum das supertolle sicherheitserhöhende und von Microsoft ungepflegte Tool (weil ausgelaufene Signatur) das Eventlog stündlich vollschreibt.

    Leider kann ich bei MS keinen Call aufmachen… Evtl. unterstützt Ihr mich ?! *ächz*

    Ein leidgeplagter Monitoring-Admin…

    Antworten
  2. Hallo zusammen,

    wir haben eine Testumgebung im Mixed Mode.
    Also 2 Exchange 2016 und 2 Exchange 2019.
    Auf einem haben wir jetzt das CU22 installiert aber beim Befehl Set-OrganizationConfig -MitigationsEnabled $false kommt der Fehler
    A parameter cannot be found that matches parameter name ‚MitigationsEnabled‘
    Müssen erst alle auf neuste CU Level gebracht werden?

    Antworten
  3. Nachtrag:

    Jupp, gerade noch mal gecheckt: „Get-Mitigations.ps1“ ist vollkommen wertlos um bereitstehende Mitigationen anzuzeigen, bevor sie angewendet wurden.

    .\Get-Mitigations.ps1
    Es werden keine Risikominderung angewendet

    (OrganizationConfig MitigationsEnabled ist auf $true)

    Dann:
    Set-ExchangeServer -Identity ExchangeServerA -MitigationsEnabled $true
    Set-ExchangeServer -Identity ExchangeServerB -MitigationsEnabled $true

    30 Min Später:
    .\Get-Mitigations.ps1
    Server : ExchangeServerA
    Version : Version 15.1 (Build 2375.7)
    ID : PING1
    Type : Ping
    Description : EEMS Heartbeat probe. Does not modify any exchange settings.
    Status : Applied

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

    Um die Auslieferung neuer Mitigations-Regeln zu checken, bevor man sie angewendet werden, hilft es wohl nur https://officeclient.microsoft.com/getexchangemitigations selbst zu parsen.

    Antworten
  4. Chaos wo man hinschaut,

    die Aussage, dass man mit „Get-Mitigations.ps1“ bereitstehende Mitigationen anzeigen kann, stimmt nicht. Das Skript zeigt nur Mitigationen an, die bereits angewendet wurden.

    .\Get-Mitigations.ps1 zeigt – anders als überall angegeben – immer n-u-r Mitigationregeln an, die auf Servern b-e-r-e-i-ts angewendet werden.

    Es werde keine n-e-u-e-n, einfach nur bereitstehenden Regeln angezeigt. Bei uns zeigt: .\Get-Mitigations.ps1 immer nur:
    Es werden keine Risikominderung angewendet

    Obwohl diese Testregel „PING1“ eigentlich bereitstehen sollte. „PING1“ wird bei uns aber nicht angewendet (auf Organisationsebene sind Mitigationen erlaubt, auf den Exchange Servern nicht), daher wird die „PING1“ von Get-Mitigations.ps1 auch nicht angezeigt.

    Das sind unsere Einstellungen für die Server und die Organisation:

    Set-OrganizationConfig -MitigationsEnabled $true
    Set-ExchangeServer -Identity ExchangeServerA -MitigationsEnabled $false
    Set-ExchangeServer -Identity ExchangeServerB -MitigationsEnabled $false

    .\Get-Mitigations.ps1 ist also wertlos, um abzufragen, ob neue Regeln ausgeliefert wurden, b-e-v-o-r man sie anwendet.

    Will man einfach nur auswerten, ob neue Regeln da sind, bevor man sie anwendet, muss man wohl selbst https://officeclient.microsoft.com/getexchangemitigations selbst parsen.

    .\Test-MitigationServiceConnectivity.ps1
    Ergebnis: Erfolgreich.
    Meldung: Auf den Endpunkt des Minderungsdiensts kann von diesem Computer aus zugegriffen werden.

    Logs dem Mitigations-Dienstes sehen bei uns auch gut aus:
    2021-11-02T11:02:38.891Z,ExchangeServerA,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations successful
    2021-11-02T11:02:38.894Z,ExchangeServerA ,ApplyMitigation,S:LogLevel=Warning;S:Message=No mitigation applied. MitigationEnabled is False

    Antworten
  5. Hallo,

    was macht man wenn die Exchange Server nicht ins Internet dürfen auch nicht gezielt auf die Seite https://officeclient.microsoft.com/*.

    Hätte an sowas gedacht wie Informationen von extern mit eine Internet Access Client abholen und intern unter einer eigenen URL bereitstellen.
    Was denkt ihr ist so ein Szenario denkbar? Wie?
    Dankeschön.

    Antworten
  6. 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
  7. 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
  8. 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
    • Vielleicht hilft es dir weiter. Ich habe das gleiche Problem, das ich mir anschaue. Es scheint, dass die Validierung der Zertifikatskette fehlschlägt
      certutil -verify c:\something\office.cer

      Incomplete certificate chain
      Cannot find certificate:
      CN=Microsoft RSA TLS CA 02, O=Microsoft Corporation, C=US

      ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)

      Antworten
  9. 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
  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 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
    • 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
  18. 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

Schreibe einen Kommentar