[English]Microsoft hat zum 8. November 2022 Sicherheitsupdates für Exchange Server 2013, Exchange Server 2016 und Exchange Server 2019 veröffentlicht. Diese Updates sollen die seit Ende September 2022 bekannten (und bereits ausgenutzte) NotProxyShell-Schwachstellen, die von externen Sicherheitspartnern gemeldet wurden, schließen.
Anzeige
Microsoft hat den Techcommunity-Beitrag Released: November 2022 Exchange Server Security Updates mit einer Beschreibung der Sicherheitsupdates veröffentlicht.
Es stehen Sicherheitsupdates für folgende Exchange-Server CU-Versionen zur Verfügung (Links von Microsoft, die teilweise Downloads von August 2022 aufweisen – aber die KB-Artikel sind in den Details richtig verlinkt).
- Exchange Server 2013 CU23 (Support endet im April 2023)
- Exchange Server 2016 CU22, CU23
- Exchange Server 2019 CU11, CU12
Microsoft schreibt im Techcommunity-Beitrag, dass die Sicherheitsupdates vom November 2022 Korrekturen für die Zero-Day-Schwachstellen enthalten, die am 29. September 2022 öffentlich gemeldet wurden (CVE-2022-41040 und CVE-2022-41082).
Das Sicherheitsteam des vietnamesischen Cybersicherheitsunternehmen GTSC entdeckte Anfang August 2022 im Rahmen von Sicherheitsüberwachungs- und Incident-Response-Tätigkeiten, dass eine kritische Infrastruktur angegriffen wurde. Während der Untersuchung stellten die Experten des Blue Teams von GTSC fest, dass der Angriff eine unveröffentlichte Exchange-Sicherheitslücke, d.h. eine 0-Day-Schwachstelle, ausnutzte. Ich hatte im Blog-Beitrag Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022).
In Folge dieser Berichte versuchte Microsoft die Schwachstellen mit Workarounds zu schließen, was aber in ein "Drama" ausuferte, da täglich neue Korrekturhinweise für Filterregeln veröffentlicht werden mussten. Siehe meine Links am Artikelende, die zu Blog-Beiträgen führen, die über diese Problematik und Microsofts Nachbesserungen berichten.
Wer diese Workarounds (u.a. Remote PowerShell deaktivieren) verwendet hat, sollte diese nach Installation des November 2022-Update wieder rückgängig machen.
Beachtet Microsofts Hinweise zur Update-Installation. Zu beachten ist, dass die Exchange Server auf das aktuelle CU aktualisiert werden, bevor die November 2022-Updates installiert werden (siehe obige Grafik und den Hinweis von Microsoft). Zur Prüfung kann das HealthChecker-PowerShell-Script von Microsoft verwendet werden.
Anzeige
Diese Sicherheitslücken betreffen Exchange Server. Exchange Online-Kunden sind bereits vor den in diesen SUs behandelten Sicherheitslücken geschützt und müssen außer der Aktualisierung aller Exchange-Server in ihrer Umgebung keine weiteren Maßnahmen ergreifen.
Ähnliche Artikel:
Sicherheitsupdates für Exchange Server (Januar 2022)
Sicherheitsupdates für Exchange Server (8. März 2022)
Exchange Server April 2022 CU (20.4.2022)
Kumulative Exchange Updates Juni 2021 veröffentlicht
Probleme mit Exchange März 2022-Updates
Microsoft 365-Bug: Mails aus Exchange Online und Outlook landen im Spam-Ordner
Microsoft Exchange Admin-Portal wegen ausgelaufenem Zertifikat blockiert
Exchange Update-Fehler und -Infos (13. April 2021)
Exchange-Probleme mit ECP/OWA-Suche nach Sicherheitsupdate (März 2021)
Exchange 2016/2019: Outlook-Probleme durch AMSI-Integration
Exchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service
Exchange Server 2016-2019: Benutzerdefinierte Attribute in ECP nach CU-Installation (Juli 2021) nicht mehr aktualisierbar
Basic Authentication in Exchange Online wird ab Oktober 2022 eingestellt
Exchange: Extended Protection, Checkliste und Probleme
Update für Exchange Extended Protection-Script, aber weiterhin Fehler
Exchange 2016/2019: Outlook-Probleme durch AMSI-Integration
Exchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service
Exchange: Extended Protection, Checkliste und Probleme
Update für Exchange Extended Protection-Script, aber weiterhin Fehler
Exchange Health Checker – Script-Erweiterungen von Frank Zöchling
Exchange Server Sicherheitsupdates (9. August 2022)
Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022)
Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333
Neues zur Exchange Server 0-day-Schwachstelle ZDI-CAN-18333: Korrekturen, Scripte und EMS-Lösung
Exchange Server: Microsofts 0-day-Schutz aushebelbar, neue Einschätzungen (3. Oktober 2022)
Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (5. Oktober 2022)
Exchange Server: Neue 0-day (nicht NotProxyShell, CVE-2022-41040, CVE-2022-41082)
Microsoft Exchange Server: Remote Code Execution-Schwachstelle CVE-2022-23277 trotz Patch ausnutzbar?
Anzeige
noch niemand installiert?
Doch, alles gut. Ohne Probleme, kein Anwender hat irgendetwas gemeldet.
Gestern schon auf Windows Server 2016 / Exchange Server 2016 CU23 / Extended Protection ON
…alles OK ;)
unser Exchange kann seither nicht mehr gestartet werden
kein einziger Dienst funktioniert
Hier auch Probleme – Mails werden teils stark zeitverzögert zugestellt. Dann Mailserver komplett eingefrohren heute Vormittag. Nur Hardreset ging noch. Seit dem läufts, aber einzelne Mails brauchen immernoch länger. Keine Ahnung was da los ist.
Das kann ich bestätigen. Bei mir geht auch nichts mehr
Wie ist der aktuelle Stand bei Euch? Habt ihr die Mitigations wieder zurückgebaut?
Nein, alles so gelassen, wie von Microsoft ausgeliefert.
Im Teamblog gibt es dafür auch eine Information:
Do we have to remove mitigation for CVE-2022-41040 after installing the November 2022 (or later) SU?
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2022-exchange-server-security-updates/ba-p/3669045
Keine Probleme mit dem Nov. Update. .
Ex2016 CU23 auf Server 2016 mit EP enabled.
Über cmd (elevated) installiert.
Defender sollte man währen der Installation deaktivieren und den Server vor dem Update rebooten.
ebenso auf 2013 und 2019 – alles gut.
Keine Probleme auf 2019 CU12 festzustellen.
Lief auch erstaunlich schnell durch.
Ex2016 CU23 auf Server 2016 mit EP enabled: keine Probleme
Hallo
problemlos auf Exchange 2019 CU12 installiert
so long
Yumper
@M. Hilser @Rene
Welche Exchange Version mit welchem CU habt ihr im Einsatz?
Habt ihr nur das SU installiert oder auch gleichzeitig Windows Updates mit?
normale Server Updates installiert und gleichzeitig das SU .
Alles aus Windows Update
Exchange 2016 CU 23 mit Extended Protection installiert – läuft :-) auf einem 2012 R2
Exchange 2016 CU 23 mit Extended Protection installiert – läuft :-) auf einem 2012 R2
EX2016 CU23 ohne Probleme per WSUS installiert.
Hier ein Fund über Twitter zu ProxyNotShell"Relay"
Will Dorman hat diesen Artikel retweetet. Was die Mitigations angeht, sind diese wohl eben nicht so sicher, wie man vielleicht denkt…
Äusserst interessanter Artikel. Man sollte sich aber vorher eine Kanne Kaffee oder Tee machen. Ist ewas länger…
ProxyNotRelay – An Exchange Vulnerability Encore
Ich hoffe Guenni lässt den Link durch.
Ich lasse Links normalerweise immer durch – nur wacht ein SPAM-Filter und schiebt die Kommentare mit Links grundsätzlich in Moderation. Wenn ich dann sehe, es ist reiner SEO-Spam oder irgend etwas anderers obskures, lösche ich.
November SU auf Exchange 2013 installiert. Keine Probleme. Die Mitigation-Regeln habe ich erstmal drin gelassen.
KB5019758 heute an 2016 CU23 (2-Node DAG) eingespielt. Verlief ohne Probleme.
Exchange 2016 CU 22 mit EP keine Probleme
Installation auf Exchange 2016 CU23 mit EP keine Probleme. OS Windows Server 2016. Vor Update Exchange durchgestartet + Virenwächter deaktiviert. Ausführen der .exe mit erhöhten Rechten.
Macht bei mir leider Probleme, 2012 R2 mit Exchange 2016 CU23 DAG, EnvtLog etliche Einträge mit ID 15021 "Bei der Verwendung der SSL-Konfiguration für den Endpunkt 0.0.0.0:444 ist ein Fehler aufgetreten. Der Fehlerstatuscode ist in den zurückgegebenen Daten enthalten."
Installation problemlos unter Exchange 2016 CU 23 auf Server 2012R2.
Nach erstem Kurztest: Alles scheint einwandfrei zu funktionieren
Moin zusammen,
versteht einer von euch warum man das Deaktivieren von Remote Powershell für nicht-administrative Konten rückgängig machen sollte. Das macht doch ohnehin Sinn?!
Das man die Rewrite-Rule wieder löscht, kann ich ja verstehen.
Danke und Gruß
Bent