CrowdStrike veröffentlicht Untersuchungsbericht und bleibt Antworten schuldig
Ein Blogartikel zum fehlerhaften Update beim Falcon Sensor erläutert haarklein den Testprozess der Software – nicht aber den der fatalen Regel-Aktualisierung.
(Bild: Below the Sky/Shutterstock.com)
Nach tagelangem Rätselraten über die Ursache des massiven IT-Ausfalls am vergangenen Freitag wagt sich der Verursacher, das US-Sicherheitsunternehmen CrowdStrikes, nun aus der Deckung. In einer vorläufigen Analyse beschreibt der Hersteller der Falcon-Software, wie es zu den Bluescreens bei über 8 Millionen Windows-Rechnern kommen konnte. Bei genauem Hinsehen bleiben jedoch viele Fragen offen.
Die Suche nach dem Programmierfehler im "Falcon Sensor" geriet zur Wochenendbeschäftigung der Security-Szene. Kaum hatte ein Experte seine Einschätzung veröffentlicht, meldeten sich andere zu Wort – von der Sicherheits-Allzweckwaffe Tavis Ormandy bis zu Windows-Urgestein David Plummer. Ormandy hatte die Annahme, es handele sich um eine "Null-Pointer Exception", früh verworfen – und sollte Recht behalten: Gemäß CrowdStrikes Analyse wurden die massenhaften BSoDs (Bluescreen of Death) durch einen Speicherzugriffsfehler (out of bounds memory read) des Falcon Sensor ausgelöst. Bei diesem handelt es sich um einen mithilfe eines Windows-Treibers tief im Betriebssystem verankertes Überwachungsprogramms zum Schutz gegen Malware und Angriffe.
Doch wie kam es zu diesem fatalen Zugriffsfehler und warum fiel das Problem erst auf, als es Millionen PCs betraf? Diese Fragen beantwortet das Unternehmen nur mit viel Vorgeplänkel. Auf mehreren Bildschirmseiten lässt CrowdStrike den Leser wissen, dass es umfangreiche Test- und Qualitätssicherungsprozeduren für ihre Produkte gebe – verhängnisvoller Weise jedoch nicht für diejenigen Dateien, die schlussendlich zum Absturz führten.
Jene werden intern als "Rapid Response Content" bezeichnet und enthalten Schlüssel-Wert-Paare in einem Binärformat, etwa zur Erkennung verdächtiger Muster in Prozessen oder im Speicher. Analog zu Signatur-Aktualisierungen bei Virenscannern werden diese "Rapid Response"-Daten mehrmals täglich aktualisiert – anders als Aktualisierungen der Sensor-Software können Administrationen dieses Update derzeit auch nicht durch eine Konfigurationseinstellung verhindern.
Updates der Sensor-Software, also des Programm- und Treibercodes, testet CrowdStrike nach eigener Aussage ausgiebig und "dogfooded" sie – setzt sie also frei nach der Wendung "eat your own dog food", im eigenen Unternehmen ein. Zwischen Rapid-Response-Dateien und den Kundensystemen steht jedoch lediglich ein Parser, der "Content Validator". Diesen nutzen Entwickler, um die Mini-Updates vor dem Ausrollen auf korrekte Syntax zu prüfen – und aufgrund eines Programmierfehlers winkte der Validator die kaputte Datei durch.
Mangelhafte Syntaxprüfung für Update-Daten
Sind die Rapid-Response-Signaturen durch den Validator freigegeben, gibt es keine Prüfung der Updates auf Testsystemen, keine gezielte Aktualisierung einer geschlossenen "friendly user"-Benutzergruppe, kein "dogfooding", und auch keinen gestaffelten Updateprozess. Warum all diese Maßnahmen, die CrowdStrike für andere Teile ihres Produkts lang und breit erklärt, bei Inhalts-Updates nicht existieren, dazu schweigt das Unternehmen.
Zu allem Überfluss scheint der Falcon-Sensor die schludrig geprüften Dateien ohne eigene Fehler- oder Syntaxprüfung unbesehen einzulesen und aufgrund der fehlerhaften Daten auf ein falsches Speichersegment zuzugreifen. Da der Falcon Sensor als Windows-Systemtreiber implementiert ist, stürzt nicht nur das Sensor-Programm ab, sondern es zieht das gesamte System mit sich in den Abgrund. Da der Treiber zu einem Zeitpunkt während des Systemstarts geladen wird, zu dem der Computer womöglich noch keine Internetverbindung hat, verursachte er beim Neustart direkt den nächsten Bluescreen. In vielen Fällen halfen dann nur noch händische Rettungsmaßnahmen. Aber wieso eine kaputte Datei einen Speicherzugriffsfehler und eine Endlosschleife aus Systemabstürzen verursachen kann, das weiß CrowdStrike nicht zu beantworten.
So bleibt ein schaler Beigeschmack: Nur scheibchenweise gibt der Verursacher Informationen über den Grund des Ausfalls preis, eine Salamitaktik, die an Microsofts Kommunikationsstrategie beim Azure-GAU im vergangenen Jahr erinnert. Nach Abschluss der Nachforschungen wolle man eine weitere Analyse veröffentlichen, verspricht das Unternehmen immerhin.
Mehr Tests – warum erst jetzt?
Damit derlei Ungemach sich nicht wiederhole, verspricht CrowdStrike, die "Rapid Response"-Updates zukünftig zu testen. Im Maßnahmenkatalog finden sich Arbeitsschritte, die anderswo eine nicht erwähnenswerte Selbstverständlichkeit darstellen, etwa lokale Tests durch Entwickler, Fuzzing und Stabilitätstests. All diese Schritte wolle man neu einführen, schreibt CrowdStrike wohlgemerkt – das bedeutet, dass sie derzeit nicht existieren.
Beim Ausrollen von Updates wolle man künftig auch für die in kurzen Zeitabständen aktualisierten "Rapid Response"-Daten auf einen gestaffelten Updateprozess umsteigen, diesen überwachen und Kunden ermöglichen, die Updates zu steuern, nötigenfalls zu verhindern und zusätzliche Versionshinweise abzurufen.
Das BSI hatte sich jüngst mit eigenen Forderungen in die Debatte eingeschaltet, die sich zum Teil mit CrowdStrikes Maßnahmenkatalog decken. Admins, die womöglich selbst das Wochenende mit Computer-Wiederbelebungen verbracht haben, dürften jedoch weder die Versprechungen noch die halbherzige technische Analyse gnädig stimmen. Und Sicherheitsverantwortliche werden sich fragen, ob sie einem Unternehmen blind vertrauen sollten, das bei systemkritischen, zwangsweise ausgespielten Updates für Millionen von Windows-PCs nicht einmal grundlegende Maßnahmen zur Qualitätskontrolle ergreift.
(cku)
