CVE-2024-21410 Betrachtung

Sie haben sicher mitbekommen, dass Microsoft am Feb 2024 nicht nur das 2024H1(CU14) Update für Exchange 2019 sondern im gleichen Zug auch noch ein CVE-Meldung mit einem Rating von 9,1/9,8 veröffentlicht wurde. Wer den CVE Bericht anschaut, bekommt erst einmal einem Schreck und fühlt sich an Hafnium erinnert. Ich möchte hier meine Überlegungen beschreiben:

Kurzanalyse Exchange 209 CU14 und CVE-2024-21410
https://youtu.be/YyQiLRQycAU

Erklärung als Video

Erklärung als Audio

Hinweis: CVS-2024-21410 ist keine Exchange Lücke, sondern eine NTLM-Attacke gegen den IIS, der von Exchange nicht mit IIS Extended Protection konfiguriert wurde. Die Lücke betrifft aber jede Webseite, die auf einem IIS ohne aktiver IIS Extended Protection und aktivierter "Windows Integrated Authentication" gehostet wird, also auch WSUS, SharePoint, Skype for Business Webdienste und viele 3rd Party Lösungen auf dem IIS. Wann merken es die anderen Produktgruppen und Firmen?

Foliensatz des Webcast bei KES Information Security 20240223_kes_cve-2024-21410.pdf
https://www.kes-informationssicherheit.de/webinare/exchange-sicherheitsluecke-cve-2024-21410-schliessen-so-gehts/

Kurzfassung

Für die eiligen Leser:

  • Das "Problem" besteht schon sehr lange und ist vermutlich nicht nur ein Exchange-Thema
    Wenn ein Server per NTLM erreichbar ist und ein Angreifer einen NTLMv2-Hashwerte abgreifen kann, kann er sich als User ausgeben. Allerdings sind Exchange Server und insbesondere ActiveSync und EWS leider "dankbare" Ziele für solche Angriffe
  • Seit zwei Jahren kann die Schwäche geschlossen werden, aber es haben wohl nur wenige auch umgesetzt.
    Die Abhilfe ist die Aktivierung von Exchange Extended Protection. war seit Aug 2022 von Exchange 2016/2019 unterstützt wird. Die Funktion IIS Extended Protection gibt es schon seit März 2010 auf Windows 2003!. und an vielen Stellen hat Microsoft schon früher darauf hingewiesen. Exchange macht nun als erste Produktgruppe ernst und jetzt hat man die Aufmerksamkeit
  • Seit März 2023 ist eine Outlook-Lücke (CVE-2023-23397) bekannt
    Ein Angreifer kann von einem Benutzer einen Net-NTLMV2-Hash angreifen, ohne dass der Anwender aktiv werden muss.
  • Exchange 2019 2024H1 (CU14) vom 13. Feb 2023 ist keine Voraussetzung für die Absicherung
    Das CU14 ist ein Cumulative Update mit neuen Features und Fehlerkorrekturen mit ca. 5GB Umfang und damit kein Security Update (SU).
  • Absicherung mittels Exchange Extended Protection
    Die Verwendung eines solchen Net-NTLMv2-Hash soll mit aktivierter "Extended Protection" nicht mehr möglich sind. Dies funktioniert auch mit Exchange 2016 CU23 und Exchange 2019CU13. CU14 aktiviert es nur automatisch als Standard. Die Aktivierung von Exchange Extended Protection hat ggfls. Auswirkungen auf die Funktion und bedarf Vorarbeiten und Kontrollen.

Nichtdestotrotz aktiviert das Exchange 2019 CU14 bei der Standard-Installation die Funktion Exchange Extended Protection und könnte damit die Funktion stören.

Das Risiko ist hoch, wenn es ein Angreifer auf sie absieht und ihre Exchange Server einen NTLM-Hash von einem Angreifer annimmt, den dieser vorher "verloren" hat. Denken Sie dabei nicht nur an externe Angreifer aus dem Internet. Es könnte auch sein, dass ein Angreifer schon einen Agenten, Bot oder VPN-Zugang in ihr LAN hat. Zudem können Sie nicht sicher sein, dass alle Client ein aktuell gepatchtes Outlook haben und NTLM generell abschalten ist meist nicht möglich.

Mein Rat:
Aktualisieren Sie Exchange umgehend auf 2016CU23, 2019CU13 oder 2019CU14.
Aktivieren Sie manuell Exchange Extended Protection, wenn die CU14 Installation es noch nicht gemacht hat.
Sollte danach die Anwender nicht mehr arbeiten und sie nicht schnell die Ursache abstellen können, dann deaktivieren Sie Exchange Extended Protection temporär wieder und arbeiten Sie an einer Lösung der Ursache, warum Exchange Extended Protection nicht funktioniert.

Dazu finden Sie hier auf der Seite entsprechende Informationen und die Seite Exchange Extended Protection.

Angriffsvektor

Leider sind die die Quellen sehr nichtssagend aber ich vermute, dass es nicht um eine echte Lücke in Exchange geht. Im im aktuellen Ex2019CU14 ist kein Patch enthalten, der nicht schon im EX2019CU13 oder gar Ex2016CU23 enthalten ist. Die Lücke besteht darin, dass Angreifer einen Net NTLM2Hash erhalten und sich damit am Postfach des Anwender anmelden können. Das ist natürlich auch nicht gut, wenn es "interessante" Postfächer sind. Meine Analyse zeigt folgendes Vorgehen:

  1. Vorbereitung
    Der Angreifer stellt einen präparierten SMB-Server auf, der vom Opfer erreicht werden kann. Dann erstellt er eine Termineinladung, in der der UNC-Pfad im Feld "PidLidReminderFileParameter" steht und sendet Sie an den Empfänger
  2. Opfer hat einfach Outlook gestartet
    Das lokale Outlook des Ziels bekommt die Mail und pflegt sich unter Vorbehalt im Kalender ein. Kurz darauf triggert die "Erinnerung" und Outlook greift ohne weitere Mithilfe des Anwenders auf den UNC-Pfad zu.
    Update: Es gibt mit CVE-2024-21413 Microsoft Outlook Remote Code Execution Vulnerability (https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2024-21413) wohl auch einen Exploit vom 13. Feb 2024, der dazu missbraucht werden kann. Eventuell gibt es auch neuere Lücken.
  3. Man in the Middle
    Der Angreifer reicht die Anfrage an Exchange weiter, wartet auf den NTLMv2-Nounce, gibt den dann zum Client der ihn mit seinem Kennwort-Hashwert verschlüsselt und an den SMB-Server gibt. Der reicht die Antwort an den Exchange weiter, der diese gegen den DC prüft, eine erfolgreiche Anmeldung protokolliert und dem angeblichen Client den erfolgt meldet.
  4. Der Angreifer greift auf das Postfach zu
    Der Client ist aber der Server des Angreifers, der mit dem NEt-NTLMv2-Hash nun weiter auf das Postfach zugreifen kann. Der eigentliche Anwender kann ein OK bekommt aber meist beendet der Angreifer die Verbindung einfach.

Es kommen hier mehrere Faktoren zusammen:

  • Outlook veraltet
    Microsoft hat im März 2023 zwar mehrere Anläufe gebraucht, um die Lücke CVE-2023-23397  zu fixen aber ein aktuelles Outlook solle hier nicht mehr auf dem Weg verwundbar sein. Es könnte zukünftig aber auch andere Programme geben, die sich genauso reinlegen lassen. Allerdings gibt es mit CVE-2024-21413 auch eine Outlook Lücke vom 13. Feb 2024
  • Zoneneinstellungen
    Normalerweise meldet sich ein Browser nur an "Intranet-Zonen" mit der "Windows Integrierten Authentifizierung (WIA)" an. Wenn der Outlook Bug oder andere Dienste das nicht beachten oder der Administrator die Zonen falsch eingestellt hat, dann ist die Lücke ebenfalls möglich.
  • Zugriff auf SMB/445
    Wenn der Angreifer extern ist, dann muss sich die Firma wirklich fragen lassen, warum die Firewall solche Verbindungen nicht unterbunden hat. Wobei ein Homeoffice-User mit SplitVPN oft solche Schutzmechanismen nicht hat. Das Risiko ist also durchaus real.
  • NTLM-Nutzung
    Seit Windows 2000 ist eine Anmeldung per Kerberos möglich und dennoch haben zu viele immer noch NTLM aktiv. Zumindest LM/NTLMv1 sollen Sie auf jeden Fall abschalten. Aber hier ist ja NTLMv2. Ein kompletter Verzicht auf NTLM ist im LAN oft nicht möglich. Aber aus dem Internet könnte dies schon blockiert werden. Allerdings wird dies nicht als möglich Gegenmaßnahme beschrieben.
  • Exchange und NTLM
    Hier greift Microsoft mittels Exchange Extended Protection ein, um den Missbrauch über den Net-NTMLv2.Hash zu unterbinden. Die Anmeldung über das MITM-System kann mit Extended Protection nicht funktionieren, wenn es keinen durchgängigen TLS und Authentication-Kanal mit dem gleichen "Channel Binding Token (CBT)" gibt. Eine andere Option wäre natürlich den kompletten Verzicht auf NTLM und z.B. von extern die Nutzung von Hybrid Modern Authentication (HMA).

All das ist aber nur ein Vorgeschmack, denn hier hat es Outlook und Exchange aus dem Internet erwischt aber Angreifer können auch intern stehen und auch andere Server und Dienste nutzen natürlich NTLMv2. Ich kann aber erst einmal keine spezielle Lücke von Exchange erkennen, sondern eher eine alte Lücke von Outlook und natürlich die NTLM-Nutzung, die ohne Extended Protection keinen Schutz gegen MITM gewährt.

Ein zweiter Vektor ist natürlich der klassische "Main in the Middle"-Angriff, bei der die Verbindung zwischen Client und Server über einen Proxy aufgebrochen wird.
Der ist natürlich schwerer durchzuführen als eine Termineinladung an einen Anwender.

Auf Dauer wird an "Extended Protection" kein Weg vorbei führen, da nur er sicher die "Man in the Middle"-Angriff auf NTLM unterbinden können. Schade, dass diese Einstellung nicht by Default aktiv ist

Outlook scheint auch ein recht "dankbarer" Client für Angriffe zu sein.

Erkennen

Wenn Sie gerade gelesen haben, was alles schief gelaufen ist, dann wissen Sie eigentlich selbst, an welchen Stellen Sie nachschauen können. Sie können die Liste auch gerne als Fingerzeig für Verbesserungen ihrer Umgebung nutzen

Instanz Beschreibung OK

Netzwerk Firewall

Wenn der Angreifer extern ist und sie natürlich eine Firewall haben, dann können Sie dort nach ausgehenden Verbindungen auf Pot 445/TCP schauen. Dies sind SMB-Zugriffe, die Sie sowieso erst einmal unterbinden sollten.

Es kann aber immer passieren, dass Anwender Mails mit URLS auf externe Pfade bekommen oder sich im Explorer verzichten. Das muss erst einmal
nicht heißen. Kritisch wird es, wenn die Verbindung zustande gekommen ist. Dann sollten Sie anhand des Users oder der Source-IP den Benutzer ermitteln und prüfen, welche Zugriffe es auf sein Postfach gibt.

Dies ist natürlich keine Lösung für die Homeoffice-User

NetFlow/SFlow/IPFix

Wenn wir schon beim Netzwerk sind, könnten Sie prüfen, ob sie eine Verkehrsflusserfassung haben, d.h. in der protokolliert wird, welche Source-IP:Port/Destination-IP:Port-Paarungen es gibt und hier Auffälligkeiten zu erkennen sind, z.B. öffentlichen IP-Adressen

Desktop Firewall / Eventlog

Auch die Windows Desktop Firewall kann Verbindungen ins Eventlog und in Textdateien protokollieren. Leider haben die meisten Firmen solche Protokolle nicht aktiv oder können diese nicht schnell einsammeln.

Insofern ist dieser Weg nur sinnvoll, wenn Sie einen Verdacht haben und lokal nachvollziehen wollen, was passiert sein könnte

Desktop SIEM

Bei solchen Fällen schlägt natürlich die Zeit einer Endpoint Protection Lösung wie Windows Defender oder andere Produkte, die mehr als nur etwas Virenscanner sind, sondern auch den Start und das Verhalten von Applikationen und Programme und deren Kommunikationsbeziehungen erfassen und an eine zentrale Stelle berichten. Hier können Sie dann per KQL-Abfrage z.B. alle Einträge suchen, bei denen Outlook eine SMB-Verbindung an öffentliche IP-Adressen gestartet hat. Eine Abfrage könnte dann so aussehen:

DeviceProcessEvents
| where FileName=="OUTLOOK.EXE"
| join DeviceNetworkEvents on DeviceId
| where RemoteIPType=="Public"
| where RemotePort == 445
| where ActionType1=="ConnectionSuccess"
| project Timestamp, DeviceName, AccountUpn, RemoteIP

Dies sollte eine Liste aller Geräte und User mit Zeitstempel und angesprochene IP-Adresse liefern. Allerdings sind auch das nur Anhaltspunkte. Mit der passenden Lösung funktioniert dies auch im Homeoffice.

Exchange Mails

Aktuell ist der Startpunkt die Outlook-Lücke CVE-2023-23397 mit einer Termineinladung und einer URL in PidLidReminderFileParameter, die Outlook ungeachtet der Zoneneinstellungen und ohne Mithilfe des Benutzers anspricht. Solche Mails lassen sich im Exchange Server finden und beseitigen. Ein entsprechendes Skript hat Microsoft bereitgestellt

 

Exchange Logs

Kniffliger ist die Analyse von Exchange Logs über die IISLogs oder Anmeldelogs o.ä.. da auch reguläre Benutzer ja kontinnuierlich arbeiten. Wenn ihre IISlLOGs aber den angemeldeten Benutzer zeigen, dann kann eine Analyse nach den IP-Adressen Hinweise geben. Die meisten Anwender sind nur auf wenigen Geräten an einem Ort aktiv

 

Auch wenn Sie heute noch nicht alle Punkte abdecken können, so könnte der CVE-2024-21410 als auch der alte CVE-2023-23397 ihnen aufzeigen, wo Sie ihre Überwachung noch verbessern können.

Risiko

Damit stellt sich nun natürlich die Frage, wie groß das Risiko ist und ob Sie als Administrator sofort reagieren müssen.

Die folgenden Annahmen könne falsch sein, aber leider liefern weder BSI noch Microsoft hier Details über den Schweregrad.

Nach einer Einschätzung besteht das Risiko darin, dass ein Angreifer ohne aktive mithilfe des Anwenders einen Zugriff auf dessen Postfach bekommt und damit dann nicht nur die Mails, Termine, Kontakte etc des Benutzers lesen kann, sondern auch Mails in dessen Namen senden und damit Folgeschäden anrichten kann. Ein Angreifer kann also hoffen, dass er Zugriff auf solche Konten erhält, um darüber Geld-Transaktionen zu steuern oder Berechtigungen auszuweiten, z.B. durch Phishing gegen andere Benutzer oder Prozesse.

Dazu muss ein Angreifer aber einen Net-NTLMv2-Hash von einem Benutzer abgreifen. Leider können Sie als Administrator nie 100% sicher sein, dass wirklich alle Anwender überall die aktuellste Outlook-Version nutzen, und damit gegen einen Angriff gesichert sind, welcher auf die CVE-2023-23397-Lücke aufsetzt. Gegen eine externe Mail könnte ein Spamfilter helfen aber dann gibt es immer noch interne Absender, z.B. andere abgephishte legitime Konten oder auch eine Mail an das "private" Postfach eines Anwenders, welches dieser parallel zum Firmenpostfach in Outlook eingebunden hat.

Zudem muss der Angreifer dann mit dem Net-NTLMv2-Hash ihren Exchange Server über einen Weg erreichen können, über den eine Anmeldung per NTLM möglich ist. Das ist bei vielen Firmen allerdings der Regelfall, da die interessanten virtuellen Verzeichnisse /EWS, /MAPI etc. die Windows Authentifizierung natürlich aktiv haben. Ein Zugriff auf das Postfach per Browser über OWA mit formularbasierte Anmeldung scheint kein Risiko darzustellen. Denkbar ist das alles und das Risiko ist nicht null.

Aber dann gibt es noch einen zweiten Aspekt, dass die öffentlichen Aussagen nur eine Teilinformation liefern. Da reicht schon ein Blick auf den Titel:

Ein "Elevation of Privilege Vulnerability" klingt alarmierend und es könnte ja mehr sein, also nur der Zugriff auf ein Postfach mit einem abgephishten Net-NTLMv2-Hash. Dem widerspricht aber die Lösung durch Aktivierung von "Extended Protection". Gäbe es eine Lücke in Exchange, dann müsste ich auch Angst davor haben, dass ein legitimer Benutzer mit gültigen Anmeldedaten auf einen per "Extended Protection" abgesicherten Exchange Server zugreift. Da der Fix ja auch bei Exchange 2019 CU13 und Exchange 2016 CU23 wirkt, kann in Exchange 2019 CU14 ja kein Fix im Code selbst dazugekommen sein.

Auch die Meldung des BSI spricht von einer "Zero-Day-Schwachstelle". Die Outlook-Lücke ist aber schon vor fast einem Jahr bekannt und gefixt worden.

Der Missbrauch mit Net-NTLMv2-Hashes gibt es ja schon viele Jahre und konnte seit August 2022 abgeschaltet werden. Ich konnte schon immer als Angreifer auch ohne Outlook Lücke eine Mail an mein Ziel senden, in der ein UNC-Pfad zu meinem präparierten Server enthalten ist. Ich musste halt nur drauf hoffen, dass der Anwender auch drauf klickt und per SMB eine Anmeldung versucht und die IE, Internetzonen und Outlook eine Anmeldung per SMB erlauben.

Da passt einiges nicht zusammen. Die Warnungen hätten schon im Aug 2022 aber spätestens im März 2023 generiert werden können.

Auch bei Microsoft steht nicht mehr:

An attacker could target an NTLM client such as Outlook with an NTLM credentials-leaking type vulnerability. The leaked credentials can then be relayed against the Exchange server to gain privileges as the victim client and to perform operations on the Exchange server on the victim's behalf.
An attacker who successfully exploited this vulnerability could relay a user's leaked Net-NTLMv2 hash against a vulnerable Exchange Server and authenticate as the user
Quelle: https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-21410

Interessant ist, dass die eigentliche Lücke schon länger bekannt war:

Why is this CVE listed as being exploited?
Microsoft was aware of targeted NTLM relay attacks back in 2023. These were documented by an Outlook CVE (CVE-2023-23397 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23397)
Quelle: https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-21410

Absicherung

Im CVE-2023-23397 (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23397) wird als Lösung empfohlen, die Benutzer in "Protected Groups" zu addieren, damit sie kein NTLM mehr nutzen und auf der Firewall ausgehende Verbindungen auf 445/TCP zu unterbinden. Über den Weg würde dann wohl der NTLMv2Hash ausgeleitet. Eventuell indem ich eine Mail mit einem Link an \\badserver.msxfaq.de\share sende und ihr Client so eine Anmeldung an dem Server versucht. Wie genau der Angriff gegen z.B. Outlook erfolgt, ist nicht weiter ausgeführt. Das könnte eine Malware auf dem Client sein, die die Verbindungen mitlauscht oder ein klassischer Man in the Middle-Angriff sein. Im lokalen LAN könnte es auch möglich sein, dass ein Mitarbeiter den NTLM-Client eines anderen Mitarbeiters irgendwie anzapft.

Exchange ist hier natürlich ein "dankbarer" Kunde, da viele Firmen ihre Exchange Server für "OWA", "ActiveSync" und EWS aus dem Internet erreichbar machen. Nicht alle Firmen haben davor eine Web Application Firewall oder eine PreAuthentication, die den Zugriff von extern über einen gekaperten NTLMv2-Hash unterbinden. Aber auch interne Angriffe sind denkbar, wenn der Angreifer schon über einen VPN-Zugang oder andere Hintertür im Netzwerk auf eine passende Lücke wartet.

Interessant finde ich aber die Abhilfe, die nicht auf der Installation eines Updates basiert sondern ausschließlich auf einer Änderung der Konfiguration hinsichtlich Exchange Extended Protection, denn laut CVE gilt

  • Exchange 2019 CU14 kann abgesichert werden
    Es reicht aber nicht die Installation des CU14 alleine sondern es muss auch Exchange Extended Protection aktiviert werden. Das macht das CU14 aber standardmäßig alleine
  • Exchange 2019 CU13 kann auch abgesichert werden
    Das ist interessant, denn das bedeutet ja, dass in CU14 kein neuerer Code dahingehend enthalten ist. Auch hier reicht die Aktivierung von Exchange Extended Protection als Lösung aus
  • Exchange 2016 CU23 kann abgesichert werden
    Interessanterweise gibt es aber kein Update zur Installation, d.h. die Lösung ist schon im Code von damals am 20. April 2022 enthalten
    https://www.microsoft.com/en-us/download/details.aspx?id=104132

Ich habe nun keine Informationen über noch ältere Versionsstände von Exchange 2016/2019 oder gar Exchange 2013. Es kann durchaus sein, dass auch dort schon die Konfiguration von Exchange Extended Protection als Absicherung ausreichen könnte. Für Exchange 2019 führt die Microsoft sogar auf:

If I already ran the script that enables NTLM credentials Relay Protections am I protected from this vulnerability?
Yes. If, for example, you are running Exchange Server 2019 CU13 or earlier and you have previously run the script then you are protected from this vulnerability, however, Microsoft strongly suggests installing the latest cumulative update.
Quelle: https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-21410

Wenn Sie eine der drei unterstützten Exchange Versionen betreiben, dann sollten Sie zügig die Aktivierung von Exchange Extended Protection umsetzen, um geschützt zu sein.

Auch wenn es weder das BSI noch Microsoft so sagt, dann könnte aufgrund der Nutzung von NTLMv2-Hashes auch die Blockade von NTLM als Authentifizierungsverfahren z.B. auf der Firewall oder dem Reverse Proxy eine mögliche Option sein. Für den Zugriff per OWA können Sie mit Form-Based-Authentication arbeiten aber ActiveSync und EWS sind natürlich native erreichbar.

Extended Protection einfach einschalten?

"Extended Protection" ist eine Funktion des IIS und nicht nur für Exchange relevant. Details finden Sie dazu auf IIS Extended Protection

Für die Aktivierung von "Extended Protection" auf einem Exchange Server habe ich auf Exchange Extended Protection eine eigene Seite geschrieben.

Dennoch sollte es für viele, insbesondere kleine Firmen, gar nicht schwer sein, Extended Protection einzuschalten. Der vermutlich einfachste Weg ist, es einfach einmal einzuschalten und wenn es keine Probleme gibt, dann sind sie schon fertig. Wenn Sie aber extern und intern unterschiedliche Zertifikate nutzen, dann geht die Aktivierung nicht so einfach, denn Sie müssten dann Zertifikate kopieren, z.B. das externe Zertifikat auch auf die internen Server.

Wenn Sie EP aktiviert haben und die Konfiguration nicht passt, dann bekommt die Anwender mit z.B. Outlook immer wieder eine Kennwortbox, die selbst bei der Eingabe korrekter Anmeldedaten nicht funktioniert.

Fakten, Fakten, Fakten

Hier noch mal das wichtigste an einer Stelle

  • Worum geht es?
    - Klassische MITM Attacke
    - Angreifer sendet eine Mail an ZielUser, damit er einen Server des Angreifers anspricht, der NTLM-Anmeldung erzwingt.
    - Outlook (oder anderer Client) muss den Server erreichen (Firewall?) und die IE-Zoneneinstellungen werden ignoriert
    - Zieluser macht also NTLM-Auth über Angreifer mit Exchange und Angreifer hat dann das AuthToken.
    - Ergebnis: Angreifer hat die Rechte des Users (Mail lesen, schreiben, Regeln etc.) aber er ist kein Admin.
    - Zumindest wenn der Admin nicht seine Mails als Admin liest (Nur User haben Mailboxen, Admin haben keine Mailbox!
  • - EP verhindert den NTLM-Handshake, weil der Client das bei ihm angekommen Zertifikat mit einrechnet.
    - Exchange mit EP prüft den Request mit seinem eigenen Zertifikat.
    -> Wenn Client ein andere Zertifikat bekommt, als der Server nutzt, dann kommt NTLM nicht zum Erfolg
    - Outlook Client fragt dann immer wieder nach Username/Kennwort
  • Warum Exchange
    - Exchange hat keine Lücke, die CVE-Meldung ist IMHO irreführend
    - Exchange 2019 CU14 aktiviert Extended Protection (EP) by Default.
    - Exchange 2019 CU13. kann man manuell aktivieren, d.h. man MUSS nicht CU14 installieren, aber sollte man aufgrund anderer Fixe
    - EX2016CU23 und sogar EX2013 mit dem Aug2022 SU können auch EP und sind dann geschützt
  • EP schützt nur "Windows IntegratedAuth", also kein BasicAuth, Formbased, Bearer etc. Da ist ein MITM immer ein Problem-> MFA hilft
  • Daher auch kein Problem mit "OWA und Formbased" oder ActiveSync mit BasicAuth
  • EP gibt es auch für andere Protokolle LDAPSigning, SMB-Sealing, RPC Signing
  • EP ist ein Feature seit IIS 7.5 (Windows 2008!!) und denkt man an ADFS, SharePoint, WSUS, und andere IIS-basierte Dienste
  • alle sind hinsichtlich NTLM-MITM-Attacken verletzlich, wenn EP nicht aktiv.
  • Seit viele Jahren wird auch immer wieder auf EP hingewiesen, aber viele Admins ignorieren es
  • Das Exchange Team hat jetzt mal angefangen und es per Default aktiviert. Weil Outlook/Exchange natürlich ein beliebtes Ziel sind.
  • Vielleicht sehen wir bald noch andere Hersteller und Produkte, die EP anraten und irgendwann einschalten
  • SSL-Inspection/Bridging nur mit identischen Zertifikaten..

Offene Fragen

Aus meiner Sicht gibt es noch einige Dinge, die ich in Verbindung mit Extended Protection und der "Lücke" CVE-2024-21410 noch nicht ganz ausgearbeitet haben.

  • Wo ist die Exchange "Lücke"?
    Ich habe es so verstanden, dass ein Angreifer von einem legitimierten Benutzer einen NTLMv2-Hash abgreifen kann. Über Exchange würde ich dann erst einmal erwarten, dass er das Postfach des Benutzers öffnen, lesen und Mails senden kann. Das ist an sich schon unschön aber keine Lücke in Exchange. Das passiert auch bei per Phishing gekaperten Konten. "Aktionen auf dem Server" ausführen könnte dann aber auch ein legitimer Anwender. Ein interner Anwender könnte mit den Daten auch SMB und andere interne Schnittstelle ansprechen. Oder ist SMB und RPC nicht auch mit "abgefischten NTLM-Hashes" angreifbar?
  • Grundregel: Administratoren haben kein Postfach nutzen kein Outlook, Anwender mit Outlook haben keine Administrator-Rechte
    Wenn ich diese Regel einhalte, dann kann ein Angreifer ja wohl kaum einen NTLM-Hash mit höheren Rechten erhalten und damit Unfug anstellen.
  • Lücke im Exchange Webserver Code?
    Die Lücke kann allein durch Aktivieren von Exchange Extended Protection verhindern werden. Das gilt auch für ältere Versionen wie Exchange 2016CU23 und Exchange 2019CU13, die schon lange verfügbar sind. Es gibt also keinen "neuen" Code in Exchange 2019 CU14, der eine Lücke schließt, außer die Aktivierung von Exchange Extended Protection.
  • Betrifft es auch andere IIS-basierten Produkte?
    Extended Protection ist nicht nur eine Einstellung in Exchange sondern erst einmal im IIS, der damit sich Verbindung zusätzlich absichert. Ich frage mich dann natürlich, was mit anderen Produkten ist, die auch auf dem IIS aufsetzen, z.B. SharePoint, WSUS etc. Muss bzw. sollte ich da auch Extended Protection aktivieren? Ich würde hier ein JA antworten, d.. EP ist für alle Server, die IIS mit Windows Integrierter Authentifizierung nutzen.
  • "Form-Based Auth/Bearer/Kerberos" ist nicht verletzlich
    Wenn Extended Protection so wichtig ist um "Man in the Middle" und SSL aufbrechen zu verhindern, warum sind dann auch viele andere Dienste alle noch ohne den Schutz erreichbar? Ich mache das einfach daran fest, dass ich z.B. weiter mit Fiddler als Analyseproxy die Verbindung aufbrechen kann. Oder funktioniert es einfach gar nicht bei "Form Based"? Meinen Exchange 2019CU14 mit aktiviert Extended Protection geschützten Server kann ich über den Azure AD Application Proxy weiterhin problemlos erreichen und auch Verbindungen zu "login.microsoftonline.com" sind weiter analysierbar.
  • Reicht es nicht, NTLM auf HTTP zu blockieren?
    Eine Gegenmaßnahme ist es, die Benutzer in "Protected Group" aufzunehmen, damit sich diese nicht mehr per NTLM anmelden können. Könnte ich dann nicht einfach in der IIS-Konfiguration die Anmeldung per NTLM und Negotiate:NTLM abschalten? Das geht leider nicht da MRSProxy und einige andere Dienste NTLM von extern brauchen
  • Warum ein "Exchange Escalation Alarm", wo doch Outlook oder IIS die Ursache ist?
    Sicher macht es viel mehr her, wenn man Exchange an den Pranger stellen kann, aber anscheinend braucht man einen Net-NTLMv2-Hash, den ein Angreifer durch eine Outlook Lücke von März 2023 (CVE-2023-23397  und CVE-2023-29324) einfach erhalten kann. Ich kann keinen "Fehler" in Exchange erkennen.
  • Kein Beispiel für einen möglichen Missbrauch
    In den Artikeln steht, dass ein Angreifer (mit dem Net-NTLMv2-Hash) auf dem Exchange Server oder anderen Servern "als Benutzer" agieren kann. Das trifft doch auch für jeden legitimen Anwender zu, dessen Kennwort abgephished wurde. Da muss zwar der Anwender dann mithelfen aber das passiert täglich.
  • EEMS - Exchange Emergency Mitigation Service
    Gibt es wirklich keine Option, einen temporäre Absicherung über diesen "Hot Fix Service" von Microsoft zu verteilen? Vielleicht sollte Microsoft nicht immer nur "optional Updates" wie Azure ARC auf Server verteilen sondern auch z.B. den Exchange HealthChecker ans "TrayApp" auf jedem Exchange Server installieren, der prominent auf Fehler und Unstimmigkeiten hinweist.

Sobald ich Antworten habe, werde ich diese hier aktualisieren.

Einschätzung

Wer gehofft hat, dass ich hier ein "alles nicht so schlimm" schreibe, ist vielleicht enttäuscht. Aber ich bin wirklich nicht sicher, ob der Alarm und insbesondere der CVE-2024-21410 nicht anders geschrieben werden sollte. Wenn ein Exchange Server seine Dienste per NTLM erreichbar macht, was bei ActiveSync und EWS leider der Standard ist, dann kann ein Angreifer aber auch legitimer User mit einem Net-NTLMv2-Hash die Dienste mit seinen Rechten und Namen nutzen. Das ist schlecht, wenn es ein Postfach mit sensiblen Daten ist.

Ich sehe aber keine Hinweise, um damit von Exchange auf andere Server zu springen oder sich erhöhte Rechte zu besorgen oder wie beim Hafnium Exploit gar anonym etwas auslösen zu können. Kunden, die ihren Exchange Server hinter eine Firewall /Web Application Proxy mit PreAuthentication betreiben oder NTLM unterbunden haben, sollten eigentlich kein Problem haben und wenn ich EWS von extern nur für den Hybrid Mode durch Microsoft Adressen zulasse, dann ist das Risiko weiter reduziert. Zudem muss der Angreifer ja erst mal ein ein Net-NTLMv2-Hash kommen, was durch eine Lücke in Outlook von März 2023 möglich war, aber heute auch ein "ungepatchtes" Outlook und ausgehende Verbindungen auf 445/TCP erfordert. Das ist im Homeoffice möglich aber in Firmen sollte eine Firewall das verhindern. Insofern gibt es ein Risiko aber die Schwere müssen Sie selbst abschätzen.

<schwurblermode>
Am Anfand der Covid19-Pandemie war die Datenlage schon ungenau und viele Entscheidungen stellten sich im Nachhinein als überzogen oder nicht weitreichend genug heraus.
 Hier gibt es sicher Menschen, welche die gesamte Tragweite des Problems kennen aber nur wenig darüber schreiben wollen oder dürfen.
</schwurblermode>

Daher bleibt die Empfehlung unverändert. Installieren Sie Ex2019CU14 (aktiviert auch EP) oder aktivieren Sie manuell Exchange Extended Protection auf Ex2019CU13/Ex2016CU23. Sollte danach der Clientzugriff nicht mehr möglich sein, dann können Sie es temporär deaktivieren oder investieren ihre darauf, ihre Proxy-Kette, Hybrid Agent, Public Folder zu entsprechend anzupassen.

Weitere Links