Transkript
Lisa: Hallo und herzlich willkommen zu einer neuen Episode vom INNOQ Security Podcast. Heute sprechen Christoph und ich, Lisa, über ein sehr aktuelles Thema, das erst am 19. Juli 2024 geschehen ist, also letzten Freitag, wenn man von unserer Aufnahme gerade ausgeht. Hallo Christoph, was ist denn da passiert, über das wir heute reden möchten?
Christoph: Hallo Lisa. Ja, ich glaube, dass die meisten Hörer und Hörerinnen werden das auch mitbekommen haben. Daran konnte man eigentlich nicht vorbeigehen, es sei denn, man hat völlig digital detox gemacht. Das war in allen Medien, auch in den typischen Mainstream-Medien, also Fernsehen und Zeitungen, die ja sonst nicht so viel über IT berichten, aber das war wahrscheinlich der größte Ausfall in der IT-Geschichte. Und zwar war es so, dass CrowdStrike dafür gesorgt hat, mit einem Update, dass ganz viele Windows-Rechner weltweit einen Bluescreen of Death hatten. Also so einen, wie man ihn kennt, bei dem dann gar nichts mehr unter Windows funktioniert. Ja, das hat für erhebliche Einschränkungen aller Art gesorgt.
Lisa: Genau, und erst mal hört sich das gar nicht so schlimm an. Ich meine, wenn jetzt mein Schwiegervater einen Bluescreen hat, dann interessiert mich das nicht so sehr. Aber warum hat das denn so große Wellen geschlagen?
Christoph: Ja, also das Problem ist nicht nur, dass deine Verwandten vielleicht Windows nutzen, sondern ganz viele Industrien und Branchen nutzen Windows. Und das hat ganz viele von denen getroffen. Da waren Banken dabei, der Einzelhandel, der keine Kartenzahlung mehr annehmen konnte, Hotels, in denen man nicht einchecken konnte. In England waren TV-Sender betroffen, die eine kurze Zeit nicht senden konnten. Ganz viel hat man an den Flughäfen gemerkt, wo die Abfertigungssysteme nicht mehr funktioniert haben und die ganzen Info-Terminals dann diesen Bluescreen of Death angezeigt haben. Auch die Airlines selber waren betroffen, vor allem in den USA, wo viele Flugzeuge landen mussten und nicht starten konnten. Krankenhäuser, was ja besonders schlimm ist, waren ebenfalls betroffen, da sind ja Menschenleben in Gefahr. Operationen mussten zuhauf aufgeschoben werden. In den USA gab es Probleme mit Blutspenden, die nicht verteilt werden konnten. Teilweise ist auch die Notrufnummer in einigen Regionen ausgefallen. Und hier in Deutschland gab es laut BSI Meldungen aus allen Bereichen der kritischen Infrastruktur, die von diesem Problem bei CrowdStrike betroffen waren. Also das war wirklich erheblich. Man schätzt, dass etwa 8,5 Millionen Geräte betroffen waren. Das klingt vielleicht nach nicht viel im Vergleich zur gesamten Installationsbasis von Windows, etwa ein Prozent, aber leider waren es eben nicht Geräte von Onkel Winnie und Tante Erna, sondern Geräte in Bereichen, die Infrastruktur aller möglichen Arten bereitstellen, sodass das jeder mitbekommen hat. Die ersten Schätzungen des Schadens belaufen sich auf etwa 5,5 Milliarden Dollar. Einige sagen, dass es größer ist als jede Malware-Attacke, die wir bisher hatten, wie z.B. NotPetya oder Ähnliches, die wir auch schon mal in unseren Folgen behandelt haben.
Lisa: Boah.
Christoph: Ja, dass das einen viel größeren wirtschaftlichen Schaden verursacht hat. Deshalb schlägt das jetzt so verdammt große Wellen und wird uns wahrscheinlich auch in den nächsten Wochen noch weiter beschäftigen, auch mit den ganzen Nachwirkungen und Dingen, die da vielleicht noch kommen. Es gibt möglicherweise auch Bereiche, wo wir noch gar nicht wussten, dass es zugeschlagen hat.
Lisa: Aber das Gute daran ist, dass wir das jetzt aufnehmen und nicht schon am Freitag aufgenommen haben. Jetzt kannst du mir auch erklären, was da technisch passiert ist, weil diese ganze Sache jetzt ein bisschen abgehangen ist und mehr ans Licht gekommen ist.
Christoph: Das stimmt. Also wir wissen jetzt, was passiert ist, zum größten Teil zumindest. Wir kennen den technischen Fehler, der zu diesem Bluescreen of Death geführt hat. Warum das aber bei CrowdStrike selbst passiert ist, also welche fehlenden Qualitätssicherungsmaßnahmen dort eine Rolle gespielt haben, das ist noch nicht ganz klar, obwohl sie schon eine Meldung herausgegeben haben, in der sie den Vorgang etwas dokumentiert haben. Aber da bleiben noch Fragen offen. Vielleicht fangen wir erst mal damit an, was überhaupt passiert ist. Oder wir klären zuerst, was CrowdStrike überhaupt ist, weil das ja nicht jeder unserer Zuhörer und Zuhörerinnen unbedingt wissen muss.
Lisa: Ja, gerne.
Christoph: CrowdStrike ist eine Firma, die im Security-Bereich tätig ist. Eines ihrer Hauptprodukte, oder wahrscheinlich das Hauptprodukt, ist Falcon, und um das geht es hier. Falcon ist eine sogenannte EDR, eine Endpoint Detection and Response Plattform, das ist neudeutsch für Anti-Virus- oder Anti-Malware-Software, also so eine Art Virenscanner, der auf den jeweiligen Endgeräten feststellen soll, ob irgendetwas Ungewöhnliches vorgeht, was ein Angriff sein könnte, wie ein Malwarebefall oder Virenbefall.
Lisa: Mhm.
Christoph: Also „Detection“ heißt, es meldet das dann irgendwo hin, damit man den betroffenen Endpoint vielleicht isolieren kann, abschalten kann, vom Netz trennen kann. Und „Response“ bedeutet, dass es vielleicht auch selbstständig agieren kann, indem es den Angriff abwehrt, zum Beispiel, indem es den Prozess killt, der einem Malwareprozess zugeordnet wird, oder es trennt sich selbst vom Netz oder so etwas in der Art. Das kann je nach Produkt unterschiedlich sein. EDR ist also der Oberbegriff für solche Systeme, und Falcon ist das Produkt von CrowdStrike dafür. Genau. Und das hat jetzt ein Update bekommen. Das Produkt besteht aus mehreren Teilen: einmal aus dem Sensor, der das eigentliche Programm ausführt, und dann gibt es noch verschiedene Konfigurationsdateien. Im alten, klassischen Virenscanner nennt man das Signaturdateien. Da sind bekannte Viren codiert, und das wird ständig geupdatet, weil immer neue Viren hinzukommen. Das eigentliche Programm hat jedoch einen größeren Updatezyklus. Genau so war es auch hier. Das eigentliche Programm wurde gar nicht geupdatet, sondern nur diese Konfigurationsdateien. Aber die haben trotzdem dafür gesorgt, dass das System so abgestürzt ist, dass auch ein Neustart nicht geholfen hat. Woran liegt das? Damit diese EDRs vernünftig funktionieren, müssen sie mit besonderen Rechten laufen. Sie müssen ja den gesamten Computer überwachen können.
Lisa: Mhm.
Christoph: Normalerweise will ich nicht, dass ein Prozess andere Prozesse überwachen kann oder mit ihnen etwas anstellen kann. Deshalb werden sie isoliert, aus Sicherheitsgründen, damit ein Programm nicht ein anderes stört und Malware nicht viel anrichten kann. Wenn ich jedoch so ein System überwachen will, brauche ich Komplettzugriff. Den kann ich bekommen, indem ich innerhalb des Kernels laufe, also innerhalb des Windows-Kernels. Der Windows-Kernel hat den vollen Zugriff auf alles. Er steuert alle anderen Programme, das Betriebssystem steuert alle anderen Programme, und dadurch hat er natürlich viel mehr Zugriffsmöglichkeiten. Das Betriebssystem läuft also im sogenannten Kernel Space, und alle anderen Programme laufen im User Space. Damit kommen besondere Privilegien ins Spiel. Zum Beispiel kann ein Userspace-Programm nur seinen eigenen Speicher sehen, aber ein Programm im Kernel Space kann den gesamten Speicher des Computers sehen, einschließlich aller anderen Prozesse. Für ein funktionierendes Betriebssystem gibt es eigentlich keine Alternative dazu; mindestens ein minimaler Teil muss im Kernel Space laufen. Bei CrowdStrike wurde das Falcon-Produkt als Windows-Treiber implementiert. Ein Treiber unter Windows, der ja auch sehr hardware-nah laufen muss und auf alles Mögliche zugreifen können muss, läuft auch im Kernel Space oder im Kernel Mode. Er hat dadurch besondere Rechte und kann seine Überwachungsfunktionen entsprechend ausführen.
Lisa: Ich wollte gerade eben noch fragen, was noch so im Kernel Mode läuft und nur, dass ich es richtig verstehe: Also wenn es ein Treiber ist, wie zum Beispiel ein Grafiktablett von Wacom, das ich mir gekauft habe und wofür ich einen Treiber installieren musste, würde dieser dann auch im Kernel Mode installiert werden, damit er die richtigen Zugriffsberechtigungen hat?
Christoph: Ja, das kommt ein bisschen darauf an. Bei Eingabegeräten kann das auch ein Userspace-Programm sein. Wenn du zum Beispiel ein Eingabegerät hast, das über USB oder Bluetooth angeschlossen wird, dann laufen das USB- oder das Bluetooth-System innerhalb des Betriebssystems im Kernel Mode.
Lisa: Ah, okay. Aber er greift dann…
Christoph: Genau. Die übernehmen die Eingaben, und daran könnte sich ein Treiber im Userspace ankoppeln, der diese Eingaben nochmal besonders verarbeitet, zum Beispiel bei einem Grafiktablett. Es könnte auch bei Spezialtastaturen der Fall sein, die besondere Anforderungen haben. Das würde wahrscheinlich eher im Userspace geschehen, aber der USB-Teil zum Beispiel, der wäre dann im Kernel Mode.
Lisa: Okay, der Drucker war auch das Erste, was mir einfiel, aber ich musste sehr lange keinen Treiber mehr für einen Drucker installieren.
Christoph: Früher liefen Druckertreiber immer im Kernel Mode und haben unter Windows viele Probleme verursacht. Microsoft hat das jedoch aufgetrennt, und die Druckertreiber laufen jetzt im Userspace, während das Ansprechen der Hardware bereits implizit im Betriebssystem integriert ist. Man trennt das, wenn die API-Oberfläche klar
ist, also was genau benötigt wird. In diesem Fall geht das jedoch nicht so gut, wenn man den gesamten Computer überwachen will.
Lisa: Ja, da musst du einfach eine gewisse Macht und eine gewisse Übersicht mitbringen.
Christoph: Genau. Das Problem ist, wenn etwas im Kernel abstürzt, dann stürzt das gesamte System ab. Wenn das Betriebssystem abstürzt, beendet es sich, und in Windows sieht man dann den Bluescreen of Death, den wir alle schon mal gesehen haben. In macOS und Linux oder Unix-artigen Betriebssystemen nennt man das eine Kernel Panic. Dann ist auch alles vorbei, weil wenn etwas innerhalb des Betriebssystems korrumpiert wird, sollte man einfach nicht weitermachen, auch wenn man es abfangen könnte. Normalerweise ist die Reaktion, dass man sagt, etwas ist schiefgelaufen, also sollte man neu starten. Ein normaler Prozess hingegen stürzt einfach ab, und alle anderen Programme laufen weiter.
Lisa: Ja genau, die sind ja nicht betroffen.
Christoph: Da gab es jetzt einen Fehler, und man weiß auch, was der Fehler war. Diese Signaturupdates, die CrowdStrike anders nennt – sie nennen sie Channel Files – hatten neue Konfigurationen. In den Presseberichten und ihrer eigenen Pressemitteilung gibt es sogenannte Channel Files, in denen codiert ist, welches Verhalten vielleicht auffällig ist und auf das dieser Sensor reagieren soll. Diese müssen natürlich auch irgendwie eingelesen werden. Leider hat man eines dieser Dateien ausgeliefert, das voller Nullen war. Es besteht aus mehreren Dateien, und eine davon war voller Nullen. Beim Einlesen gibt es dann einen Nullpointer, weil ein Nullpointer auch mit nur Nullen dargestellt wird. Die Speicheradresse, die bei Null beginnt, wird normalerweise gar nicht verwendet.
Lisa: Hm.
Christoph: Ein normales Programm wird irgendwo im Speicherbereich eingeblendet und hat dann eine Speicheradresse, die jedenfalls nicht nur aus Nullen besteht. Um einen Nullpointer, also „gibt es nichts zu sehen“ darzustellen, verwendet man Null. Wenn die Datei eingelesen wird, wird diese Null verwendet, um einen Pointer daraus zu dereferenzieren. Eigentlich hätte man dort valide Daten erwartet, aber diese Nullpointer-Dereferenzierung führte unweigerlich zum Absturz. Wenn der Kernel abstürzt, stürzt das gesamte System ab, und es erscheint ein Bluescreen. Das war das Problem, und das ist natürlich nicht gut. Wenn man sich das insgesamt ansieht, ist es eigentlich eine ziemlich schwierige Idee zu sagen: „Wir nutzen etwas, das alles kann, um Software sicher zu machen.“ Denn dadurch erhöhen wir die Angriffsfläche ungemein. Das System kann alles, aber wenn es einen Fehler enthält, den man ausnutzen kann, dann kann man damit natürlich auch alles machen. An der Stelle vergrößern wir die Angriffsfläche ungemein, was eigentlich eine relativ komische Idee ist. Es gibt sogar einen Vergleich, den ich auf Mastodon gefunden habe. Er ist älter als dieses Ereignis, wurde aber jetzt wieder hochgespült. Der Unterschied zwischen einem EDR-System und Malware ist gar nicht so groß, denn beide wollen mit erhöhten Rechten laufen und alles machen können. Es gibt eine schöne Tabelle, in der das gegenübergestellt wird. Man kann es kaum auseinanderhalten. Eigentlich kann ein EDR-System genau das, was Malware kann, was natürlich schlecht ist, weil Malware das System dann übernehmen könnte. Wir hatten jetzt das Glück, dass nur ein Programmfehler zum Absturz geführt hat, aber andere Programmfehler könnten ausgenutzt werden, um den Scanner zu übernehmen und zu missbrauchen. Das ist auch schon bei anderen Anti-Viren-Herstellern oder EDR-Herstellern passiert, dass dort Programmierfehler es ermöglicht haben, das System zu übernehmen und damit vollen Zugriff zu bekommen.
Lisa: Aber wenn das doch so gefährlich ist und eigentlich eine blöde Idee, warum macht man das dann überhaupt?
Christoph: Ja, das fragt man sich aus der Security-Perspektive auch. Eigentlich wissen das auch viele, die in der Security arbeiten, dass das eine dumme Idee ist. Aber das Problem ist, dass man oft gewisse Compliance-Anforderungen erfüllen muss. Diese Compliance soll eigentlich dafür sorgen, dass man ein sicheres System hat. Aber das Problem ist, dass diese Compliance genau solche Sachen verursacht, die das System unsicherer machen. Ein einfaches Beispiel: Ich könnte ja sagen, ich nutze solche Software gar nicht. Wenn wir uns den BSI-Grundschutz, IT-Grundschutz ansehen, dort gibt es einen Abschnitt über Anti-Viren-Software und Malware-Erkennung. Da steht drin, dass es eine Erkennung geben muss, es sei denn, man kann die anders ausschließen. Zum Beispiel, wenn ich ein System habe, das airgapped ist, also gar nicht am Netz hängt, könnte ich das vielleicht ausschließen. Oder ich habe einen minimalen Controller, der kein Betriebssystem hat, wo solche Sensoren nicht viel bringen. Es gibt ein paar Szenarien, in denen man sagen kann, dass es nicht geht, aber ansonsten steht dort ein deutliches „Muss“. Das ist noch das einfachste Compliance-Beispiel. Es gibt noch viel mehr gesetzliche Regelungen, gerade im Bereich kritischer Infrastrukturen, also bei Kritis-Systemen. Da gibt es auch neue Regelungen, die NES2 genannt werden, die gerade im Bundestag und Bundesrat debattiert werden und viel Kritik hervorrufen. Es gibt Regulierungen für den Zahlungsverkehr, für IT-Systeme im Zahlungsverkehr, für Gesundheitssysteme und so weiter. Dort steht oft, dass eine Erkennung verpflichtend ist. Dann kaufe ich ein solches Produkt ein und kann sagen, dass ich damit die Compliance erfülle. Es wird nicht auf echte Sicherheit geachtet, die ich vielleicht anders erreichen könnte, sondern es wird geschaut, ob ich die Audit-Prüfungen bestehe. Die Auditoren schauen dann, was man dagegen macht. Wenn ich keinen Virenscanner habe, wird gefragt: „Warum nicht?“ Da muss man das gut mit anderen Verfahren begründen können, sei es auf Prozessebene oder anders, um sich zu schützen.
Lisa: Das macht jetzt auch mehr Sinn, warum gerade Banken, Flughäfen, Krankenhäuser und so weiter betroffen waren, weil die ja dieser ganzen Audit-Geschichte unterliegen, ne?
Christoph: Ja, und das Lustige am Rande ist, dass in den AGBs von CrowdStrike, die wir auch verlinken, ein Abschnitt steht, dass das Produkt nicht in Aviation-Systemen oder anderen kritischen Systemen eingesetzt werden soll, wo Leben gefährdet sind. Das steht in All Caps, in den AGBs, während der Rest normal geschrieben ist. Sie sagen also selbst, dass sie eigentlich nicht in solchen Systemen eingesetzt werden wollten, weil sie vielleicht wissen, welche Risiken das mit sich bringt.
Lisa: Ach verrückt.
Christoph: Ja, und jetzt sind die Leute, die sich um Compliance kümmern müssen, in einer Zwickmühle. Ich schätze mal, dass es bei anderen Herstellern nicht anders aussieht. Auch die geben keine Garantien dafür und schließen solche Einsatzbereiche aus. Andererseits wird es oft vorgeschrieben. Das ist eigentlich völliger Wahnsinn. Meine Meinung ist, Compliance sorgt nicht wirklich für Sicherheit, sondern Compliance sorgt nur für Compliance.
Lisa: Ja. Was mich so ein bisschen wundert, ist, dass das bei einem Audit nicht schon vorher aufgefallen ist. Die Auditoren sollten doch eigentlich wissen, ob bestimmte Dinge eingesetzt werden dürfen oder nicht. Wenn CrowdStrike von vornherein sagt, setzt uns bitte nicht in kritischen Bereichen ein, hätte ich erwartet, dass jemand mal diese AGB gelesen hat und dann eine Meinung dazu gebildet hat, dass man das vielleicht besser nicht einsetzt.
Christoph: Das weiß ich nicht. Wie gesagt, ich glaube, das steht bei den anderen auch drin, und ich glaube nicht, dass die Auditoren alle AGBs kennen, die es so gibt. Es kann auch sein, dass es Zusatzvereinbarungen in Einzelverträgen gibt, die so etwas dann doch erlauben. Aber man hört jetzt nicht, dass CrowdStrike groß dafür einstehen würde, dass es solche Verträge gibt und sie zahlen müssen. Das Einzige, was man gemerkt hat, ist, dass der Aktienkurs erst mal um 20 Prozent eingebrochen ist. Aber im letzten Jahr hatte er vorher um 100 Prozent zugelegt. Von daher, wenn man da vorher investiert hatte, ist man immer noch gut raus. Das wird wahrscheinlich so ähnlich wie bei anderen Skandalen sein, wie BSE oder Pferdefleisch in der Lasagne. Es wird drei Monate dauern, dann kauft es keiner mehr, aber danach ist alles wieder gut, und dann setzt man es wieder ein. Beim nächsten Vertragsverhandlung für die nächsten Lizenzen wird es vielleicht ein bisschen billiger, aber auf lange Frist wird sich wahrscheinlich wenig ändern, und man nimmt es dann trotzdem.
Lisa: Und du hattest eingangs erwähnt, dass viele Windows-Rechner einen Bluescreen hatten. Wenn man das so hört, hätten Krankenhäuser und die betroffenen Firmen dann vielleicht besser auf Linux setzen sollen, und wäre das dann gar nicht passiert?
Christoph: Ja, wahrscheinlich wäre es nicht in dieser Form passiert, weil es das CrowdStrike-Produkt auch für Linux gibt, und die waren jetzt nicht betroffen.
Lisa: Mhm.
Christoph: Unter Linux gibt es auch andere Möglichkeiten, die nicht so gefährlich sind, wo man nicht im Kernel Mode laufen muss. Aber CrowdStrike hatte, und das ist noch gar nicht lange her, auch in ihrem Linux-Sensor ein Problem, das vor ein paar Monaten zu einer Kernel Panic führte. Das betraf jedoch nur bestimmte Red Hat-Versionen und bestimmte Debian- und Rocky Linux-Versionen, die ein Derivat von Red Hat sind. Es
war also ein begrenztes Problem, das nicht viel Aufmerksamkeit erregt hat. Ich habe das jetzt auch erst im Nachhinein durch die Recherche mitbekommen. Bei dem Linux-Problem war es ein Fehler im Linux-Kernel, ein Bug, der das ausgelöst hat. CrowdStrike war nicht schuld, sie haben es nur getriggert. Aber das hätte bei Tests auffallen müssen. Die betroffenen Versionen waren scheinbar nicht in der Testmatrix von CrowdStrike enthalten. Da fragt man sich, welche Windows-Versionen eigentlich in der Testmatrix enthalten waren.
Lisa: Ja, das hätte beim Testen durchaus auffallen müssen, hätte ich vermutet. Ich hätte auch gedacht, dass man genug testet, wenn man so eine kernalnahe Software entwickelt, die so viele Zugriffsrechte hat. Da ist ja einfach die Gefahr groß, dass man etwas kaputt macht.
Christoph: Ja, das Lustige ist, in der Mitteilung von CrowdStrike steht, was sie an Tests gemacht haben. Aber es bleibt unklar, ob sie diese Tests schon jetzt durchführen oder ob sie das in Zukunft vorhaben. Da können wir vielleicht gleich noch einmal darauf eingehen, wenn wir darüber reden, was man anders machen könnte. Testing ist dabei sicherlich auch ein Thema.
Lisa: Ja, verrückt. Und es ist nicht nur so, dass viele Leute betroffen sind und es ein echt doofer Fehler war, der viel lahmgelegt hat. Es ist auch gar nicht so leicht für die Betroffenen, da wieder rauszukommen, oder?
Christoph: Ja, das macht es noch viel schlimmer und erklärt die großen Auswirkungen. Die Zeit war recht kurz, in der dieses Update ausgerollt wurde und man gemerkt hat, dass etwas nicht stimmt. Es war etwas über eine Stunde, wie man in dem CrowdStrike-Bericht sehen kann. Wahrscheinlich wären sonst auch viel mehr Systeme betroffen gewesen. Aber das Problem ist, wenn ein Gerät einen Bluescreen of Death hat und wieder bootet, führt der Kernel-Treiber wieder zum Absturz. Man kommt da nicht raus, jedenfalls nicht remote, sondern man braucht physischen Zugang. Was muss man machen? Man muss im Safe Mode booten. Im Safe Mode wird ein minimales Betriebssystem mit minimalen Treibern gestartet. Dann muss man diese Update-Dateien manuell entfernen, und dann kann man wieder normal booten. Aber wie gesagt, man braucht physischen Zugang. Wenn man sich vorstellt, dass es solche Anzeigeterminals an Flughäfen gibt, wo man auf Leitern klettern muss, um das Gehäuse aufzuschrauben und eine Tastatur anzuschließen, ist das nicht einfach. Das Zweite, was es so schwer gemacht hat, ist, dass viele dieser Systeme mit BitLocker verschlüsselt sind. Bevor man im Safe Mode booten kann, muss man den BitLocker-Recovery-Key eingeben, um das System zu entschlüsseln. Und den hat man vielleicht nicht für jedes Terminal zur Hand. Der Umgang mit solchen Secrets ist schwer, besonders wenn man das nicht regelmäßig macht. Da gab es dann auch Probleme. Einige Admins hatten die Keys zentral gespeichert, andere nicht, und manchmal sind sie vielleicht verloren gegangen. Es gab kreative Lösungen, bei denen Leute ein Skript geschrieben haben, um den Key als Barcode auszugeben, damit man ihn mit einem Barcode-Scanner eingeben kann. Das ist eine lange Zeichenkette, die man nicht einfach so eintippt. Im Rechenzentrum ist es vielleicht einfacher, da gibt es Keyboard-Switches und andere Konsolen, die remote zugänglich sind. Aber bei den öffentlich zugänglichen Terminals war das eine echte Herausforderung, was die Sache so lange gemacht hat. Die eigentliche Lösung war einfach: Man musste eine bestimmte Datei löschen, in der das Update enthalten war, das den Nullpointer-Fehler verursacht hat. Microsoft stellt jetzt auch ein Tool zur Verfügung, das das automatisch macht, aber es war relativ einfach, wenn man erst einmal an den Rechner herankam.
Lisa: Ja krass. Und das ganze Update war ein automatisches Update, oder?
Christoph: Ja, genau. Es war ein automatisches Update, weil du bei einem Virenscanner ja immer die neuesten Signaturen haben möchtest, um aktuelle Bedrohungen zu erkennen. Da will man schnelle Updates haben. Leider war dieses Update fehlerhaft und hat das System kaputt gemacht.
Lisa: Es wären wahrscheinlich auch nicht so viele Leute betroffen gewesen, wenn es ein manuelles Update gewesen wäre, oder wenn man es nacheinander ausgerollt hätte.
Christoph: Genau. Bei normalen Windows-Updates kann man das ein bisschen steuern. Privatanwender weniger, aber in Firmennetzwerken können die Administratoren steuern, wann die Updates kommen und sie vorher testen. Das war hier nicht so gut möglich. Es gibt zwar einige Einstellungsmöglichkeiten, bei denen man zum Beispiel N-1 oder N-2 wählen kann, also ein paar Versionen hinterherbleiben kann. Aber das will man bei einem Virenscanner eigentlich auch nicht, weil das die Sicherheit beeinträchtigen könnte. Ich hatte ja am Anfang gesagt, dass man den Schaden auf 5,5 Milliarden Dollar schätzt. Das ist die aktuelle Schätzung.
Lisa: Muss CrowdStrike jetzt Schadensersatz zahlen? Ich meine, das sind ja Milliardenverluste weltweit gesehen. Eine Bekannte von mir war auch betroffen.
Christoph: Das ist schwer zu sagen. Erst einmal berufen sie sich auf ihre AGB, in denen solche Dinge ausgeschlossen sind. Und wenn dann auch noch drin steht, dass du es in deinem Fall gar nicht hättest einsetzen dürfen, weil du zum Beispiel in einem Krankenhaus oder bei einer Fluggesellschaft bist, wird es vielleicht schwierig. Letztendlich werden das die Gerichte irgendwann entscheiden. Es gibt schon Androhungen von Klagen, auch hier aus Deutschland, von Krankenhäusern, die sagen, dass sie Schadensersatz benötigen. Ob CrowdStrike dafür aufkommen muss oder eine Versicherung einspringt, ist unklar. Was aber bekannt ist, ist, dass Cyberversicherungen dafür nicht aufkommen werden, weil es kein Angriff war. Und für andere Störungen kommen sie nicht auf. Es gibt ein gemeinsames Statement der Versicherungswirtschaft, in dem sie sagen, dass sie nicht zahlen werden. Wahrscheinlich wird das vor Gericht ausgefochten, aber die meisten werden wohl auf ihrem Schaden sitzen bleiben, gerade kleinere Firmen, die sich nicht lange Gerichtsverfahren leisten können.
Lisa: Ja, das macht es für kleine Unternehmen noch schwieriger.
Christoph: Genau. Ich meine, die größeren Firmen könnten sich das vielleicht leisten, aber im Zweifelsfall bleiben die Leute wohl auf ihrem Schaden sitzen.
Lisa: Verrückt. Tut mir leid, dass ich gerade so kichern musste. Ich hatte die ganze Zeit diese Szene aus Little Britain im Kopf, wo immer gesagt wird: „Computer sagt nein.“ Und ich stelle mir vor, wie man bei der Versicherung anruft und sagt, dass man Millionenverluste gemacht hat, und dann sagt der Computer: „Nein.“ Sorry, CrowdStrike.
Christoph: Wahrscheinlich sagt der Computer nichts und zeigt nur einen Bluescreen, weil auch die Versicherungen betroffen waren. Viele Versicherungen gehören ja zur kritischen Infrastruktur und müssen solche Systeme einsetzen. Es gab sicherlich auch dort Betroffene.
Lisa: Stimmt. Und die haben auch Audits. Das ist echt krass. Gibt es schon irgendwelche Bösewichte, die das ausnutzen?
Christoph: Wie immer bei großen Ereignissen gibt es in der IT irgendwelche Trittbrettfahrer, die das ausnutzen. Es wurden viele Domains registriert, die CrowdStrike im Namen haben und Abhilfe versprechen. Diese Seiten sehen aus wie die CrowdStrike-Homepage oder die Microsoft-Homepage und bieten Removal-Tools an oder verlangen, dass man seine Daten hinterlässt. Diese Removal-Tools sind natürlich selbst Malware, die sich installiert und wahrscheinlich auch den Bluescreen behebt, aber dafür ihre eigene Malware installiert. Es gibt auch Phishing-Seiten, auf denen man sich in seinen Kunden-Login einloggen soll, um zum Beispiel die BitLocker-Keys zu bekommen. Also das Übliche bei solchen Ereignissen: IT-Bösewichte sind immer schnell dabei.
Lisa: Wie hätte man das technisch anders lösen können, damit das alles nicht in dem Maße passiert wäre?
Christoph: Da gibt es verschiedene Aspekte. Einmal auf der Seite von CrowdStrike: Man fragt sich, warum das beim Testen nicht aufgefallen ist. In ihrer Mitteilung sprechen sie von verschiedenen Testmethoden, die sie verwenden, darunter ein Content Verifier, der die Updates validiert. Aber es gab wohl einen Bug in diesem Verifier, der es ermöglicht hat, dass ein fehlerhaftes Update herausgegeben wurde. Man fragt sich, ob sie keine Testumgebung haben, in der sie solche Updates intern einspielen und merken, dass die Systeme abstürzen. Wenn sie das nicht haben, könnten sie den Update-Prozess verbessern, indem sie das Update nach und nach ausrollen, zum Beispiel erst an ein Prozent der Kunden, dann an weitere Prozent, und so weiter. Sie sammeln ja unglaublich viele Telemetriedaten, und man könnte das dann vorher merken. Das scheint es nicht gegeben zu haben. Der Update-Prozess muss also verbessert werden. Das müsste eigentlich intern auffallen, dass das Update nicht funktioniert, und spätestens bei einem gestaffelten Rollout müsste man merken, dass etwas schiefgeht. Ein weiterer Punkt ist, dass es 2024 eigentlich nicht mehr passieren sollte, dass man nicht auf Nullpointer prüft. Das ist ein klarer Programmierfehler. Ein einfacher Check hätte ausgereicht, um das Problem zu verhindern. Außerdem könnte man überlegen, ob man im Kernel nicht mehr C oder C++ verwendet, sondern eine sicherere Programmiersprache. Microsoft bietet ein Framework an, mit dem man Treiber in Rust schreiben kann, das auch für Linux genutzt werden kann
. Solche Programmierfehler könnten damit verhindert werden. Man könnte auch Fast-Testing einsetzen, also das System mit Müll bombardieren und sehen, wie es reagiert. Es gibt also viele Möglichkeiten, wie man das an dieser Stelle besser machen könnte. Es gibt auch noch andere technische Ansätze. Unter Linux gibt es zum Beispiel das eBPF-Framework, das ursprünglich für Firewalls entwickelt wurde, aber inzwischen für viele andere Zwecke genutzt wird. Damit kann man sich in bestimmte Teile des Kernels reinhängen und zum Beispiel auf Netzwerkpakete oder Systemcalls reagieren. Man kann Programme in einer eingeschränkten Programmiersprache schreiben, die verifiziert wird, bevor sie im Kernel geladen werden. Das minimiert den Schaden. CrowdStrike nutzt das bereits in ihrer Linux-Lösung.
Lisa: Ach, da waren wir vorhin schon.
Christoph: Genau. Sie nutzen sowohl Kernel-Module als auch eBPF-Programme. Der Kernel-Treiber ist aber nicht vollständig abgelöst, und der eBPF-Verifier hatte einen Bug, der das Problem ausgelöst hat. Trotzdem ist das ein vielversprechender Weg für die Zukunft. Wenn alle diesen Ansatz nutzen und ein Bug im Verifier behoben wird, ist das Problem für alle behoben, und nicht jeder Hersteller muss seine eigenen Treiber fixen. Das minimiert die Angriffsfläche. Eine andere Möglichkeit wäre, wie es macOS macht. Dort wurden früher Kernel Extensions genutzt, die jetzt durch System Extensions ersetzt wurden, die im Userspace laufen und eine definierte API haben. Das ist eine Möglichkeit, das Betriebssystem besser zu schützen, indem man die Privilegien begrenzt. Ob das für Windows ausreichen würde, weiß ich nicht, aber es ist eine Möglichkeit. Es gibt aber auch einen interessanten Twist dabei: Microsoft hat selbst gesagt, dass die EU schuld ist, weil sie in ihren Regulierungen festgelegt hat, dass andere Hersteller denselben Zugang zum Kernel haben müssen wie Microsoft selbst. Das hat Microsoft schnell genutzt, um zu sagen, dass die EU schuld sei.
Lisa: Oh, das ist ein interessanter Punkt.
Christoph: Ja, das ist wirklich interessant. Microsoft musste den anderen Anbietern von Sicherheitssoftware den Zugang zum Kernel gewähren, damit sie gleiche Wettbewerbsbedingungen haben. Das heißt, die anderen Hersteller können auch Kernel-Module entwickeln, um ihre Sicherheitssoftware auf demselben Niveau wie Windows Defender zu betreiben. Und dadurch entstehen eben solche Risiken, wie wir sie jetzt bei CrowdStrike gesehen haben.
Lisa: Das klingt nach einem ziemlich komplexen Thema mit vielen Facetten. Gibt es denn irgendetwas, was man als Endnutzer oder auch als Unternehmen tun kann, um sich vor solchen Risiken zu schützen?
Christoph: Ja, das ist tatsächlich schwierig. Für Endnutzer bleibt oft nur, die angebotenen Updates zu akzeptieren und darauf zu vertrauen, dass die Hersteller ihre Arbeit gut machen. Unternehmen können allerdings darauf achten, dass sie eine robuste IT-Sicherheitsstrategie haben, die nicht nur auf einzelnen Tools beruht, sondern auf einer Kombination von Maßnahmen. Dazu gehören regelmäßige Audits, unabhängige Sicherheitsüberprüfungen und ein starkes Incident-Response-Team, das im Ernstfall schnell reagieren kann. Wichtig ist auch, sich nicht nur auf ein einziges Sicherheitstool zu verlassen, sondern eine mehrschichtige Sicherheitsarchitektur aufzubauen, die verschiedene Technologien und Verfahren kombiniert.
Lisa: Das ist ein guter Hinweis. Vielen Dank, Christoph, dass du dir die Zeit genommen hast, uns das alles zu erklären.
Christoph: Sehr gerne, Lisa. Es war mir ein Vergnügen, und ich hoffe, dass unsere Zuhörerinnen und Zuhörer aus dieser Episode etwas mitnehmen konnten.
Lisa: Das hoffe ich auch. Vielen Dank an alle, die heute zugehört haben, und bis zum nächsten Mal.