Das Crowdstrike-Fiasko: Ursachenforschung und erste Lehren
Nach dem vielleicht größten Ausfall der IT-Geschichte analysiert Jürgen Schmidt, was genau schiefgelaufen ist – und vor allem, wie es zukünftig besser ginge.
Notfall im Rechenzentrum
(Bild: vchal/Shutterstock.com)
Ein fehlerhaftes Update für Crowdstrikes Agent-Software führte dazu, dass weltweit rund 8,5 Millionen Windows-PCs abstürzten – viele davon in Produktivumgebungen in Firmen. Der Fehler war so hartnäckig, dass ein Neustart nicht möglich war: Windows fraß sich immer wieder an derselben Stelle fest. Das Problem gilt vielen bereits als der größte Ausfall der IT-Geschichte.
Nach dem ersten Entsetzen und den anschließenden Bemühungen, die Systeme wieder zum Laufen zu bringen, beginnt langsam die Bestandsaufnahme: Was waren die Ursachen? Warum wirkte sich das so verheerend aus? Kann das wieder passieren? Und was können Firmen beziehungsweise die involvierten Hersteller tun, dass sich so etwas nicht wiederholt? Darum geht es im Folgenden; ganz zum Schluss kommen auch noch ein paar praxisrelevante Tipps, die alle Firmen-Admins beherzigen sollten.
Das Update-Problem
Für das Verständnis ist wichtig, dass es sich nicht um ein klassisches Software-Update handelte. Das hätten Admins vielleicht testen oder zumindest gestaffelt ausrollen können, um solch flächige Ausfälle zu vermeiden. Vielmehr lieferte Crowdstrike als Reaktion auf neue Bedrohungen ein neues Erkennungsmuster aus, das bestimmte Tricks mit Named Pipes aufdecken und unterbinden sollte. Unbestätigten Gerüchten zufolge war der Auslöser ein neues Feature im Angriffs-Framework Cobalt Strike, das auch Kriminelle gerne nutzen. Dessen Hersteller hatte kurz vor dem fatalen Crowdstrike-Update neue Funktionen auf Basis von Named Pipes vorgestellt.
Crowdstrike bietet zwar eine Option, die Software als solche auf einen älteren Versionsstand zu zwingen, um anderen das Testen neuer Funktionen zu überlassen. Doch das betrifft nur die eigentliche Software. Die in sogenannten Channel-Files ausgelieferten Signaturen werden immer in den jeweils aktuellen Versionen installiert. Diese Signatur-Updates erscheinen täglich, manchmal sogar stündlich, und sie werden ohne weitere Kontrollinstanz direkt ausgeliefert und aktiviert. Das ist der Dringlichkeit geschuldet, auf Gefahren möglichst schnell zu reagieren und deshalb in der Security-Branche üblich. Anwender sind in dieser Hinsicht sehr weitgehend der Sorgfalt der Hersteller ausgeliefert. Wichtig ist, dass diese Updates auch Befehle wie "Lösche diese Datei" enthalten können, die der Crowdstrike-Agent ausführt. (Das macht vielleicht im Nachhinein die Warnung des BSI vor dem Einsatz von Kaspersky-Software nachvollziehbar).
Windows als "offenes" System
Hinzu kommt, dass sich schon Antiviren- und heute noch mehr EDR-Software sehr tief ins System einklinkt, um bösartige Aktivitäten von Schad-Software selbst zu erkennen und dann auch unterbinden zu können. Nahezu jedes EDR installiert dazu unter Windows Treiber mit Kernel-Rechten. Das führt dann dazu, dass oftmals komplexe und fehleranfällige Software im Kernel-Modus ausgeführt wird. Und wenn ein Kernel-Bestandteil etwa durch einen Fehler im Code abstürzt, dann steht das komplette System. Was es mit dem Kernel-Modus und dessen Gefahren auf sich hat, erklärt übrigens der Autor des Windows-Taskmanagers Dave Plummer hervorragend in einem Video auf X.
Neben der Absturz-Gefahr bringen komplexe Kernel-Treiber natĂĽrlich auch vermehrt Security-Risiken mit sich. Und das Schlimme ist: Das trifft oft sogar Nutzer, die diesen Treiber gar nicht selbst einsetzen. So hat sich etwa die Angriffstechnik namens "Bring your own vulnerable driver" etabliert, bei der Angreifer selbst einen bekanntermaĂźen angreifbaren Kernel-Treiber installieren, nur um mit diesem dann gezielt etwa Sicherheitssoftware abzuschieĂźen.
Dass das auch anders geht, zeigt etwa Apple, die solche Kernel-Treiber strikt unterbinden. Stattdessen bieten sie der Sicherheitssoftware von Drittherstellern spezielle Schnittstellen, über die diese ihre Aufgaben wahrnehmen können, ohne dazu selbst tief ins System einzugreifen. Entsprechend fordert etwa der Sicherheitsexperte Kevin Beaumont, dass Microsoft da auch in Windows harte Leitplanken einziehen müsse, um das gefährliche Treiben der Hersteller einzugrenzen.
Das Problem dabei ist, dass solche Beschränkungen die Monopolstellung von Microsoft weiter ausbauen und die Möglichkeiten unabhängiger Security-Anbieter, sich mit innovativen Produkten auszuzeichnen, drastisch reduzieren. Kritiker fürchten ferner, dass Microsoft das ausnutzen würde, seine ohnehin schon dominante Position im Security-Markt weiter auszubauen und die Konkurrenz am ausgestreckten API-Arm verhungern zu lassen. Tatsächlich hatte Microsoft vor über zehn Jahren bereits erste Schritte in diese Richtung unternommen, stieß dabei aber auf harte Kritik der Konkurrenz aus dem Security-Lager und wurde letztlich auch von den Wettbewerbshütern zurückgepfiffen.
Es gibt aber durchaus auch Maßnahmen, wie Microsoft Sicherheit und Resilienz von Windows verbessern kann, ohne Konkurrenz unfair auszubremsen. So könnte Windows den eigenen Boot-Prozess überwachen und wenn es feststellt, dass es wiederholt an der gleichen Stelle hängen bleibt, dem Anwender anbieten, zur Problembehebung ohne den problematischen Treiber zu booten. Das wäre kein Hexenwerk, sondern solides Software-Engineering und hätte dafür gesorgt, dass die Betroffenen das System mit einem einfachen Tastendruck wieder auf die Beine bringen könnten. Windows kann das zwar prinzipiell, erlaubt jedoch Ausnahmen für sogenannte Boot-Start-Treiber. Offenbar hat Crowdstrike seinen Treiber als solchen markiert, in der Annahme, dass es besser sei, Windows gar nicht zu starten, als ohne Crowdstrikes Schutz. Da könnte Microsoft zugunsten der Resilienz rigider vorgehen, müsste das dann natürlich für die eigenen Defender-Treiber ebenso handhaben.
Microsoft könnte auch bessere Schnittstellen anbieten, um das Problem fehlerhafter Treiber zu entschärfen. So gibt es durchaus Sicherheitslösungen, die bewusst auf eigene Kernel-Treiber verzichten. Capsule8 etwa nutzt die Kernel-Schnittstelle eBPF, um tiefe Einblicke in die überwachten Linux-Systeme zu gewinnen. Doch eBPF für Windows steckt noch in den Kinderschuhen, erklärt etwa der Sicherheitsforscher Matt Suiche, warum das für Windows-Software aktuell nicht infrage kommt. Da Microsoft auch nichts Vergleichbares anbietet, ist es kein Wunder, warum zumindest alle bekannten Sicherheitslösungen für Windows auf eigene Kernel-Treiber setzen.
Rust FTW?
Im Kontext des Crowdstrike-Fiaskos wurden auch vermehrt Rufe nach einem Umstieg auf "sichere Programmiersprachen" wie Rust laut. Das ist tatsächlich eine wichtige Aufgabe, die hoffentlich jetzt noch höhere Priorität bekommt. Denn mit Rust entfallen Speicherverwaltungsfehler weitgehend, die seit Jahrzehnten einen Großteil aller sicherheitsrelevanten Programmierfehler stellen. Doch auch das deckt nur einen Teil des Problems ab. Denn die Programmiersprache, in der man keine Fehler machen kann, die zum Absturz führen, gibt es nicht. Das gilt umso mehr, wenn ein Treiber mit unbeschränkter Allmacht Befehle ausführt, die als eiliges Update mit heißer Nadel gestrickt wurden.
Letztlich ist der Schlüssel zu mehr Resilienz eher allgemein in einer besseren Qualitätssicherung zu sehen. Trotzdem sollte Microsoft dazu nicht nur die eigenen Treiber möglichst zügig von C/C++ auf Rust migrieren, sondern auch Projekte wie windows-drivers-rs vorantreiben, die das auch anderen ermöglicht. Eine schnelle Verbesserung der Situation sollte man sich jedoch nicht davon versprechen.
Tipps fĂĽr Admins
Nach all den Dingen, die Microsoft und Hersteller wie Crowdstrike tun könnten und sollten, gibt es auch mindestens zwei Lehren, die sich jeder Administrator zu Herzen nehmen sollte: eine recht konkrete und eine eher allgemeine. Die meisten Fälle, in denen die Wiederaufnahme des Betriebs unverhältnismäßig lange dauerte, hatten mit Bitlocker zu tun. Das kam daher, dass der Workaround zur Beseitigung der erzwungenen Neustart-Schleife das Löschen der Update-Dateien im Windows-Ordner erforderte (genauer: windows\system32\drivers\crowdstrike\c-00000291*).
Ist jedoch das komplette Laufwerk mit Bitlocker verschlüsselt, kommt man "von außen" nicht an diese Dateien heran. Das ist natürlich genau der Sinn & Zweck der Verschlüsselung. Sie stellt sicher, dass etwa ein Dieb oder Finder eines Firmen-Laptops keinen Zugriff auf wichtige Firmendaten erhält. Um diesen Zugriff unabhängig vom installierten Windows zu erlangen, muss man zunächst den Wiederherstellungsschlüssel eingeben. Das gilt auch für den Windows-eigenen Wiederherstellungsmodus, in dem man die problematischen Dateien löschen kann.
Wer da bei der Schlüsselverwaltung geschlampt hat, zahlte beim Recovery vom Crowdstrike-Fail einen hohen Preis, der sich noch dazu mit der Zahl der verwalteten Systeme multiplizierte. Viele Produktionsausfälle ließen sich darauf zurückführen, dass es Probleme mit dem Besorgen und Eingeben der benötigten Wiederherstellungsschlüssel gab. Deshalb die erste Lehre für Admins: Nehmt das zum Anlass, euch Gedanken darüber zu machen, wo und wie ihr eure Bitlocker-Wiederherstellungsschlüssel lagert und wie der Zugriff in diversen Notfallszenarien erfolgen soll.
Mit Notfallszenarien im allgemeineren Kontext hat der zweite Tipp zu tun: Viele Probleme waren darauf zurückzuführen, dass sich zuvor niemand im Unternehmen Gedanken darüber gemacht hatte, wie man auf großflächige Ausfälle von IT reagieren kann. Somit mussten dann alle Maßnahmen unter allerhöchstem Stress und Zeitdruck konzipiert und ausprobiert werden. Lasst es nicht so weit kommen. Plant für verschiedene, nicht unwahrscheinliche Notfallszenarien im Voraus, welche Möglichkeiten zur Reaktion ihr habt und vor allem, was ihr dafür alles benötigt. Und übt das dann möglichst auch. Denn nur so findet ihr auch die Probleme, an denen das schöne Konzept in der Praxis dann doch scheitert.
Diskutieren Sie mit dem Autor und anderen Security-Professionals im heise security PRO-Forum
(ju)
