DevOps-Teams verwenden seit Jahren Chaos-Engineering-Konzepte, um Softwarefehler zu finden. Jetzt gibt es auch Tools, die bei der Identifizierung von Sicherheitslücken helfen. [...]
Die Worte „Chaos“ und „Engineering“ werden normalerweise nicht zusammen verwendet. Schließlich halten gute Ingenieure das Chaos in Schach. Doch in letzter Zeit setzen Softwareentwickler das, was sie salopp als „Chaos“ bezeichnen, vorsichtig ein, um ihre Computersysteme zu stärken, indem sie versteckte Schwachstellen aufdecken. Die Ergebnisse sind nicht perfekt – alles, was chaotisch ist, kann keine Garantien bieten – aber die Techniken sind oft überraschend effektiv, zumindest manchmal, und das macht sie lohnenswert.
Das Verfahren kann besonders für Sicherheitsanalysten nützlich sein, da es ihre Aufgabe ist, die undokumentierten und unerwarteten Hintertüren zu finden. Das chaotische Testen kann nicht alle Sicherheitsmängel aufdecken, aber es kann gefährliche, ungepatchte Schwachstellen aufdecken, an die die Entwickler nicht gedacht haben. Ein gutes Chaos-Engineering kann sowohl den DevSecOps– als auch den DevOps-Teams helfen, denn manchmal können Probleme mit der Zuverlässigkeit oder Belastbarkeit auch Sicherheitsschwächen sein. Dieselben Kodierungsfehler können oft entweder das System zum Absturz bringen oder zu Einbrüchen führen.
Was ist Chaos Engineering?
Der Begriff ist eine Neuschöpfung, die verschiedene Techniken, die sich bewährt haben, zusammenfassen soll. Manche verwenden Begriffe wie „Fuzzing“ oder „Glitching“, um zu beschreiben, wie sie ein Computersystem manipulieren und es vielleicht aus dem Gleichgewicht bringen und zum Absturz bringen. Sie fügen zufälliges Verhalten ein, das die Software unter Stress setzen kann, während sie sorgfältig darauf achten, dass Fehlfunktionen oder Bugs auftreten. Dabei handelt es sich oft um Fehler, die sich erst nach Jahren im regulären Betrieb zeigen können.
John Gilmore, einer der Gründer der Electronic Freedom Foundation (EFF) und Mitglied des Entwicklungsteams hinter mehreren wichtigen Open-Source-Projekten, erklärt, dass die Programmierung ein Prozess ständiger Verfeinerung ist und dass Chaos-Engineering eine Möglichkeit ist, die Suche nach allen möglichen Ausführungswegen zu beschleunigen. „Der wirkliche Wert von langlaufendem Code besteht darin, dass die meisten Fehler von den ersten 10 Millionen Menschen, die ihn ausführen, den ersten 20 Compilern, die ihn kompiliert haben, den ersten fünf Betriebssystemen, auf denen er läuft, aus ihm herausgeschüttelt worden sind. Diejenigen, die dann durch Fuzzing und Penetrationstests getestet wurden (z. B. Google Project Zero), haben viel weniger unerforschte Codepfade als jedes neue Stück Code“, erklärt er.
Gilmore erzählt gerne eine Geschichte aus den 1970er Jahren, als er für Data General, einen frühen Minicomputerhersteller, arbeitete. Er stellte fest, dass das Umlegen eines Netzschalters zu zufälligen Zeiten den Zustand des Betriebssystems durcheinander brachte. „Anstatt das Problem zu beheben, behaupteten die Betriebssystem-Ingenieure, dass das Umlegen des Schalters kein gültiger Test sei“. sagt Gilmore, bevor er hinzufügt: „Das Ergebnis ist, dass Data General jetzt nicht mehr existiert.“
Die Idee ist weder in der Computerherstellung noch in anderen Bereichen der Technik neu. Autohersteller zum Beispiel testen neue Modelle im Sommer in der Wüste und im Winter in nördlichen Regionen. Architekten bauen Testkonstruktionen und überlasten sie, um zu sehen, ob sie versagen.
Die Informatik hingegen ist ein relativ mathematisches Gebiet. Viele Sicherheitsforscher erstellen ausgefeilte logische Beweise, die alle Gewissheiten der guten Mathematik bieten. Die Komplexität moderner Software ist jedoch viel größer, als unsere logischen Werkzeuge es abbilden können. Die meisten Bereiche der Computersicherheit sind weit davon entfernt, mit der Präzision verstanden zu werden, die wir uns wünschen, und das öffnet dem Zufall Tür und Tor.
Der Name vermeidet absichtlich das Wort „Wissenschaft“ und alle Traditionen des Aufbaus, des Testens und schließlich des Verstehens der Welt durch sorgfältig erstellte und kuratierte Modelle. Selbst die Verwendung des Wortes „Ingenieurwesen“ ist nicht ganz fair, denn Ingenieurwesen ist 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 freilassen oder ein gefettetes Schwein in der Schulkantine laufen lassen.
Chaos-Engineering-Techniken
Die von Chaos-Ingenieuren angewandten Techniken sind oft verblüffend einfach, aber überraschend raffiniert. Sie bestehen darin, das normalerweise schützende Haus der Software zu verbiegen und zu verzerren, indem sie viele der Dienste untergraben, die die Programmierer für selbstverständlich hielten. Ein einfacher Test löscht beispielsweise einfach die Hälfte der Datenpakete, die über die Internetverbindung laufen. Ein anderer Test kann fast den gesamten freien Speicherplatz belegen, so dass die Software nach Speicherplatz für Daten 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 sich schneeballartig ausbreiten und schließlich das System in die Knie zwingen.
Nahezu jede Ressource wie Arbeitsspeicher, Festplattenspeicher oder Datenbankverbindungen ist für Experimente geeignet. Bei einigen Tests wird die Ressource ganz abgeschnitten, bei anderen wird die Ressource 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. Puffer-Overflow-Probleme beispielsweise lassen sich von Chaos-Tools relativ leicht aufdecken, indem sie zu viele Bytes in einen Kanal einspeisen. Die Tools können zwar nicht in die Software eindringen, aber sie zeigen auf, wo jemand anderes diesen Puffer-Overflow ausnutzen könnte, um bösartigen Code einzuschleusen.
Fuzzing ist auch geeignet, Fehler in der Parsing-Logik aufzudecken. Manchmal vernachlässigen Programmierer die verschiedenen Möglichkeiten, wie die Parameter konfiguriert werden können, und lassen so eine potenzielle Hintertür offen. Wenn die Software mit zufälligen und halbstrukturierten Eingaben bombardiert wird, können diese Fehler ausgelöst werden, bevor Angreifer sie finden.
Das Gebiet hat sich auch weiterentwickelt. Einige Forscher sind über die rein zufällige Injektion hinausgegangen und haben 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. Eine Technik, die als grammatikalisches Fuzzing bezeichnet wird, beginnt mit einer Definition der erwarteten Datenstruktur und verwendet dann diese Grammatik, um Testdaten zu generieren, 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 alle getestet werden können.
Eine Herausforderung für jeden Chaos-Ingenieur ist die Erkennung von Fehlern, die bei extremen Belastungen auftreten können. Während Totalausfälle in der Regel leicht zu erkennen sind, kann es schwieriger sein zu sehen, wenn weniger krasse Ausfälle zu subtilen Sicherheitslücken führen. Viele der Probleme, die aufgedeckt werden, gefährden zwar keine Daten oder den Zugang, können aber dennoch Probleme aufzeigen, die angegangen und behoben werden sollten.
Chaos-Engineering-Tools
Dieser Bereich entwickelt sich schnell von einer geheimen Soße, die von cleveren DevSecOps-Teams eingesetzt wird, zu einem regulären Bestandteil des Entwicklungszyklus. Die Tools, die als Nebenprojekte und Skunkworks-Experimente für Ingenieure begannen, entwickeln sich nun zu vertrauten Bestandteilen vieler CI/CD-Pipelines. Viele dieser Tools bleiben Open-Source-Projekte, die von anderen DevSecOps-Spezialisten entwickelt und offen geteilt werden. Andere erregen kommerzielle Aufmerksamkeit. Einige wenige spezialisierte Unternehmen bieten proprietäre Tools für einen Markt an, der schnell wächst.
Einige Tools sind auch so konzipiert, dass sie tiefer in Software-Stacks integriert werden können. 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.
Dutzende von guten Chaos-Engineering-Tools sind in der Regel 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 Reihe 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 Gruppen von Rechnern abschalten können.
Die meisten anderen Plattformen verfügen über Tools, die darauf ausgerichtet sind, Störungen zu verursachen. Die Chaos-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 sind darauf ausgelegt, Ideen und Code über viele Plattformen hinweg zu teilen. 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 und chaotischen Herausforderungen zu versehen. Es stützt sich auch auf eine große Sammlung von Treibern und Plugins, um in vielen verschiedenen Clouds und lokalen Installationen zu funktionieren.
Der Hersteller von Software-Entwicklungswerkzeugen Cavisson bietet ein Produkt namens „NetHavoc“ an, das Fehler, so genannte „Havocs“, einschleust, die Softwarefehler einschließlich Sicherheitslücken aufdecken können. Ein Havoc beschädigt Pakete und verfälscht die DNS-Ergebnisse. Andere bringen die Anwendung um Speicher oder Festplattenplatz.
„Man kann einen Server killen, eine Instanz terminieren, sich teleportieren und Nachrichten in den Warteschlangen verfälschen“, erklärt Mrigank Mishra, ein Produktmanager bei Cavisson. „Letztendlich kommt es auf den Anwendungsfall an, den das Unternehmen untersucht.“
Einige Tools gehen tiefer, weil die Probleme innerhalb des Codes auftreten, wenn die Eingabe von den Erwartungen abweicht. Cryptofuzz beispielsweise arbeitet direkt mit einigen Kryptographie-Bibliotheken zusammen, die für die Verschlüsselung von SSL-Verbindungen zuständig sind. Es sucht nach Sicherheitsproblemen wie Abstürzen, Speicherlecks, Puffer-Overflows und nicht initialisierten Variablen.
Chaos Engineering expandiert
Dieser Bereich wächst weiter. Viele der Open-Source-Optionen werden erweitert und bringen neue Versionen mit vielen Verbesserungen hervor. Einige Unternehmen fangen an, Optionen zur Chaostheorie in ihre Entwicklungswerkzeuge, Testsuiten und Sicherheitsaudits einzubauen. Das Gebiet expandiert, weil es nicht konkret definiert ist – es ist vielmehr eine Sammlung von Techniken, um das Falsche zur falschen Zeit zu tun.
Oberflächlich betrachtet ist Chaos-Engineering ganz einfach. Man legt einfach Schalter um und verändert Daten, bis etwas kaputt geht. Aber die wahre Kunst besteht darin, die richtigen Stellen zu finden, an denen man herumfummeln und Rauschen hinzufügen kann. Chaos-Ingenieure sind weniger Ingenieure als vielmehr hinterhältige Idioten und bösartige Scherzkekse mit einer fiesen Ader. Normalerweise würden sie in höflichen Büros entweder ignoriert oder vor die Tür gesetzt werden, aber ihre Fähigkeit, die Schwachstellen, die Achillesfersen zu finden, erfordert ein antisoziales Verhalten, das die Annahmen, die die Entwickler beim Schreiben der ersten Entwürfe gemacht haben, absichtlich untergräbt und unterläuft. Wenn ein bisschen schlechtes Benehmen die Schwachstellen früh im Prozess aufdecken kann, bevor der Code in Produktion geht, gewinnen alle.
Be the first to comment