Ich prüfe nicht nur die eigene Infrastruktur, sondern gelegentlich auch die von anderen. Zuletzt habe ich einen Bug-Bounty-Fund bei TRON DAO eingereicht, über HackerOne, mit einer Einstufung, die ich ernst nehme.
Wer ich bin
Ich bin Lukas Weißmann, Gründer von NeoBild. Der Kern meiner Arbeit ist souveräne KI-Infrastruktur, lokal betrieben, offen dokumentiert. Ein zweiter, eng verwandter Strang ist Security-Research: Ich suche Schwachstellen in Systemen, auf die andere sich täglich verlassen, bevor es jemand mit anderen Absichten tut. Mein HackerOne-Profil (hackerone.com/weissmann93) sammelt diese Arbeit, TRON DAO ist eines der Programme, an denen ich aktiv bin.
Der Fund
Der Report trägt die Nummer 3734569 und betrifft eine Komponente der TRON Virtual Machine, konkret eine der eingebauten kryptografischen Precompiles, wie sie in praktisch jeder EVM-kompatiblen Chain existieren, um rechenintensive Operationen wie modulare Exponentiation nicht in normalem Smart-Contract-Bytecode nachbilden zu müssen. Genau solche Precompiles nehmen Eingabeparameter entgegen, die vor der Verarbeitung geprüft werden müssen. Fehlt diese Prüfung an einer Stelle, kann ein einzelner, gezielt konstruierter Aufruf eine Ressourcenanforderung auslösen, die weit über das hinausgeht, was ein legitimer Aufruf jemals bräuchte. Genau das ist die Schwachstellenklasse hinter CWE-770, Allocation of Resources Without Limits, und genau das habe ich gefunden.
Gefunden habe ich es nicht mit einem Scanner. Automatisierte Tools sind gut darin, bekannte Muster zu erkennen, aber sie verstehen selten, was eine Funktion eigentlich tun soll, und wo die Lücke zwischen Spezifikation und Implementierung liegt. Bei java-tron, dem öffentlichen Referenzclient von TRON, habe ich stattdessen den Code manuell gelesen, mit dem Fokus auf genau den Stellen, an denen externe Eingaben auf interne Allokationen treffen. Precompiles sind dafür ein besonders lohnendes Ziel: Sie laufen mit den Rechten der Node-Software selbst, nicht mit den Einschränkungen der Smart-Contract-Sandbox.
Diese Art von Audit ist langsamer als jeder Scan-Lauf. Man liest Funktion für Funktion, stellt sich die Frage, was der ursprüngliche Autor als gültige Eingabe vorausgesetzt hat, und prüft, ob der Code diese Annahme auch tatsächlich durchsetzt. Bei komplexen, seit Jahren gewachsenen Codebasen wie java-tron ist genau das der Punkt, an dem Annahmen und Realität auseinanderdriften, oft an Stellen, die ein automatisiertes Tool schlicht nicht als verdächtig einstuft, weil kein bekanntes Muster passt.
Die Einstufung: CVSS 8.3, High. Der Grund für diese Einschätzung ist einfach. Trifft eine einzelne Transaktion einen Full Node oder Validator mit dieser Anfrage, kann das genug Speicher binden, um den Betrieb des Knotens spürbar zu stören, ein klassisches Denial-of-Service-Risiko gegen Infrastruktur, die ein Netzwerk mit realem wirtschaftlichem Wert am Laufen hält.
Verantwortungsvolle Offenlegung
Ein Fund wie dieser ist kein Blogpost-Material, bevor ein Fix existiert. Das ist keine Förmlichkeit, sondern der eigentliche Sinn von koordinierter Offenlegung: Wer Details veröffentlicht, während die Lücke noch offen ist, liefert nicht Aufklärung, sondern eine Anleitung. Deshalb gibt es Plattformen wie HackerOne mit privater Triage, deshalb bleibt der Report unter Verschluss, bis das betroffene Projekt selbst entscheidet, was öffentlich wird und wann.
Aus genau diesem Grund verzichte ich hier bewusst auf alles, was über die allgemeine Schwachstellenklasse hinausgeht: keine Codezeilen, keine Funktionsnamen, keine Schritte, mit denen sich der Fehler nachstellen ließe. Zum Zeitpunkt dieses Artikels ist der Report auf HackerOne nicht öffentlich als disclosed markiert, also bleibt es bei dieser Flughöhe. Wer die technischen Details will, bekommt sie, sobald TRON DAO den Report freigibt, nicht früher.
Das gilt auch für den Umgang mit Timing. Ein High-Severity-Fund gegen produktive Blockchain-Infrastruktur ist kein Rennen um den ersten Blogpost. Zwischen Einreichung und öffentlicher Disclosure liegt bei seriösen Programmen bewusst Zeit, damit ein Fix entwickelt, getestet und ausgerollt werden kann, bevor irgendjemand außerhalb des Security-Teams die Details kennt. Wer diesen Zeitraum verkürzt, verschiebt das Risiko von der eigenen Reputation auf die Nutzer des Netzwerks.
Wo der Report aktuell steht
Der Report liegt TRON DAO über HackerOne vor und wird dort vom zuständigen Security-Team geprüft. Mehr lässt sich seriös nicht sagen, solange der Prozess läuft. Sobald sich das ändert, sei es durch eine öffentliche Disclosure oder eine Reaktion des Projekts, bekommt dieser Artikel eine technische Fortsetzung mit den Details, die jetzt bewusst fehlen.
Bis dahin bleibt der eigentliche Punkt derselbe, der auch hinter NeoBild als Projekt steht: Systeme, denen viele vertrauen, verdienen jemanden, der genau hinschaut, und einen Prozess, der Verantwortung vor Reichweite stellt.
Kommentare