Mit der Sicherheit vieler Microsoft Exchange-Server, die bei deutschen Anwendern laufen, sieht es nicht so rosig aus. CERT-Bund hat gerade eine Warnung veröffentlicht, dass rund 12.000 Microsoft Exchange Server 2016/2019 mit einem offenen OWA per Internet erreichbar, aber nicht auf dem aktuellem Patchstand und damit angreifbar sind.
Mangelhafter Exchange Server-Patchstand
Microsoft Exchange Server 2016/2019 sind ja beide noch im erweiterten Support durch Microsoft und erhalten Sicherheitsupdates. Diese müssen lediglich zeitnah installiert werden, um die Installationen gegen bekannte Sicherheitslücken abzusichern.
Aber mit dem Patchen hapert es wohl gewaltig. Mir ist der nachfolgende Tweet von CERT-Bund mit den Kernaussagen gerade untergekommen. Es gibt in Deutschland wohl über 12.000 Microsoft Exchange-Server 2016/2019, die mit offenem, also per Internet erreichbaren OWA (Outlook Web App) betrieben werden, aber auf einem sechs Monate alten Patchstand sind.
Laut CERT-Bund sind das 28% der Exchange-Server 2016/2019. Bei 15% der Exchange Server, dass sind ca. 6.500 Systeme, wurde der letzte Patch sogar vor über 12 Monaten eingespielt.
CVE-2024-26198 im März 2024 gepatcht
Ich habe mal nach CVE-2024-26198 geschaut. Das ist eine Microsoft Exchange Server Remote Code Execution-Schwachstelle, die zum 12. März 2024 geschlossen wurde. Die Schwachstelle ermöglicht einem nicht authentifizierter Angreifer die Remote-Ausführung von Befehlen. Dazu muss er eine speziell gestaltete Datei in einem Online-Verzeichnis oder in einem lokalen Netzwerk ablegen und den Benutzer dann dazu bringen, diese zu öffnen.
Bei einem erfolgreichen Angriff wird dann eine bösartige DLL geladen, was zu einer Remotecodeausführung führen kann. Microsoft hat die Schwachstelle mit einem CVE 3.1-Score von 8.8 bewertet. Hier wird die Ausnutzung aber nicht als sehr wahrscheinlich eingestuft – aber die Schwachstelle sollte gepatcht werden.
CVE-2023-36439 im November 2023 gepatcht
Bei CVE-2023-36439 handelt es sich ebenfalls um eine Remote Code Execution-Schwachstelle in Microsoft Exchange Server, die mit einem CVE 3.1-Score von 8.0 bewertet wurde. Ist ein Angreifer als gültiger Exchange-Benutzer authentifiziert, könnte er über die Schwachstelle NT AUTHORITY\SYSTEM Remotecode-Ausführungsrechte auf dem Server-Mailbox-Backend erlangen.
Microsoft stuft die Ausnutzbarkeit als eher wahrscheinlich ein. Administratoren, die eine betroffene Version von Microsoft Exchange verwalten, mussten das Sicherheitsupdate vom November 2023 herunterladen und sicherstellen, dass die Funktion zum Signieren serialisierter Daten aktiviert ist, um vor dieser Sicherheitsanfälligkeit geschützt zu sein. Offenbar ist das bei einer Reihe Systeme nicht passiert.
Cybersicherheit mangelhaft
Geht man den obigen Tweet mit den benannten Schwachstellen durch, erkennt man beispielsweise, dass die Remote Code Execution-Schwachstelle CVE 2023 36745 vor einem Jahr, im September 2023 gepatcht wurde.
Ich verstehe es nicht: Die genannten Microsoft Exchange Server 2016/2019 sind ja noch im erweiterten Support durch Microsoft und erhalten kostenlos Sicherheitsupdates. Diese müssten schlicht von Administratoren installiert werden. Sind das Systeme, die nicht gewartet werden? Oder gibt es gute Gründe, die betreffenden Updates einfach nicht zu installieren?
Unter dem obigen Gesichtspunkt braucht es niemanden zu wundern, wenn es erfolgreiche Cyberangriffe am laufenden Band gibt. Denn es ist naheliegend, dass andere Software-Komponenten, die in diesem Umfeld betrieben werden, ebenfalls nicht auf dem aktuellen Patchstand sind.
Die wenigstens KMUs haben Wartungsverträge oder eigene IT. Das ist nichts ungewöhnliches. Also gerade die kleineres Unternehmen, die aber ein bißchen eigene IT betreiben. Das wird einmal installiert und wieder angepackt wenn was nicht mehr geht.
Aber die Cloud wird es schon richten. Dann kümmern sich ja andere darum. Leider wird sich das dann keiner mehr leisten können und wir nehmen wieder Rechenschieber statt Computer.
Tatsächlich ja, die Cloud wird es richten. Gerade für kleinere Unternehmen, die sich die eigene sichere(!) Infrastruktur nicht leisten können oder wollen, können hier von der Cloud profitieren. Aus Sicht der IT-Sicherheit ist es wahrscheinlich besser, wenn sich ein Dienstleister um die Wartung der Mail-Infrastruktur kümmert, als jemand im Unternehmen, der das mal nebenbei macht.
Andererseits sind die Cloud-Lösungen damit auf einem Präsentierteller gebündelt…
Mir wird vollkommen schlecht, wenn ich sehe, wie die Kunden-VMs da unter Dauerbeschuss von IPs östlich von Passau stehen… Und zwar bei fast allen Anbietern, zumal fahrlässigerweise die meisten (ja, Billigheimer) kein VPN mit anbieten…
Abgesehen davon sind die Cloud-Lösungen auch nicht wartungsfrei.
Die typische Klein-IT hinter einer Fritzbox ist da nicht frei davon, aber die Fritzbox kümmert sich darum. Da geht das WLAN mal in die Knie, wenn die Fritzbox mit dem Ablehnen von Login-Versuchen beschäftigt ist, aber der Rest geht.
Wenn die Attacken auf die Cloud-VMs mal heftig sind, dann steht die VM. Der einzige Vorteil ist, die Kunden merken das auch… ;)
Ich sehe da keine eindeutigen Vor- und Nachteile bei den Varianten der (schlecht gewarteten) Klein-IT.
Wenn man einfach die Server statt im Keller (mit privater IP) ins Rechenzentrum (mit öffentlicher IP) stellt, ist das keine „Cloud“, sondern Hosting. Und in diesem Fall auch noch eine sicherheitstechnische Katastrophe.
Ja, man kann seine Server in ein RZ bringen. Dazu gibt es viele Möglichkeiten, auch mit echter Firewall davor. Ein Root-Server mit direktem Internet-Anschluss ist aber sicher keine adäquate Lösung.
Und jede Firewall sollte Geoblocking beherrschen. Wenn man den Zugriff auf OWA auf wenige Länder begrenzt, hat man schon mal die Angriffsfläche drastisch reduziert. Das ist natürlich kein Grund um Sicherheitsupdates auszulassen.
„CVE-2023-36439 im November 2024 gepatcht“. Da hat sich ein kleiner Fehler in der Überschrift eingeschlichen, im Text steht korrekterweise November 2023.
Zum Thema: Es ist immer wieder erschreckend zu sehen, wie nachlässig mit dem Thema umgegangen wird. Wenn ich Systeme selber betreibe (egal ob IT oder andere Bereiche) bin ich auch selbst dafür verantwortlich. Ja, auch ich habe schon mal einen einzelnen Exchange Patch ausgelassen, wenn der was gravierendes kaputt gemacht hat und es keinen Workaround gab. Das war dann aber wissentlich und wurde nachgeholt, wenn der Fehler gefixt wurde. Allerdings hängt unser Exchange auch nicht direkt offen am Internet, sondern hinter einer WAF.
Es sollte sich doch inzwischen rumgesprochen haben, dass alles angegriffen wird, was nicht bei 3 auf dem Baum ist. Aber es gibt ja auch „Experten“ die der Meinung sind, Managementinterfaces ins offene Internet zu hängen.
Ja, das hatte ich hier schon ein paar mal erwähnt.
Und es ist davon auszugehen, das die Server, auf denen Exchange läuft, auf einem ähnlichen Patchstand sind.
Und auch alle anderen Server und vermutlich auch die Desktopsysteme und Anwendungen im Unternehmen.
Das Thema Sicherheit spielt gerade in kleinen Unternehmen eine untergeordnete Rolle.
Viele Unternehmen machen sich darüber entweder gar keine Gedanken oder man ist der Meinung, das nur große Unternehmen Opfer von Cyberangriffen werden.
Das ist aber ein Trugschluß, denn immer mehr kleine Unternehmen werden Opfer von Cyberangriffen.
Die zu erbeutenden Summen sind da für die Cyberangreifer zwar nicht so hoch, aber dafür ist die Erfolgschance viel höher. Da macht es dann die Masse.
Und in der Presse liest man i.d.R. nur von erfolgreichen Angriffen auf größere Firmen und Institutionen.
Wenn eine kleine Firma mit < 50 Mitarbeitern Opfer eines Cyberangriffs wird, liest man davon nirgendwo etwas.
Im Übrigen sieht es bei unseren europäischen Nachbarn auch nicht viel besser aus.
Und u.U. ist die kleine Firma danach insolvent. Darwin lässt grüßen.
Stimmt, weil i.d.R. auch kein belastbares Backupkonzept vorliegt oder gleich gar keine Backups gemacht werden oder nur sporadisch.
Das Patchen von Exchange ist leider nicht so einfach wie manche sich das vielleicht vorstellen. Das ist manchmal noch übler als bei den regelmäßig vermurksten Windowsupdates. Als kleine Einstimmung in das Thema: https://learn.microsoft.com/de-de/exchange/troubleshoot/client-connectivity/exchange-security-update-issues
Grob fahrlässig. Die Server sollten von einer staatlichen Behörde stillgelegt werden dürfen. In diesem Fall bin ich auch für Bußgelder.
Das könnte mit der NIS-2 durchaus Realität werden, denn Patchen gehört nun mal zum Stand der Technik. Aktuell werden wir aber wohl mindestens bis März 2025 warten müssen bis es eine Umsetzung als Gesetz in Deutschland gibt.
Auch ist es mit dem Einspielen des Patches alleine ja auch nicht immer getan. Es gibt weitere Maßnahmen, welche zur Härtung von Exchange erfolgen sollten. Microsoft selbst bittet mit dem HealthChecker Skript für Exchange eine sehr gute Hilfestellung an. Dieses Skript wird auch laufend informiert und angepasst.
https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/
Gruß Singlethreaded
Warum liefert Microsoft seinen Exchangeserver dann nicht in der Standardeinstellung sicher aus? Alles andere ist nur Gefrickel
Weil Sicherheitslücken oft erst nach dem Release bekannt werden?
Man kann in der Softwareentwicklung schlicht nicht alle Eventualitäten abprüfen.
Meist ist die Ausnutzbarkeit von Lücken auch an diverse Bedingungen geknüpft.
Und manche Lücken sind auch nur bei Einstellungen, die nicht dem Auslieferungsstand entsprechen, vorhanden.
Aber das ist dir Regel.
100% der Benutzer von Exchange verwenden NICHT die Standardeinstellungen.
Denn damit ist Exchange kaum nutzbar.
Oder nutzt du z.b. deinen Fernseher in Standardeinstellung?
Schon das Ändern der Lautstärke ist eine Veränderung der Standardeinstellungen!
Nicht alles was hinkt ist ein Vergleich. Aber mal im Ernst wenn ein Softwarehersteller es nicht auf die Reihe bekommt Lücken zu vermeiden die durch ändern von Standardeinstellungen geöffnet werden ist unfähig. Ein Fernseher wird nicht zum Sicherheitsrisiko wenn ich Standardeinstellungen ändere.
Dafür gibt es verschiedene Gründe. Zum Teil geht es um Faktoren, welche nicht direkt durch einen Patch beeinflusst werden können. Das sind z.B. die Zertifikate welche für TLS verwendet werden. Ein Patch kann ein schwaches Zertifikat nicht von 1.024 auf 4.096 Bit hochstufen, die für die Absicherung von OWA erforderliche Download-Domain ergänzen oder abgelaufene Zertifikate ersetzen.
Bestimme Einstellungen müssen auch mit den Einstellungen im AD zusammenpassen, damit manche Patches ihre Schutzwirkung entfalten. Es ist nun mal Aufgabe eines IT-Admins diese Dinge zu regeln.
Das Skript klopft auch die Konfiguration externer Komponenten ab. So werden z.B. die Einstellungen von VMXNET-3 Netzwerkkarten aus VMware geprüft. Es gibt Best Practices für die Einstellungen im Treiber. Die Puffer müssen ausreichend groß dimensioniert werden, damit es nicht zu Paketverlusten kommt. Auch hier sollte ein Patch für Exchange nicht einfach Änderungen vornehmen.
Zwar sollte ein Server mit Exchange nur Exchange dienen und sonst keine Workloads tragen, aber die Praxis sieht oft leider anders aus. Knipst ein Patch für Exchange hier einfach mal TLS 1.0 und 1.1 für den Server aus, dann könnte es zu Kollateralschäden kommen.
Der Exchange-Mitigation-Service würde erst nach den massiven Exchange-Hacks hereinprogrammiert. Damit das funktioniert, muss der Server aber den Pattern-Dienst von Microsoft erreichen können. Der Patch kann aber keine Regel zur Firmen-Firewall hinzufügen, welche diesen Traffic erlaubt.
Das Skript weist sehr gut auf solche Dinge hin und nennt in der Ausgabe auch direkt die URL mit der Hilfe zum jeweiligen Thema. Die Dokumentation ist ordentlich und für eine Fachkraft aus dem IT-Bereich auch gut verständlich.
Microsoft macht lange nicht alles richtig, dass ist keine Frage. Ich selber würde mir viel mehr Fokus auf Security und weniger Features wünschen. Trotzdem gilt aber auch, dass derjenige der ein komplexes System wie Exchange betreibt, auch eine Mitverantwortung trägt dieses System zu pflegen und nach dem Stand der Technik zu warten.
Bei einem Lifecycle von fast zehn Jahren bleiben neue Erkenntnisse nicht aus, was gestern als sicherer Standard galt, ist heute vielleicht schon überholt. Entsprechend gilt es anpassungsfähig zu bleiben.
Ergänzend sei gesagt, dass für SMTP auch ein entsprechender Proxy vor den Exchange-Server gehört.
Des weiteren sollten OWA, AS, MAPI, etc. ausschließlich über Pre-Authentifizierung bereitgestellt werden. Das setzt aber weiteres Wissen und Ressourcen voraus.
Auch dafür bietet Microsoft von Hause entsprechende Rollen an (AD FS, WAP, etc). Was aber in der Regel eine funktionierende DNS und PKI voraussetzt. Jetzt könnt ihr vermutlich an einer Hand abzählen, wie viele Kunden diesen Aufwand auf sich nehmen können…
Es gibt da natürlich auch 3rd Party Produkte, z.B. F5, Sophos, etc. Hat/Kann aber den Nebeneffekt haben, dass nach einem Microsoft Update es zu Inkompatibilitäten kommt. Was im Best Case durch einen Ticket beim 3rd Party Hersteller zeitnah gefixt wird. Im Worst Case geht das Hersteller Ping-Pong los.
Naja, wer nutzt denn noch TLS 1.0 oder 1.1?
Die sind unsicher und schon Windows XP unterstützt TLS 1.2.
Es geht darum welche Cipher auf dem Server aktiv sind. Auch Windows Server 2016 und 2019 unterstützen noch aktiv TLS 1.0 und TLS 1.1. Diese Server wird man in Kombination mit Exchange 2016 und Exchange 2019 recht häufig sehen.
Natürlich wird bevorzugt TLS 1.2 oder bei Server 2019 auch TLS 1.3 verwendet, aber Hacker können per Downgrade-Attacke ansetzen und Verbindungen ggf. auf eine schwache Verschlüsselung herunterstufen, welche sich dann als MITM entschlüsseln lässt. Genau deshalb gehören die alten Cipher in den Status „disabled by default“, so dass kein Downgrade möglich ist. Dafür gibt es Einträge in der Registry und diese werden durch das Skript geprüft.
Wir betreiben eigene Mail-Gates für unser Unternehmen, Exchange gibt es nur im Backend. Würde man die volle Security von allen anderen Gegenstellen erwarten:
– HELO korrekt
– Absenderdomain existiert
– Absenderdomain hat gültigen Mail-Server
– Reverse-DNS
– SPF
– DKIM
– DMARC
– Nur TLS 1.2 oder höher mit PFS
– Steht auf keinen Sperrlisten
Ich glaube 20% unserer Kunden kämen nicht mehr per Mail mit uns in Kontakt. Es gibt meiner Erfahrung nach viel Verbesserungspotenzial in diesem Bereich.
2019 und TLS 1.3, und das im Kontext von Exchange? Ähm..
Mein Fehler. TLS 1.3 Support war für Exchange 2019 mit dem CU14 geplant, hat es dann aber wohl doch nicht ins Update geschafft.
Ist jetzt für CU15 wieder in der Planung. Siehe:
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-2024-h1-cumulative-update-for-exchange-server/ba-p/4047506/page/3
Vorraussetzung ist aber mindestens Windows Server 2022.
Ja, natürlich muß man die Downgrademöglichkeit auf TLS 1.0 und 1.1 abschalten, sonst macht TLS 1.2/1.3 wenig Sinn.
Und man müsste nicht nur alte TLS Versionen und Ceipher sondern auch die TLS negotiation ganz abschalten, aber es gibt noch genug Server die gar keine Verschlüsselung machen, diese wären da komplett nicht mehr erreichbar. Lässt man die TLS negotiation allerdings an, sagt der MITM einfach, aber ich kann doch gar keine Verschlüsselung… und sowas wie HSTS gibt es bei email afaik nicht.
„und sowas wie HSTS gibt es bei email afaik nicht“
Doch, gibt es: nennt sich MTA-STS
Sehe ich auch so. Zwangsabschalten und hohe Strafen für die Betreiber… Anders scheint man nicht lernfähig zu werfen.
Stand nicht mal irgendwo das MS selbst (also die Cloud Mailserver) mails von veralteten On Premise Exchange Servern blocken?
„hohe Strafen für die Betreiber“ ach!
…wir wäre es mal mit hohe Strafen für den Hersteller von so einem Murks?
Und zusätzlich bitte Kaufpreis- und Lizenzkostenerstattung für die Kunden denen der Murks angedreht wurde dazu.
Warum? Wer wird gezwungen, den Murks einzusetzen? Wenn man weiß, das es Murks ist, lässt man es oder hat dafür die Haftung zu übernehmen.
Komisch warum warnen die nicht mal allgemein vor Microsoft-Produkten die ja so löchrig sind wie ein schweizer Käse? Da kommen lieber neue Oberflächen, KI, Cloud und sonstiger Quatsch, die Sicherheitsprobleme werden mit den unendlichen Patches nur verschlimmbessert und kann froh sein wenn der Murks danach noch läuft.
Weil es unter Linux dasselbe ist, siehe die aktuelle CUPS-Problematik: „From a generic security point of view, a whole Linux system as it is nowadays is just an endless and hopeless mess of security holes waiting to be exploited.“
wieder Werbung für Exchange Online durch Bundesbehörden??
Der Vorteil bei M365 liegt ja nicht an den „sichereren“ Produkten, sondern daran, dass die Daten nicht entwendet werden können.
Sie sind ja schon weg.
Wird interessant. NIS-2 kommt. Wie will man das erklären? Aber NIS2 wird auch nichts bringen, wenn niemand sowas kontrolliert und auch ahndet.
Es ist wie es ist. Ich bin gespannt was passieren muss, um die IT-Budgets zu verdoppeln oder zu verdreifachen. Statistik sagt ja, dass in D nur 1,x% vom BIP in IT investiert wird. Fast Schlusslicht in EU…