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.
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…
Hallo nochmal,
hier Links zu Beiträgen, die ich bzgl. Zertifikatsproblem gefunden habe:
https://techcommunity.microsoft.com/t5/exchange-team-blog/addressing-your-feedback-on-the-exchange-emergency-mitigation/bc-p/3498825#M33257
https://docs.microsoft.com/en-us/answers/questions/887192/exchange-emergency-mitigation-xml-file-contains-ex.html
A lot of Grüße
Wolfgang ;)
Seit heute Nacht wurde das Heartbeat-Skript von Microsoft offenbar mit neuen, gültigen Zertifikaten ausgestattet. Siehe https://techcommunity.microsoft.com/t5/exchange-team-blog/addressing-your-feedback-on-the-exchange-emergency-mitigation/bc-p/3498825#M33257
Die stündlichen Fehlermeldungen sind nun weg.
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?
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.
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
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.
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?
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?
Moin,
bei unserer Fortigate musste ich noch die Symantec-Web-Services zulassen! Dann hat es funktioniert.
Hallo, es scheitert bei uns wie immer am Proxy. https://docs.microsoft.com/de-de/exchange/plan-and-deploy/deployment-ref/ms-exch-setupreadiness-MitigationsCloudEndpointUnreachable?view=exchserver-2019
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
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)
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 :-)
Hallo Paul,
ist bereits in Arbeit.
Gruß,
Frank
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
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.
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
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“
Danke.
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.
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.
Also wie gesagt, ich hab das jetzt auf mehreren Orgs sowie 2016 als auch 2019 getestet und überall war das auf false.
Vielleicht ist das schon die erste „Emergency Mitigation“ ;)
Das wär natürlich clever. Aber am Ende wird es, wenn das öfter vorkommen eben dazu führen, dass im Worst Case doch wieder jede Menge Server ungeschützt rumstehen.
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“.
Ja beim Server. Das hilft aber nix, wenn auf Organization Level nicht auch True gesetzt ist. Liest denn hier niemand die Artikel? ;)
Hi Norbert,
in meinem Lab (Ex2019) ist es auf Organisations-, sowie auf Server Level per Default aktiviert. Ich hab bisher nur das Lab aktualisiert.
Gruß,
Frank
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
Bei mir war es genauso. Exchange 2019 Get-OrganizationConfig | fl MitigationsEnabled -> False
Das selbe hier bei Exchange 2016. Musste es manuell auf true setzen.
Bei mir kommt als Antwort True
Wäre jetzt zu klären, wie und warum es dort Unterschiede gibt.
Bei meinem 2019er (Mitglied in DAG) -> Erst einer upgedatet steht ebenfalls der Wert auf false.
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?
muss da eigentlich dann auch der MS Defender auf den Exchange laufen?
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.
Der ist ja auch erst nach der Installation von CU22/CU11 vorhanden und heißt auf deutschsprachigen Systemen „Microsoft Exchange-Notfallrisikominderungsdienst“
Danke Norbert dieser Dienst ist existent ;-)
also bei mir nennt es sich „Microsoft-Exchange-Notfallschutzdienst“ und verweist auf die Datei Microsoft.Exchange.Mitigation.Service.exe – denke das gilt auch :-)
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
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
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
sehr schön und ausführlich. Danke!
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
Hallo Martin,
kannst du den Link mal posten denn ich habe es über den Webinstaller gemacht (Ex2016) und nun die Version 7.2.1993 installiert.
MfG Paul
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-september-2021-quarterly-exchange-updates/ba-p/2779883
Nino Bilic Microsoft
Sep 28 2021 08:49 AM
@sjhudson Correct, x64 MSI version. I added that to the bullet. Thanks!