CVE-2024-21410: Exchange Schwachstelle wird aktiv ausgenutzt

by

Die kritische Schwachstelle CVE-2024-21410 in Exchange Server, welche am 13.02.2024 öffentlich gemacht wurde, wird jetzt aktiv ausgenutzt. Die Schwachstelle CVE-2024-21410 ermöglicht Angreifern eine NTLM Relay Attacke (Pass the Hash). In diesem Fall können Angreifer einen Client wie Outlook dazu bringen sich gegenüber einen bösartigen Relay anzumelden um so an die NTLM Anmeldeinformationen zu kommen. Die NTLM Anmeldeinformationen können dann mittels Pass the Hash an den Exchange Server weitergeleitet werden. Angreifer können damit die Identität und die Rechte des Benutzers auf dem Exchange Server übernehmen.

Vor der Schwachstelle CVE-2024-21410 schützt das aktivieren der Extended Protection. Das kürzlich veröffentlichte Cumulative Update 14 für Exchange Server 2019 aktiviert Extended Protection in der Standardeinstellung bei der Installation. Wichtig zu wissen ist aber, dass das CU14 für Exchange 2019 nicht die Schwachstelle an sich schließt. Nur die Aktivierung der Extended Protection verhindert das Ausnutzen der Shcwachstelle. Wenn bei der Installation des CU14 das Setup mit den Schaltern „/DoNotEnableEP“ oder „/DoNotEnableEP_FEEWS“ ausgeführt wurde, ist CVE-2024-21410 weiterhin ausnutzbar. Auch wenn nachträglich die Extended Protection wieder deaktiviert wurde, sollte Extended Protection unbedingt wieder aktiviert werden.

Der größte Hinderungsgrund für das Aktivieren der Extended Protection, dürfte die Anforderung an das SSL Zertifikat sein. Auf allen Geräten wie Loadbalancern und Web Application Firewalls, welche SSL Inspection oder SSL Bridging durchführen, muss das gleiche Zertifikat verwendet werden. Hier muss man sich also Gedanken machen, wie man das gleiche Zertifikat auf allen relevanten Geräten installieren und erneuern kann. SSL Offloading wird mit Extended Protection nicht unterstützt.

Mit dem Exchange Health Checker lässt sich prüfen, ob die Extended Protection aktiviert ist.

Auch Exchange Server 2016 ist anfällig für CVE-2024-21410, auch hier hilft das Aktivieren der Extended Protection. Für Exchange 2016 die Extended Protection über ein PowerShell Script aktiviert werden. Ein Sicherheitsupdate welches die Schwachstelle auch ohne das Aktivieren der Extended Protection schließt, wurde bisher nicht veröffentlicht.

CVE-2024-21410

56 thoughts on “CVE-2024-21410: Exchange Schwachstelle wird aktiv ausgenutzt”

  1. Hallo liebe Exchange-Admins… Ich bin verzweifelt….

    Am Wochenende habe ich bei einem meiner Letzen Kunden das CU 14 auf dem Exchange 2019 installiert – alles ohne Probleme..

    Dann aber der Test im Outlook – keine Verbindung – unendliche Passwortabfrage…

    Das Zertifikat ist von LetsEncrypt, ich habe keine Loadbalancer oder UTMs davor – die Zertifikate sollten also schön sein.
    LmCompatibilityLevel Settings: 3 sieht auch gut aus… SchUseStrongCrypto ist schön…
    Das Problem ist: ich kann mich nicht am https://autodiscover.firma.de/autodiscover/autodiscover.xml anmelden – er fragt unendlich oft nach dem Passwort…
    Im IIS-Log sehe ich:
    Zeile 3368: 2024-03-19 07:46:33 192.168.115.5 GET /Autodiscover/Autodiscover.xml &CorrelationID=;&cafeReqId=2dd02461-73e9-4ebc-8cff-9a33ddb0b5ef; 443 – 80.meine.IP.243 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/122.0.0.0+Safari/537.36 – 401 0 0 68
    Auch die Anfragen von internen Outlooks bekommen eine 401…

    Nun dachte ich, bin ich clever: spiele das Backup der System- und Install-Partition zurück.. diese hatte das CU13 ohne Extended Protection.. aber auch da – das gleiche Problem…

    Eine neue Installation eines neuen zusätzlichen Servers im CU14 zeigt das gleiche Verhalten…

    Hat jemand eine Idee was man da noch machen kann ? Viele Grüße aus Berlin
    Jens

    Reply

  2. Bei mir funktioniert seit cu14 und aktiver EP Mapi nicht mehr sprich Outlook 2016 verbindet sich nicht bzw. Erfordert ein Passwort. Wenn ich im IIS für mapi EP abschalte tut alles wie gewohnt. Jemand eine Idee? Liegt dies evtl. an der Hybridstellung?

    Reply

  3. Vielleicht einfach mal ein paar Stichpunkte
    – 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
    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
    – 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
    – Nur 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.
    – Einzige Forderung: SSL-Inspection/Bridging nur mit identischen Zertifikaten..
    Soweit mal eine Kurzform. Ansonsten:
    https://www.msxfaq.de/exchange/update/cve-2024-21410.htm (mit Video/Audio)
    https://www.msxfaq.de/windows/iis/iis_extended_protection.htm (wer es nur für den IIS braucht)
    https://www.msxfaq.de/windows/sicherheit/ntlm-anmeldung.htm

    Frank

    Reply

  4. ich habe die EP mittels des Scripts aktiviert, die Verbindung von Handys über ActiveSync funktioniert aber dennoch, trotzdem ich das Zertifikat (opnsense mit haproxy und LE) noch nicht im Exchange (2016) eingerichtet habe. Das Script meldete Erfolg und der Healthcheck besagte auch, das EP aktiviert sei. Bezieht sich das nur auf Outlook, dass man das Zertifikat auf RProxy und Exchange gleich haben muß?

    VG
    thoenny

    Reply

    • Ja, hatte meine Analyse damals auch so ergeben. Nur Outlook bringt extern per OA einen permanenten Passwort Prompt, wenn das Zertifikat nicht gleich ist.

      Reply

      • Info, heute so aktiviert, intern Zertifikat von Unternehmens-CA und auf Reverse Proxy öffentliches Zertifikat. EAS fkt. weiterhin, da /RPC nach extern nicht veröffentlicht, gehen hier 2 Zertifikate.

        Für mich ist das größte Fragezeichen, wie verhält es sich dem Autodiscover Verzeichnis, muss dort bei Veröffentlichung das Zertifikat gleich sein?

        Meine bisherigen Erkenntnisse (bitte um Korrektur wenn ihr anderer Meinung seid). Alles unter der Annahme EP aktiv und Reverse Proxy im Einsatz:

        OWA extern – unterschiedliche Zertifikate mgl. laut Test
        EAS extern – unterschiedliche Zertifikate mgl. laut Test
        RPC/MAPI – selbes Zertifikat erforderlich
        OAB – unklar, aber sehe ich wie RPC/MAPI
        EWS – unklar, aber sehe ich wie RPC/MAPI

        Autodiscover – unklar

        Reply

        • Du hast /mapi vergessen. Und das benötigt wie /rpc identische Zertifikate. /oab vermutlich auch, aber das wär auch egal, weil oab für rpc und/oder mapi gebraucht wird. ;)

  5. Guten Tag,
    ich müsste bei einem alten Exchange 2013 CU23 Extendet Protection aktivieren.  Leider werden in dieser Umgebung auch öffentliche Ordner genutzt.  Hat jemand zufällig Erfahrung, wie man EP aktiviert und die PF´s  außen vor lässt? 
    Vielen Dank im Voraus für jeden Hinweis. 

    Reply

  6. Frage in die Runde. Ist die Lücke auch ausnutzbar wenn eine Web Application Firewall wie eine SOPHOS UTM dazwischengeschaltet ist?

    Reply

  7. Schönen guten Morgen,

    unsere Exchange Server 2016 können lediglich eine Verbindung zu Microsoft 365 aufbauen, der Rest ist von der Firewall geblockt. Sprich die Rechner kommen sonst nirgends ins internet. Intern sind dort noch einige Mailboxen und die können von den Clients erreicht werden.

    Sind wir auch stark gefährdert? Wir werden die Exchange Protection aktivieren es wird nur einige Tage dauern, da es bei uns eine externe Firma macht.

    Grüße

    Reply

    • Das müsst Ihr einschätzen. Es könnte ja auch ein gehackter PC/etc. im internen Netz als „Man-in-the-middle“ genutzt werden. Wie wahrscheinlich das ist, müßt Ihr beurteilen.

      Reply

  8. Wir haben mittlerweile einige Konten die sich nicht mehr verbinden können. Es kommt immer wieder die Windows Passwortabfrage. Selbst ein neues Outlook Profil hilft nicht. Was mir aufgefallen ist, das beim neuen Profil selbst bei Eingabe eines falschen Passwortes der Assistent ohne Fehler durchläuft.
    Kann das jemand bestätigen? In einem Heise Kommentar würde ebenfalls ähnliches Verhalten kommentiert.

    Reply

  9. Note:

    After the initial release, we’ve updated Default Website/OAB to be Accept/Allow instead of Required and Default Website/PowerShell to be Off instead of Required. The change to Default Website/OAB is because of Outlook for Mac clients not being able to download the OAB any longer with the Required setting. The change to Default Website/PowerShell is because the Exchange Server default configuration doesn’t allow connections using NTLM authentication to PowerShell Front-End virtual directory and therefore, Extended Protection is not applicable.

    Making modifications to the Default Website/PowerShell virtual directory is not supported unless explicitly adviced by Microsoft Customer Service and Support (CSS).

    https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-extended-protection?view=exchserver-2019#enabling-extended-protection

    Habe die gleiche rote Meldung. Aber soll ich nun „Default Web Site/PowerShell “ anpassen oder nicht? Wenn ja, wie?

    Reply

      • Habs bislang nicht gefixed bekommen, bei reddit gibts auch was zu.
        Link bekomm ich leider nicht reinkopiert.

        Müsstest mal in Netz suchen:
        Health checker displays the following message in red „Default Web Site/Poweshell has authentication set, which is unsupported“

        Reply

        • Lade dir die aktuelle Version des EP-Scrips herunter und lass es noch einmal laufen.
          Die Einstellung, die angemeckert wird, wurde von einer alten Version des Scripts so gesetzt.
          Das Script hat Microsoft überarbeitet, weil diese alte Einstellung Probleme machen kann.

  10. Guten Morgen!

    Bin auf EX2016 und habe mich aufgrund des Artikels noch mal vergewissern wollen, dass ich EP aktiviert habe.
    „.\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection“ wirft mir in der Zeile „Powershell“ bei „Value“ den Wert „Require“ und bei „SupportedValue“ den Wert „“None“ aus. Die Beiden Werte sollen aber ja eigentlich identisch sein, ist bei allen anderen ach der Fall…
    Der Healthchecker melden EP als aktiviert. EP hatte ich schon vor einiger Zeit mit einem älteren als dem aktuellen Script aktiviert (weil weiter oben von versch. Script-Versionen die Rede ist).
    Ist das mit den unterscheidlichen Werten bei noch jemandem so?

    TJ

    Reply

    • Ja, das hatte ich bei uns auch. Es gab irgendwann mal eine Änderung an dem Skript von Microsoft. Da haben die an Verzeichnissen, die angeblich nicht angreifbar sind, die Werte wieder reduziert. Das kannst du entweder manuell anpassen, oder du lässt die aktuellste Version von dem Skript noch mal drüber laufen, das ändert die Werte dann passend.
      Ich hab die Variante mit dem Skript gemacht, war im laufenden Betrieb kein Problem, es musste auch nichts neu gestartet werden und es wurden auch keine Verbindungen unterbrochen.

      Reply

  11. Könnte man sich nicht gegen solche NTLM-Attacken schützen, indem man einfach z.B. den Exchange auf Kerberos only umstellt?
    Hier läuft die Kommunikation zwischen Outlook und Exchange schon sehr lange mit Kerberos.
    EP ist natürlich trotzdem aktiviert.
    NTLM ist in der Domäne weitgehend deaktiviert.

    Reply

  12. Ich würde EP gern nutzen, aber bei uns ist die Modern Hybrid Connection aktiv. Toll Microsoft, dass man uns hier etwas empfohlen hat, was nun zu einem Problem wird. Gibt es etwas zu beachten, wenn man die Classic Hybrid Connection nutzt? Vorteile, Nachteile, Fallstricke? Wir nutzen Hybrid aktuell nur für MS Teams Integration, sprich Kalendersynchronisation etc. Die bisher gefundenen Infos verwirren mich mehr, als dass sie mir nützen.

    Reply

  13. Kann ich im Exchange selbst weiterhin ein internes Zertifikat verwenden? Im Beitrag von franky heisst es „ Der größte Hinderungsgrund für das Aktivieren der Extended Protection, dürfte die Anforderung an das SSL Zertifikat sein. Auf allen Geräten wie Loadbalancern und Web Application Firewalls, welche SSL Inspection oder SSL Bridging durchführen, muss das gleiche Zertifikat verwendet werden“

    Heisst Reverse Proxy und LB je das selbe und auf dem EX selbst reicht ein internes only oder brauche ich dort exakt das selbe?

    Reply

    • Du brauchst auf dem Exchange exakt dasselbe wie auf dem Reverse Proxy. Nur das backend Zertifikat darf weiterhin das selfsigned cert sein.

      Reply

  14. Wir mussten nach Installation auf CU14 gestern die EP deaktivieren, da wir sonst überhaupt keinen Zugriff mehr hatten. Sowohl OWA als auch ECP. Da ging nichts. Als wenn keine Authentifizierung mehr stattgefunden hätte im Hintergrund.
    Ist natürlich jetzt super, dass es benötigt wird…

    Reply

    • Es wird seit August 2023 „benötigt“. Jetzt wirds halt nur kritischer. Wer also immer bis zuletzt wartet, muss jetzt das in kurzer Zeit tun, was er 6 Monate aufgeschoben hat.
      Hast du die ganzen Infos zu EP gelesen? Gerade was das Thema SSL Offloading/Bridging angeht aber auch Endpoint mit SSL Inspection und NTLMv1 usw.?

      Reply

    • Servus,
      das selbe Problem hatten wir auch.
      Konnte es jedoch lösen.
      Hier war für das Backend die Bindung im IIS für den Port 444 auf die IP des Exchange Servers gesetzt. Nach der Änderung auf * und einen IISReset ging die Anmeldung ohne Probleme.
      Wäre nur ne Idee.

      Grüße aus Bayern

      Reply

      • Sesra? Ich bin seit ü20 Stunden, habe mir alle Fingernägel abgeknabbert, 3x das Höschen wechseln müssen und habe 2x den kompletten Server restored…… weil ich genau das gleiche Problem HABE ähhhh HATTE. Ich danke dir sooooooooo sehr! Bei mir genau das gleiche Problem nachdem ich die Bindung im IIS Port 444 auf (nicht gewählt) gesetzt habe -> IIS Neustart -> ES GEHT WIEDER. Mir fällt ein Stein vom Herzen. Vielen Vielen Dank!!!!!

        Ich würde dir ja Rosen schicken :-D aber das is too much ;-) Danke!

        Reply

  15. Ist CU13 23NovSU eigentlich geschützt, sobald EP aktiviert ist? Es gab dort seit November keine Updates mehr, laut Unterstützungsmatrix von MS ist CU13 aber weiterhin supported.

    Reply

    • Ja ist es. CU14 hat nicht direkt was mit dem CVE zu tun, es aktiviert nur bei der Installation automatisch die Extended Protection, wenn man das nicht per Kommandozeile deaktiviert. Bis CU13 und bei Exchange 2016 muss man es halt manuell aktivieren, dann ist man geschützt. Wenn du das also schon aktiviert hast, ist alles gut. Zumindest nach bisherigem Kenntnisstand.

      Reply

  16. So ganz habe ich den Angriffsweg noch nicht verstanden..

    Beispiel:
    Outlook mit meinem Account verbindet sich mit einem falschen relay Server und dabei wird das Passwort geklaut..mit diesen Anmeldedaten wird sich dann am korrekten Mailserver angemeldet und erhält die Benutzer rechte von mir..kann dann wahrscheinlich Mails lesen, schreiben bzw Diebstahl..im schlimmsten Fall irgendwie malware oder backdoor ablegen?!

    Die Outlook Anmeldung kann dann wahrscheinlich in Kombi mit einem cves erfolgen? Der weg vom Outlook zum bösen relay ist mir noch nicht so klar

    Reply

      • Die Kalender Erinnerung mit dem Ton habe ich auch noch im Kopf und da musste glaube ich nicht mal was gemacht werden..

        Sprich man muss aber wahrscheinlich mehrere Lücken kombinieren…vorher waren es „nur“ Passwörter die weg waren und jetzt gibt es aber zusätzlich Zugriff auf den Exchange direkt wenn die hash geklaut wurden

        Reply

        • Sagen wir es so, einfach per Skript aktivieren und die Kunden müssen entweder ein öffentliches Zertifikat für intern kaufen oder auf Outlook Anywhere extern verzichten bzw. dann nur noch per VPN. Und ganz ehrlich, im 2100 Jahrhundert geht es leider um Sicherheit und nicht um Bequemlichkeit.

      • @sebastian

        Meinst du mit sperren von Outlook anywhere nimmt man etwas angriffsfläche raus? Schließlich kann sich dann Outlook nicht mehr dem Exchange von extern verbinden und erfolgt nur noch intern

        Reply

        • Meine Aussage hat sich darauf bezogen, wenn man Extern kein OA nutzt, können die Zertifikate weiterhin unterschiedlich sein.meine Tests vor 2 Jahren haben auch gezeigt, dass scheinbar OWA und EAS mit aktiven EAS auch mit 2 unterschiedlichen Zertifikaten fkt., in 2 Tagen weiß ich mehr.

  17. Mal eine kleine Frage, sollte man Probleme bei Aktivierung von EP haben und will zurück, welches ist der richtige Befehl?

    .\ExchangeExtendedProtectionManagement.ps1 -RollbackType „RestoreConfiguration“

    ODER

    .\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection

    Quellen:

    https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/

    https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-extended-protection?view=exchserver-2019#extended-protection-and-public-folder-scenarios

    Reply

Leave a Comment