[English]Seit dem 13. Februar 2024 ist ja eine Schwachstelle CVE-2024-21410 bekannt, über die Angreifer NTLM-Hashes per Microsoft Exchange Server abgreifen und dann für NTLM-Relay- oder Pass-the-Hash-Angriffe missbrauchen können. Nun habe ich gelesen, dass mehr als 28.500 Exchange Server über CVE-2024-21410 angreifbar sind. Administratoren müssen also handeln und ihre IT-Infrastruktur absichern. In diesem Kontext ist mir auch noch eine Analyse von Frank Carius untergekommen, der die Schwachstelle nicht beim Exchange Server sondern beim IIS sieht. Es ist also potentiell wesentlich mehr betroffen.
Anzeige
Rückblick Schwachstelle CVE-2024-21410
Ich habe mich hier im Blog ja bereits ausgiebiger mit der Schwachstelle CVE-2024-21410 befasst. Im Beitrag Microsoft Security Update Summary (13. Februar 2024) findet sich der Hinweis, dass es sich bei CVE-2024-21410 um eine Microsoft Exchange Server Elevation of Privilege-Schwachstelle handelt, die als kritisch und mit dem CVEv3 Score 9.8 eingestuft ist. Eine erfolgreiche Ausnutzung dieser Schwachstelle würde es einem Angreifer ermöglichen, einen NTLMv2 Hash gegen einen anfälligen Server weiterzuleiten. NTLM2.0-Hashes könnten in NTLM-Relay- oder Pass-the-Hash-Angriffen missbraucht werden.
Administratoren können in Microsoft Exchange Server die Extended Protection (EP) aktivieren, um gegen diese Art Angriffe geschützt zu sein. Ich hatte dazu was im Blog-Beitrag Nachlese zu CU 14 für Exchange 2019 und Schwachstelle CVE-2024-21410 (Feb. 2024) geschrieben. Alternativ können IT-Administratoren die NTLM-Authentifizierung gegen eine Kerberos-Authentifizierung ersetzen, um das Risiko, dass NTLM2.0-Hashes abgegriffen werden können, erst gar nicht aufkommen zu lassen.
R.S. hatte in diesem Kommentar was dazu geschrieben, und darauf hingewiesen, dass die NTLM-Hashes nur von außen abgegriffen werden können, wenn der Port 445 (SMB) in der Firewall nach außen hin offen ist. Das sollte in einer guten Konfiguration nicht der Fall sein. Und in diesem Kommentar habe ich die beiden Artikel von Frank Zöchling zur Umstellung auf Kerberos-Authentifizierung verlinkt.
Exchange 2013: Authentifizierung auf Kerberos umstellen
Exchange 2019: Kerberos Authentifizierung aktivieren
Anzeige
Eigentlich eine IIS-Schwachstelle
Frank Carius hat sich des Themas nochmals angenommen und weist ebenfalls darauf hin, dass CVE-2024-21410 eigentlich keine Exchange Server-Schwachstelle ist. Sondern es erfolgt ein NTLM-Angriff zum Abgriff der Hashes auf den von Exchange Server verwendeten Internet Information Server (IIS).
Frank weist in obigem Tweet auf seine Einschätzungen hin und schreibt, dass die Schwachstelle für jede Webseite oder jedes virtuelle Verzeichnis gilt, für die folgendes zutrifft:
- Sie ist auf eine IIS gehostet
- IIS Extended Protection ist nicht aktiv (leider Default)
- Anmeldung mit "Windows Integrated Authentication" aktiv
Damit sind laut Frank auch Dienste wie WSUS, SharePoint, Skype for Business Webdienste, Biztalk-Server, RDP-Service und viele ASP.NET-Anwendungen, PHP etc. sowie 3rd Party Lösungen auf dem IIS betroffen.
Das im Tweet angesprochene ADFS dürfte nicht betroffen sein, da es die HTTP.sys verwendet und ohne den IIS auskommt. Es lässt sich da keine EP aktivieren – wird in nachfolgendem Kommentar und auch in einem Facebook-Kommentar erwähnt.
Frank Carius ruft auf, die "IIS Extended Protection" bei allen Webservern anzuschalten. Hier mal die beiden Artikel von Frank Carius zum Thema verlinkt:
Informationen zur IIS Extended Protection
Informationen zu CVE-2024-21410
Mehr als 28.500 Exchange Server angreifbar
Mit obigen Informationen hätte ich gesagt: Das Risiko ist begrenzt, habe aber die Rechnung ohne die Administratoren gemacht. Die Kollegen von Bleeping Computer melden in diesem Artikel, dass bis zu 97.000 Microsoft Exchange-Server möglicherweise anfällig für Angriffe über die Schwachstelle CVE-2024-21410 sind. Derzeit seien bereits 28.500 Server als anfällig für die Schwachstelle, die von Hackern bereits zum Abgreifen der Hashes und auswerten der Rechte aktiv ausgenutzt wird, identifiziert worden.
Sie beziehen sich auf obigen Tweet von Shadowserver, die auf dieser Seite entsprechende Exchange-Instanzen auflisten. Deutschland ist mit fast 25.000 Instanzen gut mit dabei und liegt noch vor dem USA.
Ähnliche Artikel:
Microsoft Security Update Summary (13. Februar 2024)
Exchange Server Update CU 14 (13. Februar 2024)
Nachlese zu CU 14 für Exchange 2019 und Schwachstelle CVE-2024-21410 (Feb. 2024)
Südwestfalen IT: Chaos ist das neue Normal; Mail für NRW-Verwaltungen wegen Sicherheitslücke gestoppt
Anzeige
Wow, 25.000 ungepatchte Exchange-Server in Deutschland!
Das ist schon eine fette Hausnummer!
Ich kanns nicht verstehen!
Der Exchange (2013/2016/2019) unterstützt EP ist seit dem Patchday August 2022, also seit satten 18 Monaten.
Wer EP noch nicht aktiviert hat, hat nicht nur ein Problem mit der Lücke CVE-2024-21410, sondern auch mit der Lücke CVE-2023-23397 vom März 2023.
Damals gabs einen Patch für Outlook und Exchange, der einen Einfallsvektor für die Lücke schließt, aber nicht die Lücke selbst.
Bei der werden ebenfalls NTLM-Hashes abgezogen und auch diese Lücke lässt sich durch EP schließen.
Es gibt noch weitere Lücken aus 2022, die sich mit EP schließen lassen:
CVE-2022-24516
CVE-2022-21979
CVE-2022-21980
CVE-2022-24477
CVE-2022-30134
Die Aktivierung von EP sollte also bei jedem Exchange-Administrator auf höchster Eskalationsstufe stehen!
Es war jetzt fast 1,5 Jahre Zeit dafür, das zu machen.
3rd Party Integrationen erschweren allerdings den Einsatz von EP und einige Anwendungsszenarien sind damit nun nicht mehr kompatibel, weshalb sicher etliche davon abgesehen hatten, nachdem offiziell keine Dringlichkeit Bestand.
Anderes Szenario lese ich doch immer wieder von Leuten, die bloß Patches einspielen, sich aber die Infos dazu nicht durchlesen.
Die beiden Szenarien dürften dann wohl stark zu der Anzahl, der verwundbaren Systeme, beigetragen haben.
Wo hast Du die Information her, dass es in Deutschland 25000 Server sind?
Steht doch am Ende des Blog-Beitrags: "Deutschland ist mit fast 25.000 Instanzen gut mit dabei"
Naja,
EP funktioniert dann gut wenn man den.Exchanhe direkt ans Internet hängt. Wer das macht ist recht mutig.
Wir können im Moment EP nicht nutzen da wir eine WAF und Loadbalancer mit multiblen Domänen haben die alle.auf dem Exhange aufschlagen. Müssen erst mal schauen ob wir jetzt entsprechende Zertifikate nachkaufen.
haben aber schon seit langem bei uns.Kerberos als Teil der AD Härtung aktiv.
es soll zwar gehen wenn die selben Zertifikate auf den tools vorne.dran sind wie auf dem.exchange. Bei unseren Tests bei der Einführung haben sich aber trotzdem immer wieder Outlook Clients ausgehängt
Im Zeitalter von ZeroTrust und die hohe Wahrscheinlichkeit in großen Netzwerken, dass da irgendwann Mal ein Angreifer sitzt, ist die reine Blockade vom Port (zb 445) an der Perimeter Firewall nicht mehr ausreichend. Klar die Ausnutzung der Lücke wird erschwert, ist aber nicht ausreichend geschützt.
Theoretisch könnte ein intern sitzender Angreifer somit also die Daten abgreifen und nach extern leiten oder gleich im internen Netz weiter missbraucht werden.
Stimmt.
Gegen Angriffe von Intern schützt das Schließen des Ports 445 nicht.
Aber EP schützt vor dem Abgreifen von NTLM-Hashes.
Bei einem offen Port 445 sollte man sich eh fragen, warum der offen ist.
Will man SMB-Zugriffe von Extern?
Wohl kaum!
Mir fällt da kein Scenario ein, weshalb der Port 445 nach außen hin offen sein sollte.
Und bei Angriffen von Intern hat man noch ganz andere Probleme als den Exchange.
Es geht darum, dass ein internes Gerät aus dem LAN einen externen SMB-Server im Internet anspricht und dabei seinen NTLM-Hash zwecks Authentifizierung überträgt.
Somit muss der Port 445 für SMB vom internen LAN in Richtung Internet gesperrt sein. Klar sollte der Port 445 vom Internet in Richtung LAN auch geschlossen sein, aber dass ist hier quasi nicht der "Use-Case".
Auch sollte einem bewusst sein, dass diese Sperre von SMB in Richtung Internet nichts bringt, wenn ein Angreifer bereits ein Gerät im LAN kontrolliert, welches als Reciever dienen kann.
Wer nutzt so einen Müll eigentlich noch? Dazu muss man seine Ehre und sein Gewissen doch direkt im nächsten Gulli versenken, um sowas zu tun.
Dann nenne doch einmal eine Groupware mit dem Funktionsumfang der Kombi Exchange und Outlook.
Bashing hilft hier überhaupt gar nicht weiter!
was nützt dir der beste Funktionsumfang, wenn du – Gewissen vorausgesetzt – jede Nacht schlecht schläfst, weil Du so etwas deinen Kunden oder Kollegen zumutest?
weniger ist mehr
egroupware z.B.?
Einen ganz normalen Linux-Email (IMAP/SMTP) Server mit Sogo (https://www.sogo.nu/) für's ActiveSync und Webmailer. Hat alles, was Exchange auch kann inkl. 2FA ohne ModernAuth und Weitergabe der Schlüssel an Microsoft.
Seit Jahren migriere ich erfolgreich diverse OnPrem-Exchanges auf diese Konstellation.
das Anmeldeverfahren stammt aus den 90ern und ist bequem, es hat rein gar nichts mit Exchange zu tun. Kannst es ja abschalten
Wie war das gleich? Auf Exchange in Hybrid-Konfiguration kann man EP nicht aktivieren, oder hab ich da was falsch verstanden?
Ach und wieviele sind denn zu 100% auf Exchange-Online oder zu 100% OnPrem?
Da werden wohl recht viele ne Alternative finden müssen, weil sie einfach gerade in der Migration zu Ex-Online stecken und das CU ohne EP installieren (müssen).
Es bleibt spannend
Nicht ganz. Es ist nur explizit Modern Hybrid mit dem Modern Hybrid Agent auf Exchange nicht mit EP kompatibel. In dem Fall muss man eins der VDirs von EP ausschließen (geht beim CU14-Setup per Kommandozeile mit einem zus. Parameter). Falls man Classic Hybrid verwendet ist das nicht gegeben und EP kann normal eingeschaltet werden.
Das betrifft nur modern Hybrid!
Wir verwenden Classic Hybrid, damit funktioniert EP.
Warum ADFS betroffen sein soll, ist mir noch nicht ganz klar. Weil für diese Rolle wird kein IIS installiert. Damit kann EP doch gar nicht aktiviert werden?!
Die Liste von Frank würde ich nicht mit Gold aufwiegen – sehe es als Beispiel für Dienste, die Admins und/oder Entwickler auf Verletzbarkeit prüfen müssen. Hatte den Hinweis auf ADFS auch auf Facebook vernommen – Frank hat da aber nicht drauf reagiert.
Bei der Geschichte geht es darum, das ohne EP bei einem IIS über eine MitM-Attacke NTLM-Hashes abgegriffen werden können. Und mit den abgegriffenen NTLM-Hashes kann man sich natürlich auch gegen das ADFS authentifizieren und gegen alles in der Domäne, was eine NTLM Authentifizierung nutzt.
EP verhindert das Abgreifen von NTLM-Hashes über MitM.
Man könnte alternativ auch NTLM komplett abschalten und alles auf Kerberos umstellen.
Kein NTLM = keine Möglichkeit, NTLM-Hashes abzugreifen.
Bei Frank Carius kann man schön sehen, wie so ein MitM-Angriff aussieht.
Ich versteh nicht warum kleine/mittlere Firmen Exchange OnPremises betreiben.
Da sind ExchangeOnline Accounts für 4,2EUR/Account/Monat reichlich günstig wenn man zumindestens einen Exchange-Admin, die ganzen Lizenzen, Hardware/FallbackHardware bis hin zum Security-Gateway hin und das ganze Knowledge rund um Backup/Disaster-Recovery einrechnet.
Ein Backup-Konzept macht auch bei Exchange Online mehr als Sinn, oder möchte man sich auf Microsoft verlassen, dass im Zweifel keine Daten abhanden kommen?
Es gibt eine Backup-API und auch entsprechende Produkte.
Wir setzen (da sowieso VEEAM) VEEAM für Offic365 ein, das sichert nicht nur die Postfächer, sondern auch andere Inhalte im Teams bzw. OnDrive/Sharepoint.
Als "Billiglösung" habe ich auch bei diversen NAS-Herstellern (z.B. QNAP) entsprechende Apps gesehen.
Ja, die Daten nur bei Microsoft in der Cloud zu haben und bei Unstimmigkeiten (rechtlicher, technischer oder kommerzieller Natur) durch Abschaltung des Tenants zu verlieren ist mehr als fahrlässig und dürfte im kommerziellen Umfeld auch mit diversen Archivierungsauflagen (10 Jahre drohen eigentlich immer) kollidieren.
Verfügbarkeit und keine Abhängigkeiten?
Bei OnPrem bin ich nicht darauf angewiesen, das der Internetzugang funktioniert. Ich habe trotzdem Zugriff auf alles, kann nur keine Mails senden/empfangen.
Zudem muß man sich einmal anschauen, was bei ExchangeOnline im letzten Jahr los war.
ExchangeOnline ist nach dem Microsoft-Vorfall von 2023
nicht mehr vertrauenswürdig!
Zudem gibts da häufiger mal Ausfälle.
Ich bin also abhängig von der Verfügbarkeit des Dienstes und auch des Internetzugangs.
Und auch davon, das der Anbieter da nicht an den Funktionen herumfummelt. Z.B., das er einfach mal entschließt, bestimmte Funktionen nicht mehr anzubieten.
Auch das gabs schon bei ExchangeOnline.
Und der Dienstanbieter kann einem auch jederzeit den Zugang sperren (z.B., wenn der da Inhalte findet, die gegen dessen Nutzungsbedingungen verstoßen).
Dann sind alle Emails verloren!
Theoretisch könnte bei ExchangeOnline ein Admin bei Microsoft jede Mail mitlesen (übrigens auch bei OnPrem der lokale Admin).
Und mitgelesen wird bei ExchangeOnline auf jeden Fall, aber durch automatisierte Prozesse.
Denn sonst könnten die gar nicht feststellen, ob da Inhalte, die gegen die Nutzungsbedingungen verstoßen, vorhanden sind).
Und die 3-Buchstaben-Dienste haben da auch Vollzugriff drauf (Stichwort Cloud Act).
Und zudem muß ich schon ein gerütteltes Maß an Vertrauen an den Dienstanbieter und dessen Mitarbeiter haben.
Und die Hardware bzgl. Backup etc. muß man auch bei ExchangeOnline vorhalten, denn es gibt gesetzliche Aufbewahrungsfristen!
Alle Emails, die mit steuerlich relevanten Dingen zu tun haben (also z.B. Rechnungen, Aufträgen, Bestellungen, etc.) müssen 10 Jahre lang aufbewahrt werden, und zwar so, das die nachträglich nicht mehr verändert werden können.
Und was die Sicherheit angeht, ist ExchangeOnline auch nicht sicherer als OnPrem, siehe Microsoft Vorfall 2023.
Es ist sogar so, das ExchangeOnline sicherheitstechnisch schlechter da steht, denn ExchangeOnline bietet für Hacker eine viel größere Angriffsfläche als ein Exchange OnPrem.
Bei ExchangeOnline ist bei einem erfolgreichen Hack viel mehr zu holen als bei einem Exchange OnPrem.
ExchangeOnline bedeutet keineswegs weniger Aufwand!
Ob diese hohen OnPrem kosten die Vorteile der Offline Verfügbarkeit für kleine/mittlere Firmen wieder wett machen wage ich zu bezweifeln.
Als valider Punkt bleibt der Datenschutz. Aber macht das letztlich final noch einen so grossen Unterschied in der Microsoft Welt mit Teams/Windows/Office wo eh schon Tastenanschläge/Mausklicks etc im Rahmen vom Telemetry übertragen werden? Letztlich gibts klare Verträge an die sich Microsoft bei Businesskunden halten wird.
Ich denke für kleine/mittlere Firmen überwiegen die Sicherheitsvorteile eine bestmöglich gepatchten Umgebung, Online Support im Fehlerfall und den deutlich reduzierten kosten – insbesondere wenn man sich die katastrophale gelebte OnPrem-Praxis vieler kleiner Firmen ansieht.
weil die Daten dem Kunden gehören und nicht MS, weil die 4,x € nur die Einstiegsdroge sind und die Kunden auf 6J gesehen trotz lokaler Implementierung am Ende online dennoch das 3fache zahlen.
Bin ich froh dass ich unseren Exchange 2019 Server nun verschrottet habe und auf Zimbra umgestiegen bin.
so long
Yumper
Zimbra hatte in den letzten Jahren aber auch einige sehr schwere Lücken, die exploited wurden.
Das optimale Email System gibt es halt leider nicht :-(
Zu dem aufgeblasenen Exchange ist es bei ca. 50 Usern eine sehr gute Alternative
Versteh ich das richtig. Wenn mein Anwender hinter einer Firewall sitzt, die Port 445 weder eingehend noch ausgehend erlaubt, ist der Angriff nicht möglich.
Heißt dann in dem Fall, dass wenn der Anwender bei sich zu Hause hinter einem 0815-Router ohne brauchbare Firewall sitzt, dass die Lücke dann sehr gut ausnutzbar ist?
Doch, der Angriff ist ohne EP möglich, aber nicht mehr von Außerhalb, sondern nur von Intern.
Z.B. von einem Mitarbeiter, der sich z.B. Zugang zum Postfach der Geschäftsleitung verschaffen will.
Oder aber auch von einem Hacker, der schon ins Netzwerk eingedrungen ist.
Gut ok, EP ist bei uns eh aktiviert und VPN ist nötig. Aber vielleicht bekommen wir endlich nun ein paar Kunden davon weg, den Exchange offen zu haben ohne VPN und keine Geld für unsere Updatezeit auszugeben. So viel Resistenz gegenüber dem Rat des IT-Dienstleisters ist echt teilweise nicht normal…. aber anderes Thema
Der Anwender hat Outlook anywhere zu Hause auf sprich Lokal auf seinen Endgerät und erhält eine Mail mit der smb Anfrage..dann kannst wahrscheinlich davon ausgehen, dass die Anfrage erfolgreich ist.
Anders verhält es sich schätze ich mal, wenn der User eine terminalserver Sitzung aufmacht wo alle Anwendungen vorhanden sind..Hier sollten dann ja die Einstellungen der Firma innerhalb der Sitzung gelten.
IIS betrifft es aber ohne Exchange nur wenn ein Webost NTLM nutzt, verstehe ich das richtig?