Schwachstellen effektiver finden

"Chaos" und "Engineering" passen eigentlich nicht besonders gut zusammen. Schließlich sind es gute Engineers, die das Chaos in Schach halten. Inzwischen setzen Softwareentwickler allerdings immer öfter auf Chaos Engineering, um versteckte Schwachstellen aufzudecken und ihre Systeme zu härten. Die Ergebnisse sind nicht perfekt, die Techniken aber in vielen Fällen überraschend effektiv.

Besonders für Security-Analysten kann sich dieses Vorgehen lohnen. Mit Hilfe von Chaos Engineering lassen sich zwar nicht sämtliche Security-Löcher aufdecken, wohl aber gefährliche, weil ungepatchte Schwachstellen, die die Entwickler übersehen haben. So unterstützt diese Vorgehensweise sowohl DevOps- als auch DevSecOps-Teams. Ein und derselbe Programmierfehler kann entweder das System zum Absturz bringen oder Einfallstore für Eindringlinge schaffen.

Was ist Chaos Engineering?

Der Begriff Chaos Engineering ist eine Neuschöpfung, die verschiedene Techniken zusammenfasst. Manche Experten verwenden Begriffe wie "Fuzzing" oder "Glitching", um zu beschreiben, wie sie ein Computersystem manipulieren und zum Absturz bringen: Sie setzen eine Software mit zufälligen Verhaltensmustern unter Stress und achten dabei auf Fehlfunktionen. Die Bugs, die hierbei identifiziert werden, zeigen sich im regulären Betrieb oft erst nach Jahren.

Laut John Gilmore, Mitbegründer der Electronic Freedom Foundation (EFF) und Mitglied der Entwicklungsteams hinter mehreren wichtigen Open-Source-Projekten, ist Softwareentwicklung ein Prozess der ständigen Verfeinerung - und Chaos Engineering eine Möglichkeit, die Suche nach allen möglichen Ausführungspfaden zu beschleunigen: "Der wahre Wert von langfristig laufendem Code besteht darin, dass die meisten Kinderkrankheiten in der Anfangsphase verschwinden. Was übrig bleibt und durch Fuzzing oder Penetrationstests identifiziert wird, weist im Regelfall deutlich weniger unerforschte Codepfade auf als jedes neue Stück Code."

Die Idee hinter diesem Vorgehen ist alles andere als neu: Autohersteller testen neue Modelle im Sommer in der Wüste und im Winter am Polarkreis, Architekten bauen Testkonstruktionen und überlasten sie, um zu sehen, ob beziehungsweise wie sie versagen. Die Informatik hingegen ist ein sehr mathematisch ausgerichtetes Gebiet. Viele Sicherheitsforscher erstellen ausgefeilte logische Beweise. Die Komplexität moderner Software ist jedoch viel größer, um sie mit diesen logischen Werkzeugen abbilden zu können. Und speziell im Bereich der Cybersicherheit sind wir weit davon entfernt, alles mit der Präzision zu verstehen, die nötig wäre. An dieser Stelle kommt das Chaos ins Spiel.

Chaos Engineering vermeidet absichtlich das Wort "Wissenschaft" und bricht mit der Tradition von Building, Testing und Verstehen anhand sorgfältig erstellter und kuratierter Modelle. Eigentlich führt auch der Begriff "Engineering" in die Irre - ist es doch oft genauso rigoros, geplant und methodisch wie das, was in wissenschaftlichen Labors passiert. Chaos Engineering ist eher so, als würde man einen Elefanten im Porzellanladen loslassen oder ein Wildschwein in der vollbesetzten Firmenkantine.

Chaos Engineering - Techniken

Die Techniken, die im Rahmen von Chaos Engineering angewandt werden, sind oft verblüffend einfach und überraschend hinterhältig. Sie sollen die Software an ihre Grenzen bringen, indem sie viele der Services unterwandern, die für Softwareentwickler selbstverständlich sind. Ein einfacher Test beinhaltet beispielsweise, einfach die Hälfte aller Datenpakete, die über die Internetverbindung laufen, zu löschen. Ein anderer Test belegt nahezu den gesamten freien Speicherplatz, so dass die Software nach Speicherplatz suchen muss.

Die Tests werden oft auf einer höheren Ebene durchgeführt. DevSecOps-Teams können einfach eine Teilmenge der Server abschalten, um zu sehen, ob die verschiedenen Softwarepakete, die in der Konstellation laufen, belastbar genug sind, um den Ausfall zu überstehen. Andere fügen einfach eine gewisse Latenz hinzu, um zu sehen, ob die Verzögerungen weitere Verzögerungen auslösen, die zu einem Schneeball-Effekt führen und schließlich das System in die Knie zwingen. Allgemein gilt:

• Nahezu alle Ressourcen (Arbeitsspeicher, Festplattenspeicher oder Datenbankverbindungen) sind diesbezüglich für Experimente geeignet. Bei einigen Tests wird die Ressource ganz abgeschaltet, bei anderen nur stark eingeschränkt, um zu sehen, wie sich die Software verhält, wenn sie unter Druck gerät.

• Sicherheitslücken werden oft indirekt aufgedeckt. Buffer-Overflow-Probleme lassen sich mit Hilfe von Chaos-Engineering-Tools relativ leicht aufdecken, indem zu viele Bytes eingespeist werden. Die Tools können zwar nicht in die Software eindringen, aber sie zeigen auf, wo Angreifer ansetzen könnten, um bösartigen Code einzuschleusen.

• Fuzzing ist dazu geeignet, Fehler in der Parsing-Logik aufzudecken. Manchmal vernachlässigen Programmierer die verschiedenen Möglichkeiten, die Parameter zu konfigurieren und schaffen so eine potenzielle Hintertür. Wird die Software mit zufälligen und halbstrukturierten Eingaben bombardiert, können diese Fehler aufgedeckt werden, bevor Angreifer auf sie stoßen. Einige Forscher haben inzwischen ausgeklügelte Fuzzing-Tools entwickelt, die das Wissen über die Software nutzen, um den Prozess mit Hilfe einer so genannten White-Box-Analyse zu steuern. Grammatical Fuzzing beginnt mit einer Definition der erwarteten Datenstruktur und generiert Testdaten, bevor die Definition in der Hoffnung unterlaufen wird, einen Parsing-Fehler zu finden.

• Tiefergehende Strategien können systematisch versuchen, alle möglichen Ausführungspfade im Code zu identifizieren. Microsoft hat beispielsweise ein Tool namens SAGE entwickelt, das potenzielle Fehler aufzeigt, indem es die möglichen Verzweigungen untersucht und Eingaben erstellt, mit denen diese getestet werden können.

Eine Herausforderung für jeden Chaos Engineer ist es, Fehler zu erkennen, die bei extremen Belastungen auftreten. Während Totalausfälle in der Regel leicht zu erkennen sind, kann das bei weniger krassen Ausfällen, die zu subtilen Sicherheitslücken führen, ganz anders aussehen.

Chaos Engineering - Tools

Chaos Engineering Tools entwickeln sich vom Geheimtipp cleverer DevSecOps-Teams zu einem regulären Part des Entwicklungszyklus und einem zuverlässigen Bestandteil vieler CI/CD-Pipelines. Dabei ist ein Gros der Tools als Open-Source-Projekt angelegt - in der Regel von anderen DevSecOps-Profis entwickelt. Allerdings bieten auch einige spezialisierte Unternehmen proprietäre Tools an.

• Einige Tools sind darauf konzipiert, tiefer in Software-Stacks integriert zu werden. ChaosMachine, ein an der Königlichen Technischen Hochschule (KTH) in Schweden entwickeltes Forschungstool, fügt beispielsweise falsche Ausnahmen in Bytecode ein, der auf virtuellen Java-Maschinen läuft. Diese belasten die Mechanismen zur Fehlerbehandlung, die bereits in den Code geschrieben sein sollten.

• Viele Chaos-Engineering-Tools sind auf eine bestimmte Sprache oder Plattform ausgerichtet. Pythonfuzz zum Beispiel ruft wiederholt Funktionen mit zufälligen Daten auf und achtet dabei auf Speicherlecks, Deadlocks oder andere Fehler. OSS-Fuzz von Google arbeitet mit mehreren Sprachen und Projekten, und das Unternehmen nutzt sie, um Open-Source-Beiträge zu seinem Ökosystem wie Chrome-Erweiterungen zu testen.

• Andere Tools sind auf bestimmte Plattformen ausgerichtet. Netflix war einer der Pioniere auf diesem Gebiet und hat eine Sammlung von Tools zum Testen seiner Infrastruktur entwickelt, die sich stark auf Amazon Web Services stützt. Eines der ersten Tools, Chaos Monkey, greift nach dem Zufallsprinzip in Maschinencluster ein und beendet einige, um zu sehen, ob der Totalausfall einer Instanz zu Problemen führt. Netflix hat ähnliche Tools entwickelt, die es die Simian Army nennt. Dazu gehören Latency Monkey, Chaos Gorilla und Chaos Kong, die Netzwerke verlangsamen oder sogar ganze Rechnernetzwerke abschalten können.

• Die meisten anderen Plattformen verfügen über Tools, die darauf ausgerichtet sind, Chaos zu stiften. Die Plattform von Proofdock zielt zum Beispiel auf Azure ab. Google Cloud Chaos Monkey ist eine für die GCP-API umgeschriebene Version des Originals.

• Einige Projekte dienen dem Austausch von Ideen und Code über mehrere Plattformen hinweg. Ein Open-Source-Projekt namens Litmus zielt auf alle wichtigen Clouds und Maschinen, die vor Ort laufen. Die Litmus-Plattform unterstützt "ChaosExperimente", die auf Software abzielen können, die in verschiedenen Clouds läuft. Die ChaosEngine stellt die Experimente bereit und verfolgt die Ergebnisse.

• Viele Tools sind dafür gedacht, Teamgrenzen zu überwinden und sowohl Entwickler, die Code in frühen Phasen testen, als auch DevOps-Teams, die CI/CD-Pipelines verwalten und die in Produktion befindliche Software überwachen, zusammenzubringen. Das ChaosToolkit beispielsweise ist ein Open-Source-Projekt, das sich in jede Build-Pipeline integrieren lässt, um den neuen Code mit komplexeren Herausforderungen zu konfrontieren. Dabei stützt sich das Tool auch auf eine große Sammlung von Treibern und Plugins, die in vielen verschiedenen Clouds und lokalen Installationen funktionieren.

• Der Anbieter Cavisson bietet ein Produkt namens "NetHavoc" an, das Softwarefehler einschließlich Sicherheitslücken aufdecken soll. Dabei werden Datenpakete beschädigt und DNS-Ergebnisse verfälscht. Bei anderen wird der Anwendung Speicher- oder Festplattenplatz entzogen.

• Einige Tools gehen tiefer, weil die Probleme innerhalb des Codes auftreten, wenn die Eingabe von den Erwartungen abweicht. Cryptofuzz beispielsweise arbeitet direkt mit einigen Kryptografie-Bibliotheken zusammen, die für die Verschlüsselung von SSL-Verbindungen zuständig sind. Es sucht nach Sicherheitsproblemen wie Abstürzen, Speicherlecks, Buffer Overflows und nicht initialisierten Variablen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.