[English]Microsoft hat zum 13. Februar 2024 das kumulative (Funktions-) Update CU 2024 H1 für Exchange Server 2019 veröffentlicht. Diese Update (CU 14) enthält Korrekturen für von Kunden gemeldete Probleme, eine Sicherheitsänderung und alle zuvor veröffentlichten Sicherheitsupdates (SUs).
Ich bin auf Twitter auf nachfolgenden Tweet des Exchange-Teams zum Update CU 2024 H1 (CU 14) für Exchange Server 2019 gestoßen. Zudem hat ein Leser mich per Mail auf das Update hingewiesen (danke dafür). Microsoft hat den Techcommunity-Beitrag Released: 2024 H1 Cumulative Update for Exchange Server mit einer Beschreibung der Updates veröffentlicht.
Mittlerweile befindet sich nur noch Exchange Server 2019 im Support für CUs und bekommt das vorletzte CU (siehe Exchange Server 2019 Mainstream Support endete am 9. Januar 2024 – hat aber wenig Konsequenzen). Das kumulative Update (CU) 2024 H1 für Exchange Server 2019 (CU14) enthält Korrekturen für von Kunden gemeldete Probleme, eine Sicherheitsänderung und alle zuvor veröffentlichten Sicherheitsupdates (SUs).
Exchange Server 2019 Cumulative Update 14 (KB5035606), VLSC Download, Download
Das Update schließt über die standardmäßig jetzt aktivierte Extended Protection (EP) die in Microsoft Security Update Summary (13. Februar 2024) beschriebene kritische Schwachstelle CVE-2024-21410 (siehe Microsoft Exchange Server Elevation of Privilege Vulnerability CVE-2024-21410). Eine vollständige Liste der Fehlerbehebungen ist im KB-Artikel für CU14 enthalten.
Änderung und Neuerungen bei CU 14
Mit dem kumulativen Update (CU) 2024 H1 (CU14) werden einige Änderungen bzw. Neuerungen an Exchange Server 2019 vorgenommen.
Extended Protection standardmäßig aktiviert
Es war bereits im August 2023 angekündigt worden: Das Setup aktiviert ab CU14 standardmäßig das Feature Windows Extended Protection (EP) auf dem zu installierenden Exchange-Server.
Dies geschieht, wenn Administratoren die GUI-Version von Setup ausführen und wenn diese die Befehlszeilenversion von Setup ausführen, ohne den Setup-Schalter /DoNotEnableEP oder /DoNotEnableEPFEEWS zu verwenden, um die Aktivierung zu deaktivieren. Weitere Informationen finden sich in der EP-Setup-Dokumentation.
Obwohl Setup EP standardmäßig aktiviert, wird nicht überprüft, ob Ihre Organisation bereit oder in der Lage ist, EP zu verwenden. Details dazu finden sich im Techcommunity-Artikel.
Unterstützung für .NET Framework 4.8.1 auf Windows Server 2022
Mit CU14 wird auch die Unterstützung für .NET Framework 4.8.1 eingeführt. Das gilt aber nur Exchange 2019-Versionen, die auf Windows Server 2022 installiert sind (kann nicht auf älteren Versionen installiert werden). Die Unterstützungsmatrix für Exchange Server wurde aktualisiert, um diese Änderung widerzuspiegeln.
TLS 1.3-Unterstützung auf CU15 verschoben
Ursprünglich war angekündigt, dass mit dem CU14 TLS 1.3 auf Windows Server 2022 kommt. Dies trifft aber nicht zu, sondern das ist auf CU 15 verschoben. Microsofts Entwickler testen und validieren TLS 1.3 noch mit Exchange Server und wollten die Veröffentlichung von CU14 nicht verzögern. Die Unterstützung für TLS 1.3 wird in CU15 noch in diesem Jahr veröffentlicht.
Der Techcommunity-Beitrag Released: 2024 H1 Cumulative Update for Exchange Server enthält noch einige Hinweise zur Schwachstelle CVE-2024-21410. In den Kommentaren werden diverse Fragen im Zusammenhang mit der Update-Installation diskutiert.
Ähnliche Artikel:
Office: Projekt Update KB5002530 vom 6. Februar 2024
Microsoft Security Update Summary (13. Februar 2024)
Patchday: Windows 10-Updates (13. Februar 2024)
Patchday: Windows 11/Server 2022-Updates (13. Februar 2024)
Windows Server 2012 / R2 und Windows 7/Server 2008 R2 (13. Februar 2024)
Microsoft Office Updates (13. Februar 2024)
Exchange Server Updates (13. Februar 2024)
Nachlese zu CU 14 für Exchange 2019 und Schwachstelle CVE-2024-21410 (Feb. 2024)
Warnung vor kritischer Outlook RCE-Schwachstelle CVE-2024-21413
Exchange: Extended Protection, Checkliste und Probleme
„Obwohl Setup EP standardmäßig aktiviert, wird nicht überprüft, ob Ihre Organisation bereit oder in der Lage ist, EP zu verwenden.“
DAS wäre ja auch zu viel verlangt. Da released MS lieber Healthcheck-Sripts und so ein Zeug das einem dann sagt das etwas nicht stimmt anstatt es selbst zu fixen. Lustig finde ich hierbei die Warnung (ROT!) das die automatische Verwaltung der Auslagerungsdatei aktiviert ist. die AUTOMATISCHE Verwaltung… nein, kann man sich nicht ausdenken.
Mal einige Tage abwarten bevor ich das Teil wo installiere.
das Problem ist aber nicht auf Seiten MS, es gibt sehr viele kundenseitige Konstellationen, wo 3rd party software implementiert ist, die nicht für EP geeignet sein können bzw. nicht ausreichend dafür konfiguriert.
Es muss dann also definitiv vom Kunden eingegriffen und nachgebessert werden – nichts das MS hier beeinflussen oder selbst fixen könnte, da 3rd Party Anwendung.
der Health Checker prüft Best Practices. Und auf einem Exchange 2019 sollte die automatische Verwaltung der Auslagerungsdatei nicht eingestellt sein, sondern fix konfiguriert werden
„Lustig finde ich hierbei die Warnung (ROT!) das die automatische Verwaltung der Auslagerungsdatei aktiviert ist. “
Das ist aber schon gefühlt ewig so, man soll beim Exchange die Größe der Auslagerungsdatei fest zuweisen, gibt sogar ne Faustformel dafür. (Oder auch Skripts von z.Bsp. Frank Zöchling, die das passend umsetzen)
Bezüglich des Extended Protection: Bisher musste man das per Script selbst aktivieren, ich bin mir gerade nicht sicher, ob dieses bestimmte Voraussetzungen geprüft hat. Da ein Teil der Voraussetzungen (SSL-Offloading und SSL-Bridging) auch andere Komponenten betrifft die MS gar nicht prüfen kann war aber bisher auch Handarbeit nötig.
Viel Schlimmer finde ich, dass es immer noch Szenarien gibt, in denen man das nicht aktivieren kann/darf (Modern Hybrid irgendwer?) und diese Systeme nun im Regen stehen, da das neuste CVE ja nur durch die Aktivierung verhindert werden kann.
Man sollte ja meinen, MS hätte da eine vernünftige Lösung für.
Ja, ich weiß, gibt es schon lang. Ich frage micht halt nur was dann der Sinn der automatischen Auslagerungsdateigröße sein soll, wenn ich sie erst händisch setzen soll und ggfl. zu klein einstelle und das System crashed. Das System ist ja ein Tool um MIR meine Arbeit zu erleichtern, nicht andersrum.
Ja, frage ich mich auch. „Lösung“ ist das irgendwie keine was MS hier macht.
für Modern Hybrid lässt sich EP teilweise aktivieren. Verwendet dafür den Switch /DoNotEnableEP_FEEWS
Quelle: https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-extended-protection?view=exchserver-2019
Scenario #2
Ja, steh jetzt irgendwie erstmal dumm da.
Habe genau den Fall, einen 2019 für Modern Hybrid.
Das ist natürlich keine Extended Protection an, da ja MS ausführlich damals darauf hingewiesen hat das man das bei hybrid nicht aktivieren soll.
Popcorn Essen, dokumentieren, mit der Geschäftsleitung / Vorstand sprechen, was soll gemacht werden, geklagt werden? Exchange abschalten?
Irgendwann reicht es halt einfach was MS da verbockt… Es nervt nur noch. Ich habe auch keine Lust mehr jedes mal mich neu zu ärgern…. :(
Extended Protection ist bei uns zwar an, aber naja… man zwingt die Leute zu Exchange Online…
Solange die Leute sich zwingen lassen, werden diese Zwänge hier und da immer weiter ausgerollt werden…
Nur der Vollständigkeit halber: Das Cumulative Update 14 ist _kein_ neues Sicherheitsupdate. Es ist ein Funktionsupdate, das auch alle bis dahin enthaltenen Sicherheitsupdates einschließt. Das CU14 schließt _nicht_ die Schwachstelle CVE-2024-21410. Diese Schwachstelle wird, nach allem was ich aus den Dokumenten herauslese, durch aktivieren des Härtungs-Features „Extended Protection“ (EP) geschlossen.
Diese EP gibt es für alle unterstützten Exchange Versionen seit August 2022(!) und sollte wirklich schon vor langer Zeit aktiviert worden sein (das war auch genügend Zeit, die eigene SSL-Offloading Konfiguration zu ändern, falls sie nicht unterstützt wird).
Das Microsoft es in dieser Zeit nicht hinbekommen hat, seine eigene Hybrid Lösung für Extended Protection tauglich zu machen, ist allerdings ein Armutszeugnis (wie andere schon geschrieben haben). Damit werden genau die Kunden im Regen stehen gelassen, die brav ihre lokalen Exchange Server mit der Cloud verknüpfen, um Stück für Stück in die Cloud zu migrieren.
Du hast Recht mit dem Stichwort „Sicherheitsupdate“ – ich habe das (hoffentlich) durchkorrigiert. Da die Extended Protection (EP) standardmäßig aktiviert wird, bin ich davon ausgegangen, dass CVE-2024-21410 mitigiert ist. Aber es ist gut, dass Du da nochmals explizit auf den Sachverhalt hinweist. Ansonsten sind die Microsoft-Dokumente bei Fragen und Zeifelsfällen die Referenz, da Microsoft da ergänzen kann.
EP gabs sogar noch für Exchange 2013.
Aber das sollte nun wirklich nicht mehr im Einsatz sein, das ist EOL und bekommt keine Sicherheitsupdates mehr.
bezüglich Modern Hybrid: Microsoft hat da tatsächlich nen switch (“ /DoNotEnableEP_FEEWS“ )in das setup eingebaut der Extended Protection aktiviert und das FrontEnd-EWS ( was ja das problem bei modern hybrid ist) davon ausnimmt. Siehe https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-extended-protection?view=exchserver-2019#scenarios-that-could-affect-client-connectivity-when-extended-protection-was-enabled
Gut zu finden ist das natürlich nicht..
Stimmt, aber die Frage ist halt, ob dann das CVE trotzdem vollständig behoben/mitigiert ist. Es bleibt ja das FrontEnd-EWS weiterhin ungeschützt. Das sieht für mich eher wie ein Würgaround als denn eine vernünftige Lösung aus.
Ich meine klar, ist bessere als gar nichts, aber sieht für mich trotzdem irgendwie „unschön“ aus.
bei modern hybrid wird Exchange nicht veröffentlicht, daher gibt es weniger Grund, sich aufzuregen. Bliebe noch die Schwachstelle von intern, aber da gibt es in jeder AD dutzende, auf eine mehr oder weniger kommt es auch nicht an.
nicht in gehärteten Umgebungen ;) es reicht meist eine Schwachstelle aus um die Mauer zum Einsturz zu bringen. Und der aktuelle ZeroTrust Ansatz geht ja auch davon aus, dass intern nicht gleich vertrauenswürdig ist.
Meine Empfehlung wäre daher schon EP zu aktivieren, so weit halt möglich.
meines Erachtens gibt es keine wirklich gehärteten Umgebungen.
Zu komplex.
jede Maßnahme die optional ist, aber zum Schutz beiträgt ist eine Härtungsmaßnahme. Will da jetzt nicht philosophisch werden – im Falle vom AD sind per default sehr viele Dinge erlaubt, die mehr ermöglichen als empfohlen -> Härtungsmaßnahmen und damit Angriffsflächen reduzieren.
Viele Umgebungen machen das aber nicht, entweder zu komplex od. Altlasten die Gewisse Dinge verhindern, aber möglich ist es auf jeden Fall, kann das bestätigen da das einer meiner Hauptbereiche ist.
So ist es.
Auch abseits des ADs sind bei einer Standardinstallation sehr viele Dinge mangelhaft konfiguriert, u.A. auch Rechte, Logging, etc. und es sind unnötige Dienste aktiv (beispielsweise auf Servern der Druckdienst und der Audiodienst).
Auch auf Clients kann man die Angriffsflächen sehr deutlich reduzieren.
Hmm,
was ist eigentlich mit Exchange 2016? Das ist ja noch im Extended Support. Laut
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21410
ist das betroffen, aber kein Patch verfügbar.
Ganz toll Microsoft.
Wenn ich es richtig interpretiere, bekommt Exchange 2016 ja keine CUs mehr – bei Exchange 2019 werden 2024 ja noch die fehlenden CU 14 und 15 nachgeholt. Da mit der Extended Protection (EP) die Schwachstelle behoben wird, und in Exchange 2019 diese Option standardmäßig mit dem CU 14 aktiviert wurde, gibt es keine Notwendigkeit, für Exchange 2016 was auszurollen. Aber vielleicht liege ich daneben.
Nee, du liegst genau richtig.
Die Lücke wird durch EP geschlossen.
Und EP gabs schon für Exchange 2016.
Daher ist Exchange 2016/2019 mit aktiviertem EP bzgl. der Lücke sicher.
Und man sollte EP eh schon lange aktiviert haben.
Wenn nicht, dann wirds jetzt aber allerhöchste Zeit!
Wer damals (als dies im August 2022 herauskam) die EP per Script scharf geschaltet hat, kann sich entspannt zurücklehnen.
2016 bekommt aktuell nur SUs, keine CUs. End of Life bei 2016 ist der gleiche Zeitpunkt (Oct 14, 2025) wie bei 2019, außer dass man beim 2016er keine CUs mehr bekommt. Security Fixes bekommen beide, 2016 und 2019, noch – daher keine Panik. ;)
Hmm,
ok, bei dem scheint Aktivieren von Extended Protection zu genügen. Die Anleitung ist nicht gerade trivial, aber hey, wer Exchange nutzt sollte Spass verstehen :-/
Der Spass ist mir bei diesem Produkt restlos vergangen :(
Ich hatte in einem Supportticket bei Microsoft nachgefragt ob Hybrid mit Mördern Auth und modern Agent die Extended Protection unterstützt. Die Antwort war nein wird offiziell nicht unterstützt!
Wenn ich als CU14 installiere und direkt die Extended Protection aktiviert wird finde ich das nicht lustig..
Lies dir doch einfach nochmal den Artikel in Ruhe durch.
…Dies geschieht, wenn Administratoren die GUI-Version von Setup ausführen und wenn diese die Befehlszeilenversion von Setup ausführen, ohne den Setup-Schalter /DoNotEnableEP oder /DoNotEnableEPFEEWS zu verwenden, um die Aktivierung zu deaktivieren. Weitere Informationen finden sich in der EP-Setup-Dokumentation…
Der korrekte Parameter ist: DoNotEnableEP_FEEWS
Dieser wird dann einfach auf dem Server verwendet, der beim modern hybrid Agent als Target Server gesetzt wurde.
Eigentlich ganz einfach (steht auch so in der Doku die man vorher besser lesen sollte).
Microsoft hat den Advisory für CVE-2024-21410 nun überarbeitet und gibt an, dass die Schwachstelle bereits ausgenutzt wird / wurde:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21410
Gibt auch von BleepingComputer einen Artikel dazu:
https://www.bleepingcomputer.com/news/security/microsoft-new-critical-exchange-bug-exploited-as-zero-day/
Ist jetzt in der Nachlese (siehe Links am Artikelende) aufgegriffen.
Hallo Leute, Welche Probleme sind den bei aktivierter Extended Protection zu erwarten? Hat jemand Probleme damit?
Ja, meine Clients können nicht mehr mit Outlook über MAPI/RPC over https nicht mehr verbinden, es kommt immer die Aufforderung User/Passwort einzugeben, auch mit korrekten Daten kein Anmelden möglich. Ich denke gerade darüber nach einen Rollback zu machen.
Scheint möglicherweise daran zu liegen, dass meine WAF ein anderes (gekauftes) SSL Zertifikat verwendet als der Exchange selbst (interne Root CA).
Für die extended Protection müssen beide bzw. alle in der Kette das exakt gleiche Zertifikat verwenden.
Oder es ist möglicherweise noch NTLMv1 aktiviert.
danke, das wars
Wir nutzen Exchange 2019 ohe WAF mit gekauftem Zertifikat. Extended Protection ust aktiviert. Seit dem Update kann kein Outlook Client mehr zugreifen. Es kommt immer Benutzername Passwort Abfrage. Hast du dazu schon eine Lösung gefunden?
Eventuell mach eure AV-Lösung eine DPI-SSL. Das könnte deine Probleme verursachen.
Haben die Outlook Clients einen ausgehenden Proxy. Manchmal ist es auch ein lokaler Virenscanner, der sich als „Proxy“ einklemmt.
Ansonsten habe ich auf https://www.msxfaq.de/windows/iis/iis_extended_protection.htm beschrieben, was dahinter passiert. Vielleicht hilft das bei der Suche
Hallo, wir verwenden die SeppMail-Technologie zur Verschlüsselung von E-Mails. Der schwere Client macht Probleme und löst diese Anmeldung aus. Nach der Deaktivierung dieses Plugins ist es ok. Mein Rat: Starten Sie Outlook im fehlerfreien Modus (alle Plugins deaktiviert) und prüfen Sie, ob alles in Ordnung ist. Wenn dies der Fall ist, ist eines Ihrer Pluggings dafür verantwortlich.
Hallo, wir verwenden die SeppMail-Technologie zur Verschlüsselung von E-Mails. Der schwere Client macht Probleme und löst diese Anmeldung aus. Nach der Deaktivierung dieses Plugins ist es ok. Mein Rat: Starten Sie Outlook im fehlerfreien Modus (alle Plugins deaktiviert) und prüfen Sie, ob alles in Ordnung ist. Wenn dies der Fall ist, ist eines Ihrer Pluggings dafür verantwortlich.
Wird bei euch die CU14 als Download im Admin Center angeboten? Ich finde hier nur die CU13. Per WindowsUpdate wird ebenfalls keine CU14 angeboten,
CUs kamen noch nie per Windows Update, nur die Sicherheitsupdates für die CUs. Das aktuelle CU kannst Du hier herunterladen: https://www.microsoft.com/de-de/download/details.aspx?id=105878
Wichtig ist, vor dem CU14 die Voraussetzungen zu prüfen: https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-extended-protection?view=exchserver-2019
Wenn die Voraussetzungen stimmen, ggf. vor dem CU14, mittels dieses Scripts, das EEP aktivieren:
https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/
Unterstützung liefert immer das HealthChecker Script, zumindest wo noch Fallstricke lauern könnten und ob es bekannte Sicherheitslücken gibt: https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/
Viel Erfolg!