Viel ist nicht über den Sicherheitsforscher bekannt, der unter dem Namen „Chaotic Eclipse“ einen funktionierenden Exploit namens "Bluehammer" veröffentlicht hat. Erklärungen dazu hat er nicht mitgeliefert – „Ihr Genies könnt das selber herausfinden“. Im einzigen Post zum Thema dankt er auch mit einer gehörigen Portion Sarkasmus der Leitung des MSRC (Microsoft Security Response Center) und namentlich Tom Gallagher für die Veröffentlichung. Der Exploit mit dem Namen „Bluehammer“– vermutlich in Anlehnung an den berühmt-berüchtigten „Eternal Blue“-Exploit – scheint allerdings „zwar nicht hundertprozentig, aber gut genug“ zu funktionieren, wie Will Dormann, selbst ein bekannter und gefragter Sicherheitsforscher, herausgefunden und auf Mastodon gepostet hat.
Aber warum wurde die Sicherheitslücke und der passende Exploit überhaupt öffentlich gemacht? Ich habe dazu ein paar Vermutungen und „educated guesses“.
Dazu müssen wir zunächst einen Blick darauf werfen, wie solche so genannten Vulnerability Reports verarbeitet werden.
Langsam mahlende Mühlen
Wer zum Beispiel eine Sicherheitslücke an Microsoft meldet, kann nicht automatisch damit rechnen, dass sofort ein Patch erfolgt, oder dass binnen weniger Tage eine Veröffentlichung erfolgt. Nach der Einsendung und einem Review kann es zwischen 40 und 200 Tagen dauern, bis ein Patch veröffentlicht wird. Sprich: Es kann nach der initialen Meldung bis zu knapp sieben Monate dauern, bis eine Sicherheitslücke tatsächlich behoben ist.
Es ergeben sich zahlreiche Reibungspunkte entlang des Weges zum Patch – angefangen von der Annahme des Reports (oder deren Ausbleiben) über die Kritikalität bis hin zur Dauer, bis ein Fix bereitsteht. Hier kommt es auf das nötige Feingefühl an. Auch in Detailfragen gehen die Meinungen bisweilen weit auseinander. So mag es im Einzelfall sein, dass eine bestimmte Funktion innerhalb eines Programms zwar theoretisch angreifbar ist, der Entwickler dies jedoch bereits eingeplant und den Angriff an einer anderen Stelle (zum Beispiel durch eine separate Prüfung oder Validierung von Eingaben) blockiert. Somit wäre keine ausnutzbare Sicherheitslücke vorhanden. Finales Urteil in einem solchen Fall: „Working as intended, won’t fix“ (Funktioniert wie beabsichtigt; kein Fix erforderlich).
Die Kritikalität ist ein häufiger Streitpunkt – während der oder die Meldende eine Sicherheitslücke für hochkritisch hält, folgt der Hersteller dieser Einschätzung nicht zwingend, da bestimmte Voraussetzungen für ein Gelingen des Angriffs vorliegen müssen, die nicht automatisch erfüllt sind, und gegebenenfalls weitere Exploits oder Nutzerrechte erfordern.
Filtern und Aussortieren
Gerade mit dem Aufkommen von KI-Technologien und durch deren Eignung als Werkzeug zur Analyse von Programmcode ist das Aufkommen an Meldungen über Schwachstellen bei vielen Herstellern drastisch angestiegen. Während tatsächlich brauchbare und legitime Schwachstellen unter den Meldungen sein können, ist das Hauptproblem tatsächlich die schiere Masse an Meldungen.
Denn: Die eingehenden Meldungen sind zwar oftmals sauber formatiert und klingen beim ersten Lesen überzeugend – doch bei näherem Hinsehen stellt sich dann heraus, dass hier keine ausnutzbare Sicherheitslücke vorliegt. Dazu muss jedoch entweder ein Mensch diese Kontrolle übernehmen oder ein Mensch muss eine entsprechend konfigurierte KI-gestützte Analyseumgebung nutzen, und die Ergebnisse korrekt interpretieren. Das braucht Zeit und Ressourcen – selbst, wenn eine KI hilft. Ohne Weiteres kann diese allerdings keine verlässlichen Einschätzungen abgeben, wie mein Kollege Karsten Hahn in seinem Blogartikel schrieb.
So haben wir es also mit einer Flut an Berichten zu tun, die mit wenig Aufwand erstellt sind, aber mit viel Aufwand gesichtet und kategorisiert werden müssen.
Opfer von Umstrukturierungen
Meldungen über Schwachstellen zunächst einen Screening-Prozess durchlaufen zu lassen, ergibt absolut Sinn. Aus dem oben genannten Mastodon-Post lässt sich ableiten, dass speziell Microsoft hier in letzter Zeit eine zusätzliche „Filter-Ebene“ eingezogen hat, die die Aufgaben übernehmen soll, eingehende Berichte vorzu sortieren und substanzlose Meldungen auszusieben. Dazu kann Microsoft allerdings keine hochspezialisierten Entwicklerinnen und Entwickler abstellen. Es seien sogar Stellen abgebaut worden, sodass sich laut Dormann die Zusammenarbeit mit dem MSRC wesentlich schwieriger gestalte als in der Vergangenheit.
Somit ist davon auszugehen, dass die erste Person, die eine Schwachstellen-Meldung zu Gesicht bekommt, kein Experte in Sachen Malware ist.
An dieser Stelle könnte der zitierte „Video-Beweis“ ins Spiel kommen. Dieser wird nämlich anscheinend erst seit Kurzem beim Einreichen einer Meldung verlangt.
Ein Video ist technisch gesehen nicht unbedingt nötig, um die Wirksamkeit eines Exploits zu demonstrieren, macht es aber anschaulicher – auch für relative Laien.
„Pics or it didn’t happen“
Hierin könnte der erste Grund für das Verlangen eines Videobeweises liegen: Unkundige können so sehen, ob ein Bericht tatsächlich potenziell wertvolle Informationen enthält. Liegt ein Videobeweis vor, gewinnt ein eingesendeter Bericht aus Sicht von Microsoft (und anderer Hersteller, die ähnlich agieren), an Qualität – trotz der Tatsache, dass er rein technisch keinen wirklichen Mehrwert bringt.
Natürlich lässt sich ein Video auch fälschen oder manipulieren. Das läge jedoch nicht im Interesse eines Sicherheitsforschers, der eine legitime, echte Sicherheitslücke melden will. Für diesen ist das Erstellen eines Videos ein eigentlich unnötiger, mit Mehrarbeit (und potenziellem Frust ob des zusätzlichen Zeitaufwandes) verbundener Schritt; Dass jemand frustriert ist, wenn ausschließlich aufgrund des fehlenden Videos ein legitimer Bericht abgewiesen wird, ist nachvollziehbar - vor allem dann, wenn jemand seine Erkenntnisse pro bono zur Verfügung stellt und nicht auf eine Bug Bounty aus ist.
Auf der anderen Seite wäre ein KI-Agent, der den Auftrag hat, so viele Sicherheitslücken wie möglich zu finden und automatisch zu melden, mit dieser Aufgabe überfordert. Und selbst, wenn die Generierung einer (gefälschten) Bildschirmaufnahme gelänge, wären die Kosten dafür unverhältnismäßig hoch – vor allem wenn die Gefahr besteht, dass der Bericht in zweiter Instanz dann doch abgelehnt wird.
Frust und Vorurteil
Aus Sicht einer Person, die Schaden abwenden und daher eine Sicherheitslücke melden will, und der es dabei vielleicht noch nicht einmal um eine Bug Bounty (also eine Art „Kopfgeld“, für Sicherheitslücken) geht, lässt der Hersteller sie mit dem Verlangen eines Video-Nachweises ohne Not durch einen weiteren brennenden Reifen springen. Das erzeugt maximalen Frust bei Menschen wie dem Entdecker von BlueHammer, bis zu dem Punkt, an dem sie aufgeben und ihre Erkenntnisse kurzerhand sofort und selbst veröffentlichen.
War das eine Impulshandlung aus der Frustration heraus, um eine Reaktion von Microsoft zu erzwingen? Vielleicht.
Aber auf jeden Fall ist der Fall „Bluehammer“ ein Signal an Hersteller, ihre Melde- und Prüfprozesse genau unter die Lupe zu nehmen, um nicht am Ende das Kind mit dem Bade auszuschütten.
