Fuzzing – Angriff ist die beste Verteidigung

Inhaltsverzeichnis

Eine der oft empfohlenen Best Practices in der Softwareentwicklung ist es, Bugs möglichst früh im Entwicklungsprozess zu beheben. Denn zahlreiche Studien zeigen, dass die Kosten, um einen Bug zu beheben exponentiell wachsen, je später Entwickler ihn finden (Rule of Ten).

Heutige Software zeichnet sich durch eine stark gestiegene Komplexität aus. Außerdem läuft die Entwicklung zunehmend schneller ab. Trotzdem darf die Qualität der ausgelieferten Software nicht leiden. Gleichzeitig wachsen die Gefahren durch Hackerangriffe. Vor allem im Bereich des Internet of Things (IoT) öffnen sich durch die Vielzahl der Angriffsvektoren in allen Ecken potenzielle Angriffspunkte für Cyberkriminelle. Das kann für Unternehmen im schlimmsten Fall existenzbedrohende Konsequenzen nach sich ziehen.

Diese enormen Herausforderungen lassen sich nur durch aktives Qualitätsmanagement bewältigen. Dafür sollten Unternehmen smartes und automatisiertes Software-Security-Testing bereits von Anfang an in den Entwicklungsprozess integrieren. Modernes Fuzzing ist ein Ansatz, den Testprozess durch Effektivitäts- und Effizienzsteigerung zu optimieren.

Der Weg zu zeitgemäßem Fuzzing

Um das Potenzial von Fuzzing einschätzen zu können, muss man den automatisierten Testing-Ansatz in Relation zu seinen Vorgängern und "Konkurrenten" betrachten. Fuzzing beruht auf Methoden, die seit geraumer Zeit in der Softwareentwicklung im Einsatz sind. Die ältesten Testverfahren sind Modultests und manuelle Code-Reviews. Da sie mit großem manuellen Aufwand verbunden sind, sind sie besonders zeitaufwendig und bei Zeitdruck oft vernachlässigt. Nichtsdestoweniger führte lange kein Weg daran vorbei – bis die ersten statischen Codeanalyse-Tools ernstzunehmende Resultate lieferten.

Sie untersuchen den Quellcode mit Heuristiken, ohne ihn auszuführen. Da oft der Ausführungskontext fehlt (mit welchen Eingaben Nutzer bestimmte Codestellen tatsächlich von außen erreichen können), entstehen jedoch riesige Mengen an False-Positive-Warnungen. Diese müssen Entwickler einer aufwendigen manuellen Nachkontrolle unterziehen. Parallel dazu haben sich dynamische Analyseverfahren entwickelt, die eine deutlich niedrigere False-Positive-Rate aufweisen, indem sie die zu testende Applikation tatsächlich ausführen und nur wirklich auftretende Fehler melden. Dazu erfolgt ein Angriff auf die Applikation mit zufälligen Eingaben oder potenziellen Angriffsmustern und eine Beobachtung des resultierenden Programmverhaltens. Nur mit Angriffsmustern und Zufallseingaben dringt man in diesem Verfahren aber systembedingt nicht bis in die Tiefe des Quellcodes vor. Mit zunehmender Komplexität der Eingabestrukturen nimmt die Qualität der Ergebnisse ab.