[English]Zum 13. Februar 2024 wurde ja eine kritische Schwachstelle CVE-2024-21410 in Microsoft Exchange Server öffentlich. Die Elevation of Privilege-Schwachstelle hat den CVEv3 Score 9.8 und wird wohl (bald) ausgenutzt. Sicherheitsbehörden warnen vor dieser Schwachstelle. In der Blog-Leserschaft gab es aber Verwirrung, weil zum 13. Februar nur das CU 14 für Exchange Server 2019 gab, welches die Schwachstelle aber nicht explizit schließt. Was ist mit Exchange Server 2016 und was muss ich tun, um vor CVE-2024-21410 geschützt zu sein. Hier eine Nachlese mit einem groben Abriss.
Anzeige
Die Schwachstelle CVE-2024-21410
Ich hatte im Blog-Beitrag Microsoft Security Update Summary (13. Februar 2024) vom 13. Februar 2024 auf die Microsoft Exchange Server Elevation of Privilege-Schwachstelle CVE-2024-21410 hingewiesen. Die Schwachstelle ist mit einem CVEv3.1 Score 9.8 als kritisch eingestuft. Inzwischen gibt Microsoft an, dass es zu Angriffen kommt. Die erfolgreiche Ausnutzung dieser Schwachstelle ermöglicht es einem Angreifer, einen New Technology LAN Manager Version 2 (NTLMv2) Hash gegen einen anfälligen Server weiterzuleiten. NTLM-Hashes könnten in NTLM-Relay- oder Pass-the-Hash-Angriffen missbraucht werden, um die Position eines Angreifers in einer Organisation zu stärken.
Das BSI warnt inzwischen vor dieser kritischen Schwachstelle, nachdem Microsoft den Hinweis, dass die Sicherheitslücke bereits aktiv ausgenutzt wird, ergänzt hat. Die Schwachstelle ermöglicht es externen Angreifenden im Zusammenhang mit potenziellen weiteren Verwundbarkeiten in NTLM-Clients (wie Outlook), sich mit entwendeten Net-NTLMv2-Hashwerten bei einem verwundbaren Exchange Server zu authentifizieren und Aktionen mit den Berechtigungen des ursprünglichen Opfers durchzuführen.
Den Exchange Server schützen
Als ich die obigen Beiträge zum Patchday schrieb, war (mir) noch unklar, wie man die Exchange Server schützen könnte. Zum 13. Februar 2024 gab es ja nur ein kumulatives Update (CU 14) für Exchange Server 2019, welches aber keinen Patch vor der Schwachstelle enthält. Inzwischen ist klar, dass der Schutz anders funktioniert und auch Exchange Server 2016 geschützt werden kann.
Anzeige
- Diese oben erwähnten NTLM-Relay-Angriffe können durch die seit Herbst 2022 verfügbare Exchange Server Schutzfunktion Extended Protection (EP), auch Extended Protection for Authentication (EPA) genannt, unterbunden werden.
- Das Update CU14 für Exchange Server 2019 aktiviert Extended Protection (EP) standardmäßig, der betreffende Server ist also dann geschützt. Ohne das CU 14 muss Extended Protection auf Exchange 2019 explizit aktiviert werden.
- Bei Exchange Server 2016 muss das CU23 (April 2022) mit dem Security Update von August 2022 installiert werden, da dort die die Unterstützung für Extended Protection als optionale Funktion eingeführt wurde. Anschließend muss Extended Protection aktiviert werden (siehe auch ja, da gab es hier auch schon einen Artikel dazu: Exchange: Extended Protection, Checkliste und Probleme).
Weitere Details sind dem Supportbeitrag für CVE-2024-21410 zu entnehmen. Bei heise gibt es noch diesen Kommentar, wo jemand einige Anmerkungen macht, warum und wie Extended Protection schützt.
Mögliche Probleme
An dieser Stelle der Hinweis auf diesen Kommentar von Edmund, dessen Clients sich nicht mehr mit Outlook über MAPI/RPC over https verbinden können. Es kommt immer die Aufforderung User/Passwort einzugeben, auch mit korrekten Daten kein Anmelden möglich. In einem Folgekommentar deutet der Leser Zertifikatsprobleme an.
Ergänzung: Frank Carius hat in diesem Beitrag ebenfalls einige Informationen zum Thema zusammen geschrieben.
Ä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)
Warnung vor kritischer Outlook RCE-Schwachstelle CVE-2024-21413
Exchange: Extended Protection, Checkliste und Probleme
Anzeige
Kleine Korrektur: Die Unterstützung für Extended Protection kam für Exchange 2013, 2016 und 2019 schon mit dem Sicherheitsupdate aus August 2022, nicht erst Herbst 2023. Musste man aber manuell aktivieren, am besten per Skript.
Siehe hier: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/ba-p/3593862
Es gab nachträglich noch mal Anpassungen an dem MS-Skript, aber damit wurden nur für zwei der Vdirs das EP-Level niedriger gesetzt, der Schutz selber war aber wie gesagt schon Mitte 2022 möglich, was MS auch empfohlen hat umzusetzen, seofern die Umgebung nicht von den Einschränkungen betroffen war/ist.
@G.Born: es ist immer von Fixes die Rede, die es seit 2023 geben soll.
Richtig ist: die Extended Protection gibt es schon seit August 2022
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/ba-p/3593862
ja, da gab es hier auch schon einen Artikel dazu: Exchange: Extended Protection, Checkliste und Probleme
Eindeutig mein Fehler – hatte mich im Datum verlesen – der verlinkte Blog-Beitrag stammt von August 2022 – ist im Text jetzt korrigiert – danke.
Wenn man es genau gibt, dann gibt es "Extended Protection" schon seit 2010 und kam mit einem Update für Windows 2003! Server. Man hätte es da schon aktivieren können. Aber war recht unsinnig, wenn es die Clients nicht gemacht haben.
Seit Aug 2022 hat Microsoft dann offiziell den Support in Exchange Server aufgeführt. wobei ich nicht genau verstehe, warum es nicht auch ohne geht ,da es eine IIS-Einstellung ist.
Rätselhafter finde ich, dass es ja alle IIS-Apps mit NTLM betrifft und nicht nur Exchange. Aber über SharePoint, WSUS und was sonst noch alles NTLM auf IIS macht, hört man nichts.
Man kann die NTLM-Angriffe auch verhindern, indem man einfach überall NTLM deaktiviert.
Hier ist die Domäne Kerberos-Only, NTLM gibts nicht mehr.
Funktioniert natürlich nur, wenn man nur Software einsetzt, die nicht zwingend NTLM braucht.
Bzgl. Outlook kann schon Outlook 2010 Kerberos only.
Die EP ist hier aber natürlich trotzdem aktiviert.
Wie man Exchange auf Kerberos umstellt, kann man bei Frankys Web nachlesen, funktioniert so auch bei Exchange 2016.
Hab mal die beiden Artikel von Frank Zöchling verlinkt.
Exchange 2013: Authentifizierung auf Kerberos umstellen
Exchange 2019: Kerberos Authentifizierung aktivieren
Mal wieder ein ein schöner Haufen Scheiße vor dem man da steht. Moderne Hybridkonfig ist Ausschlusskreterium. Ich weiß man kann das vDir von EWS skippen aber gibt es mittlerweile eine Aussage von Microsoft ob die Sicherheitslücke dann überhaupt korrekt geschlossen ist?
so wie ich es verstehe ist der Server dann weiter verwundbar.
Microsoft empfiehlt für hybrid einen separaten Exchange bereitzustellen als Endpunkt auf dem keine Mailbox gehostet wird..
natürlich sicherlich lizenzpflichtig ;)
wie man sich in einer singe Exchange Umgebung schützen soll ist nicht beschrieben.
ein reiner hybrid ohne Mailboxen ist gültig mit einer Gratislizenz, sobald du aber mailboxen betreibst aber kostenpflichtig, macht somit keinen Unterschied bei den Lizenzen.
Server Pending Reboot: True — Warning a reboot is pending and can cause issues on the server.
HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
More Information: https://aka.ms/HC-RebootPending
Bekomme trotz mehrerer Neustarts die Meldung nicht weg. Wird dauerhaft seit der neuesten HealtChecker Version angezeigt. Jemand eine Idee ? Einfach Werte in der Reg löschen, …. ?!
Ja, werte in der PendingFileRenameOperations löschen. Hatte das gestern auch bei einigen Exchanges, dann ging die Installation.
Das reicht nicht.
Die Meldung im Health Checker ist erst weg, wenn man den Schlüssel "PendingFileRenameOperations" löscht.
Hat jemand das Enabling Script zum Laufen zu bringen?
Er fordert immer die Exchange Management Shell, dies nutze ich auch elevated geht einfach nicht grml
Hat dein Nutzer die entsprechenden Rechte? Bei mir lief das Script damals sauber durch und ich habe es erst gestern noch mal laufen lassen, weil der HealthChecker in zwei VDirs falsche Einstellungen gefunden hatte. Die kamen daher, dass die das Script noch mal angepasst hatten. Daher neuste Version geladen und noch mal ausgeführt. Ging problemlos.
Ok, gefunden. Eine elevated Powershell starteten und das Script lädt das Snapin selbst nach *grml*
Achtet auf die aktuellste Fassung des Scripts – gestern bei heise noch einen Kommentar gelesen, dass jemand sich wohl mit einer Uralt-Variante des Exchange abgeschossen hat.
Nein es war die aktuellste Version direkt von MS geladen.
Es hat definitiv nur funktioniert als ich eine
'normale' Powershell als Admin gestartet habe. Diese hat dann das Snapin nachgeladen und EP aktiviert. In der EMS schlug das Script fehl da es das Snapin nicht laden konnte, logisch war ja schon, EMS halt und hat diese verwirrende Fehlermeldung ausgegeben.
So hat es hier funktioniert.
Hallo,
Wir haben einige andere Probleme zusammen gefasst für Exchange 2013/2016/2019:
* Load Balancer KEMP&F5 (Komplex Umstellung nötig/Downtime)
* Retention Archivierungen (Achtung nicht mehr compliant ohne workaround!)
* Bei on-premises M365/EXO/Cloud > Bestimmen CLASSIC / MODERN Hybrid Mode oder keiner
Frank hat eine gute Zusammenfassung für andere Punkte geschrieben. Diese Punkte waren bis gestern nicht da drin.
Moin, Moin,
könnte es eine Abhilfe schaffen, wenn ich per GPO NTML Authentifizierung domänenweit verbieten würde?
die Einstellung – Netzwerksicherheit: Beschränken von NTLM: NTLM-Authentifizierung in dieser Domäne
Danke und Viele Grüße
Wikont