Wenn Bits und Bytes zum Arzt müssen – Diagnosedaten gegen die CrowdStrike Panne

Der Freitag der 19.07.2024 wird wohl weltweit vielen in Erinnerung bleiben: Es war der Tag an dem buchstäblich die Welt stillgestanden hat.

CrowdStrike verteilt weltweites fehlerhaftes Update

Doch was war passiert: Der Cybersecurity Hersteller CrowdStrike hat ein weltweites, aber leider fehlerhaftes Update auf geschätzt ca. 8.5 Millionen Geräte verteilt.
Die Folge davon: Betroffene Geräte zeigten einen Bluescreen of Death (BSOD) mit der Fehlermeldung PAGE_FAULT_IN_NONEPAGED_AREA an, ausgelöst durch die Datei csagent.sys: 

Nach dem automatischen Neustart folgt dann der nächste Bluescreen. Die Geräte waren in einer Endlosschleife gefangen. Durch diesen Fehler wurden ganze Firmen sowie Fabriken als auch Teile von kritischen Infrastrukturen stillgelegt. 

Wie kam es zu dem Fehler?

Die Suche nach dem Fehler wurde für viele Sicherheitsexperten zu einer kleinen Wochenendbeschäftigung. Es geisterten recht früh einige wilde Thesen durch das Internet, wonach es sich um eine sog. “Null-Pointer Exception” handeln könnte – diese Thesen wurden aber schnell wieder verworfen.

Der Hersteller selbst hatte sich nach dem Wochenende endlich zu Wort gemeldet und laut seiner Homepage wurden die massenhaften BSoDs (Bluescreen of Death) durch einen Speicherzugriffsfehler (out of bounds memory read) des Falcon Sensors ausgelöst. Bei diesem handelt es sich um einen mithilfe eines Windows-Treibers tief im Betriebssystem verankertes Überwachungsprogramms zum Schutz gegen Malware und Angriffe.

Wer wirklich diesen Fehler mit all seinen Facetten verstehen möchte, dem sei an dieser Stelle das folgende Video ans Herz gelegt: CrowdStrike IT Outage Explained by a Windows Developer (youtube.com) – es erklärt wunderbar, wie die Architektur von Windows mit Treibern funktioniert und wie es zu dem Problem kommen konnte.

Diagnosedaten & Updates in Wellen!

Unabhängig, dass es jetzt passiert ist, bin ich dennoch der Meinung, dass dieses Ausmaß einer weltweiten Störung hätte verhindert werden können. Die dafür notwendigen Technologien existieren bereits und werden vom Hersteller Microsoft schon viele Jahre eingesetzt.

Diagnosedaten

Die Diagnosedaten bei Microsoft sind Informationen, die pseudonymisiert gesammelt werden, um die Sicherheit, Leistung und Funktionalität von deren Produkten zu gewährleisten und zu verbessern. Man unterscheidet hierbei zwischen den sog. erforderlichen und optionalen Diagnosedaten. Die Daten helfen Microsoft zu erkennen, wo es Probleme gibt und wo nachgebessert werden muss. Mit dem EU Data Boundary liegen die Diagnoseendpunkte nun auch endlich in der EU, so dass es auch aus Datenschutzaspekten kaum noch Kritik am Sammeln dieser Daten geben sollte.

Schlussfolgerung in Bezug auf die CrowdStrike-Panne:
Offenbar hatte CrowdStrike einen solchen Mechanismus nicht in sein Produkt eingebaut. Sonst wäre bereits recht früh eine Rückmeldung über die Diagnosedaten an CrowdStrike zurückgekommen, dass mit dem ausgelieferten Update etwas nicht stimmt und man hätte schnell Gegenmaßnahmen ergreifen können und das Update stoppen können.

Staged Rollout – Updates in Wellen

Bei Servern sowie Endpunkten gibt es eine unendliche Anzahl möglicher Hard- und Software-Kombinationen. Was auf einem System gut funktioniert, muss nicht zwangsläufig auf allen Systemen klappen. Wie oben bereits beschrieben, helfen hier die Diagnosedaten, auf Probleme schnell reagieren zu können. Die auf diese Weise gewonnen Kenntnisse setzt Microsoft nämlich auch bei der Verteilung von Updates ein. Eine verbaute Komponente oder ein installiertes Programm können alleine oder in Kombination mit einem anderen Faktor nämlich dafür sorgen, dass der Update-Mechanismus “stumm” bleibt. Auch längere Zeit, nachdem der Rollout bereits angelaufen ist. Erst, wenn das zugrunde liegende Problem als gelöst markiert ist, wird das Update dann auch auf diesen Geräten angeboten.

Schlussfolgerung in Bezug auf die CrowdStrike-Panne:
Sicherlich hätte es eine kleine Gruppe gegeben, die diesen Fehler bekommen und ausbaden hätte müssen. Aber der sicherlich größte Teil der Geräte wäre wahrscheinlich von diesem Fehler verschont geblieben und wir hätten diese weltweite Katastrophe nicht in diesem Ausmaß erleben müssen.

Kernel-Zugriff

Es gibt aber meiner Meinung nach noch ein drittes Problem, das aber nicht nur allein CrowdStrike betrifft, sondern nahezu alle Sicherheitsplattformen: Der volle Zugriff auf den Windows-Kernel.
Gemäß Vereinbarung von 2009 zur Interoperabilität, die Microsoft mit der Europäischen Kommission getroffen hat, muss Microsoft seine APIs für Drittanbieter-Sicherheitssoftware zugänglich machen. Die jüngsten Probleme mit CrowdStrike haben jedoch weltweit die Frage aufgeworfen, warum Drittanbieter-Software auf so niedriger Ebene im Betriebssystem laufen darf, wo Fehler schwerwiegende Folgen haben können.

Der Kernel bei Betriebssystemen verwaltet Speicher, Prozesse, Dateien und Geräte und ist im Grunde das Herzstück des Betriebssystems. Bei Mac- und Linux-Rechnern trat dieser Fehler nicht auf, weil eine auf diesen Systemen installierte Software keinen Zugriff auf das Kernelmodul hat. Vielmehr gibt der Kernel bei Apple und bei Linux einen Report aus, den dann Sicherheitstools, wie “CrowdStrike” oder “Defender for Endpoint” z.B. nur auslesen und analysieren können. Der eigentliche Zugriff auf den Kernel ist aber untersagt. Somit wäre durch diese Architektur des Windows-Betriebssystems ein solcher Fehler ebenfalls vermeidbar gewesen, weil technisch nicht möglich.