Pre-Model Representation Failures in GNN-Based Smart Contract Vulnerability Detection

In der digitalen Welt der dezentralen Finanzen bewegt sich Geld durch selbstausführende Computerprogramme, die Smart Contracts genannt werden. Diese Programme leben auf einer Blockchain, einem öffentlichen Register, das jede Transaktion aufzeichnet, und sie sind darauf ausgelegt, reale Vermögenswerte ohne menschliche Vermittler zu verwalten. Da diese Verträge wertvolle Gelder verwalten, kann ein einziger verborgener Fehler zu sofortigem und irreversiblem Diebstahl führen. Um dies zu verhindern, haben Forscher automatisierte Systeme entwickelt, die den Code scannen, um Schwachstellen zu finden, bevor sie ausgenutzt werden. Ein populärer Ansatz verwendet eine Art künstliche Intelligenz, die als Graph Neural Network bekannt ist. Um zu verstehen, wie dies funktioniert, stellen Sie sich vor, man nehme ein komplexes Stück Code und verwandle es in eine Karte aus verbundenen Punkten und Linien, wobei die Punkte Teile des Programms repräsentieren und die Linien zeigen, wie diese interagieren. Der Computer studiert diese Karte dann, um zu entscheiden, ob das Programm sicher oder gefährlich ist. Die Hoffnung ist, dass diese Systeme durch das Betrachten der Struktur des Codes anstatt nur Zeile für Zeile zu lesen, subtile Fallen entdecken können, die Menschen entgehen könnten.

Ein Team von Forschern der Carnegie Mellon University Africa beschloss, das Fundament dieses Ansatzes zu testen. Sie konzentrierten sich auf ein spezifisches System namens GNNSCVulDetector, das weit verbreitet ist, um eine gefährliche Schwachstelle zu finden, die als Reentrancy bekannt ist. Dieser Fehler tritt auf, wenn ein Programm Geld versendet, bevor es seine eigenen Datensätze aktualisiert, was es einem Dieb ermöglicht, das System auszutricksen, damit es mehr auszahlt, als es sollte. Die Forscher testeten nicht, wie gut der Computer lernt oder wie schnell er denkt. Stattdessen untersuchten sie den Schritt, der geschieht, bevor der Computer die Daten überhaupt sieht: der Prozess, den Quellcode in die Karte zu verwandeln. Sie wollten wissen, ob die Karte das Code-Fragment, das sie darstellen sollte, tatsächlich korrekt widerspiegelte. Ihre Untersuchung enthüllte eine erschreckende Wahrheit: Der Prozess der Kartenerstellung selbst war auf eine Weise fehlerhaft, die durch keinerlei Training behoben werden konnte.

Das erste Problem, das sie fanden, war, dass das System durch einfache Änderungen am Code leicht getäuscht werden konnte. Die Forscher nahmen einen bekannten vulnerablen Vertrag und benannten dessen Teile einfach um, änderten den Namen des Vertrags selbst, die Namen der Funktionen und die Namen der Variablen, die das Geld hielten. Sie fügten auch Codezeilen hinzu, die nichts taten, nur um die Datei zu überladen. In einer normalen Welt würden diese Änderungen das Programm anders aussehen lassen, selbst wenn die gefährliche Logik dieselbe bliebe. Als die Forscher jedoch sowohl die ursprüngliche als auch die modifizierte Version in das System einspeisten, erzeugte der Computer Karten, die bis auf das letzte Byte identisch waren. Das System konnte den Unterschied zwischen den beiden nicht feststellen. Dies bedeutet, dass ein Angreifer die Sicherheitsprüfung umgehen könnte, indem er lediglich Variablen umbenennt, ohne wissen zu müssen, wie der Detektor funktioniert oder mit welchen Daten er trainiert wurde. Das System war blind für die tatsächliche Struktur des Codes und sah nur ein starres Muster von Namen.

Durch tieferes Graben entdeckten die Forscher, warum dies geschah. Das Werkzeug, das die Karte erstellt, liest und versteht den Code nicht wirklich wie ein menschlicher Programmierer. Stattdessen verlässt es sich auf eine fest codierte Liste von siebenundvierzig spezifischen Variablennamen, die es erkennen darf. Wenn der Code einen Namen aus dieser Liste verwendet, erstellt das Werkzeug einen Knoten auf der Karte. Wenn der Name nicht auf der Liste steht, ignoriert das Werkzeug ihn oder erstellt einen generischen Platzhalter. Die Forscher testeten dies, indem sie vier verschiedene Verträge erstellten, die alle exakt dieselbe gefährliche Schwachstelle aufwiesen, aber unterschiedliche Namen für die Geldvariablen verwendeten. Wenn der Variablenname perfekt mit der Liste übereinstimmte, sah die Karte normal aus. Wenn der Name leicht abwich, veränderte sich die Karte auf verwirrende Weise. Wenn der Name völlig neu und nicht auf der Liste war, wurde die Karte degradiert und verlor wichtige Details. Im schlimmsten Fall, wenn überhaupt keine Namen übereinstimmten, fabricierte das Werkzeug Teile der Karte, die im Originalcode gar nicht existierten, und schuf eine Struktur basierend auf nichts als seinen eigenen internen Regeln. Dies bedeutete, dass die Qualität der Karte vollständig davon abhing, ob der Programmierer zufällig einen der siebenundvierzig zugelassenen Namen verwendete.

Der zweite große Fehler betraf einen spezifischen Teil der Karte, der den Angreifer repräsentiert. Im Design des Systems gibt es einen Knoten, der dazu gedacht ist, den externen Aufrufer darzustellen – die externe Entität, die den Angriff auslöst. Damit eine Reentrancy-Schwachstelle existieren kann, muss dieser externe Aufrufer in der Karte vorhanden sein. Die Forscher fanden heraus, dass dieser Knoten für das berühmteste Beispiel eines vulnerablen Vertrags in der Fachliteratur komplett fehlte. Das Werkzeug versäumte es, die Verbindung zwischen dem Angreifer und der vulnerablen Funktion zu zeichnen, obwohl der Code dies eindeutig zeigte. Dies war keine Einschränkung des Designs der Karte, da andere Verträge in den Trainingsdaten diese Verbindung aufzeigten. Es war eine Inkonsistenz darin, wie das Werkzeug entschied, die Karte aufzubauen. Da die Verbindung fehlte, hatte der Computer keine Möglichkeit, das Angriffsmuster zu sehen, obwohl das Muster direkt im Code vorhanden war.

Um zu beweisen, dass dieses fehlende Puzzleteil den Ausfall des Systems verursachte, bauten die Forscher einen minimalen, zweckgebundenen Vertrag, der eine voll ausnutzbare Reentrancy-Schwachstelle enthielt. Sie verwendeten einen Variablennamen, der bekanntlich auf der zugelassenen Liste stand, um sicherzustellen, dass das erste Problem mit der Umbenennung nicht interferierte. Sie speisten diesen Vertrag in das System ein. Das Ergebnis war eine klare Fehlklassifizierung: Das System stufte den gefährlichen Vertrag als sicher ein. Der Grund war einfach und direkt. Weil das Werkzeug versäumte, die Verbindung zwischen dem externen Aufrufer und der vulnerablen Funktion zu zeichnen, fehlte der Karte das kritische Signal, das zur Identifizierung der Bedrohung nötig war. Der Computer lag nicht bei seiner Berechnung falsch; er arbeitete lediglich mit einem unvollständigen Bild. Die Information, die für die richtige Entscheidung erforderlich war, war verworfen worden, noch bevor der Computer überhaupt anfing zu denken.

Diese Erkenntnisse legen nahe, dass die in früheren Studien berichteten hohen Genauigkeitswerte irreführend sind, da sie unter Bedingungen gemessen wurden, die diese Fehler nicht offenlegten. Die Systeme funktionierten nur deshalb gut, weil die Testdaten zufällig genau die Namen und Muster verwendeten, die das Werkzeug erkennen konnte. In der realen Welt, in der Code mit unterschiedlichen Namenskonventionen und Strukturen geschrieben wird, könnten diese Systeme lautlos versagen. Die Forscher betonen, dass die Verbesserung des KI-Modells selbst dieses Problem nicht lösen wird. Keine Menge an besserem Training oder mehr Daten kann ein Problem beheben, wenn die Karte bereits falsch gezeichnet wurde. Die Lösung erfordert eine Änderung der Art und Weise, wie der Code in eine Karte umgewandelt wird, weg vom einfachen Namensabgleich hin zu einem tieferen Verständnis dessen, was der Code tatsächlich tut. Bis das Fundament repariert ist, bleiben die auf ihm aufgebauten Sicherheitssysteme anfällig für genau die Angriffe, die sie eigentlich verhindern sollen.