zurück zur Übersicht

Chaff Bugs in der IT-Sicherheit: Viel hilft viel?

Chaff Bugs: Die Zukunft der IT-Sicherheit?

Die heutige Welt der IT Security besteht aus einem ewigen Kampf zwischen dem Guten und dem Bösen, ständig werden neue Technologien entwickelt, um die Sicherheit zu erhöhen. Ständig werden böse Werkzeuge erschaffen, um Schwachstellen zu finden und auszunutzen: Das Problem, dass jedes Schloss geknackt werden kann, bleibt erhalten.

Man versucht dieses Problem von verschiedenen Perspektiven aus zu lösen: Einige versuchen das Schloss feiner und komplizierter zu machen, einige bauen Alarmsysteme ein usw.

Die Mannschaft von Professor Brendan Dolan-Gavitt ist einen anderen Weg gegangen. Sie fragten sich, was würde mit „der Tür“ passieren wenn sie eine riesige Anzahl von Schlössern hätte, aber nur aber nur mit einem davon die Tür geöffnet werden kann? So kam es zu der Idee, den Code einer Software so fehlerhaft wie möglich zu machen. Aber hat diese Idee auch einen Sinn?

Ursprünglich  arbeitete Professor Dolan-Gavitt an LAVA, ein System um automatisch potenzielle memory safety Fehler in C/C++ Programme hinzuzufügen, damit man verschiedene bugsuchende Werkzeuge testen kann. Während der Entwicklung ist der Mannschaft folgendes aufgefallen:

Der klassische Weg eines IT-Angreifers sieht wie folgt aus:

 

Die heutigen Sicherheitsmechanismen beschäftigen sich primär mit der Phase 1 und Phase 4 indem man versucht die Anzahl der möglichen exploitable Bugs zu minimieren und das Ausführen von Exploits zu verhindern.

All you need is bug!

Das Angriffsziel der Methode von Professor Dolan-Gavitt ist die Entdeckung des Bugs und bezieht sich auf die Phase 2 und 4. Er ist der Meinung, dass die wichtigste und die teuerste Ressource des Angreifers die Zeit ist. Je mehr Zeit der Angreifer dafür verschwendet überhaupt die Exploitable Bugs zu identifizieren und dafür die Exploits zu bauen, desto größer ist die Wahrscheinlichkeit, dass der Angriff abgebrochen wird.

Der Professor nannte diesen Ansatz „Chaff Bugs“

Die meisten Programme aus C/C++ leiden unter zwei Hauptarten von Memory Bugs:

  • stack buffer overflows
  • heap buffer overflows

Beim Einfügen eines Overflows gibt es zwei Schlüsseleigenschaften die den Exploit definieren: das Ziel des Overflows (welche Data überschrieben ist) und der Wert, der geschrieben wird. Die Aufgabe von Professor Dolan-Gavitt bestand darin, sehr viele solche Bugs in den Sourcecode zu integrieren, die dabei zwei Anforderungen erfüllen sollten:

  • non-exploitable zu sein
  • schwer analysierbar für die Exploit Entwicklung sein

Die Schlacht bewusst verlieren um den Krieg zu gewinnen?

Um sicherzustellen, dass die integrierten Bugs non exploitable sind, verfolgt man zwei Strategien:

  • Das Ziel des Overflows ist eine Variable, die das Programm nicht nutzt
  • Das Sicherstellen dass der Wert eingeschränkt ist

Die zweite Anforderung war, diese Bugs kompliziert für die Analyse zu machen.

Das Problem bei den eingeschränkten Werten besteht darin, dass der Angreifer fähig ist, den Einschränkungsprüfungscode zu finden und damit umzugehen. Deswegen zerteilte man den Prüfungscode in einzelne Komponenten und versteckte sie in verschiedenen Bereichen des Programms.

Bei den ungenutzten Variablen konnte der Angreifer sehen, dass sie innerhalb einer Funktion bleiben und dadurch keine Auswirkung auf den Gesamtcode haben. Um das zu verstecken wurde das Faking Data Flow eingesetzt. Die ungenutzten Variablen werden nach dem Overflow auch in den anderen Teilen des Codes gebraucht (sind dabei aber nicht essentiell). Das führt dazu, dass ein einfaches Betrachten des Codes keine Aussage über den Wert der Variable liefert. Man muss vielmehr den gesamten Datapfad betrachten.

Welche Folgen haben diese Bugs für die Nutzer?

Professor Dolan-Gavitt ist in diesem Kontext völlig entspannt. Falls es tatsächlich zu einem Exploit kommen sollte, kann es im allerschlimmsten Fall nur zu einem Crash des Programms kommen. Derartige Crashs hält der Professor jedoch nicht für kritisch. Heutzutage beinhalten viele Programme Micro Services. Diese werdeb explizit dafür gebaut, um die Ausfälle zu behandeln und die Prozesse zu restarten. Z.B. können viele moderne Browser jeden Tab in einen einzelnen Prozess teilen. Zusätzlich beinhalten Web Server wie nginx einen Pool von Serverprozessen, die jederzeit neugestartet werden können. Außerdem meint der Professor, dass es die ehrlichen Nutzer mit legitimen Eingaben nicht betreffen wird.

Nichtsdestotrotz wird es noch eine lange Zeit bis zur Anerkennung und zum kommerziellen Einsatz dieser Methode dauern. Denn die Technologie hat auch Nachteile:

Die größte Schwachstelle der Methode ist die, dass der Unterschied zwischen den natürlichen und den künstlichen Bugs nicht versteckt ist. Wenn der Angreifer das Muster erkennt, hat er leichtet Spiel, die Chaff Bugs zu identifizieren.

Chaff Bugs – das Antibiotikum der IT-Sicherheit?

Zweitens ist es unmöglich diesen Ansatz bei einer Open Source Software einzusetzen, da sich der Code ständig optimiert.

Auch die Begrenzung auf den Source Code macht die Anwendung der Methode für einige Applikationen schwierig. In diesem Kontext wird aber momentan weiter geforscht. Die letzte Aussage des Professors Dolan-Gavitt lautet, dass es bald möglich sein sollte, auch mit Binaries zu arbeiten.

Und letztlich kostet es auch eine Überwindung damit klar zu kommen, dass der Code „verdorben “ ist und dass es absichtlich zu einem Crash kommen wird.

Deswegen bleibt uns nur übrig abzuwarten und zu schauen, wie und ob diese Methode sich durchsetzen kann oder ob sie nur ein Kandidat für den Ig- Nobelpreis ist.


Mehr Informationen zu diesem Thema

Bild: © GettyImages-507396240-altmodern

Schreibe einen Kommentar

Wir nehmen Datenschutz ernst! Deshalb informieren wir Sie, was mit Ihren Daten geschieht:

  • Daten aus Formularen und Webseiten-Tracking können von uns zur Analyse gespeichert werden
  • Die Daten können zur Optimierung der Webseite ausgewertet werden. Das ermöglicht es uns, besser zu verstehen, wo das Interesse unserer Besucher liegt. Wir benutzen primär Hubspot für dieses Tracking (mehr dazu finden Sie in der Erklärung auf unserer Datenschutzseite, siehe unten)
  • Wir geben Ihre Daten nicht an Dritte weiter. Im Rahmen von Veranstaltungen, an denen Sie teilnehmen möchten, kann es nötig sein, dass Ihre Daten an Vertragspartner übermittelt werden.
  • Sie haben jederzeit ein Recht auf die Herausgabe, Berichtigung oder Löschung persönlicher Daten.
  • Sie können Ihre Einwilligung, mit uns in Kontakt zu treten, jederzeit mit sofortiger Wirkung widerrufen.

Weitere Details dazu, was wir mit den Daten tun und nicht tun finden Sie auf unserer Datenschutzseite, oder schreiben Sie mich bei Fragen direkt an!

Felix Möckel
Data Protection Officer