680-Millionen-Dollar-Warnung: Die meisten DeFi-Angriffe liegen außerhalb des Audit-Bereichs

Autor: Liam 'Akiba' Wright, cryptoslate

Übersetzung: Chopper, Foresight News

Im Bereich dezentraler Finanzen wird „auditiert“ oft als Sicherheitsgarantie für das gesamte Projekt angesehen. Tatsächlich deckt ein Audit jedoch nur einen bestimmten Zeitpunkt, bestimmten Code, bestimmte Komponenten und Versionen ab. Alles, was außerhalb dieses Bereichs hinzugefügt, entfernt oder verändert wird, kann zu völlig anderen Audit-Ergebnissen führen.

Eine neue Preprint-Studie beziffert diese Lücke konkret. Forscher des Sicherheitsunternehmens ack3 und der Tschechischen Technischen Universität Prag analysierten 135 Sicherheitsvorfälle im ersten Halbjahr 2025 mit Verlusten von insgesamt 939,86 Millionen US-Dollar. Sie fanden heraus, dass bei 68 dieser Vorfälle öffentlich zugängliche Audit-Aufzeichnungen vor dem Vorfall identifizierbar waren.

In dieser Stichprobe von 68 Vorfällen ordneten die Forscher 46 Angriffspfade als vollständig außerhalb jedes nachvollziehbaren Audit-Bereichs ein; 20 Vorfälle lagen zumindest teilweise im Bereich eines Audits; die restlichen 2 konnten nicht zugeordnet werden. Vorfälle außerhalb des Audit-Bereichs machten 67,6 % der Gesamtzahl aus, aber 94,4 % der gemeldeten Gesamtverluste.

Dieser erstaunliche Anteil ist weder eine Bewertung der Audit-Wirksamkeit noch ein Beweis dafür, dass Audit-Bereichsbeschränkungen Verluste verursachen. Er stellt lediglich die Verlustverteilung in der ausgewählten Stichprobe öffentlicher Sicherheitsvorfälle dar. Zwei außergewöhnlich große Vorfälle beeinflussen die Daten stark: Ohne den Kelp-DAO-Verlust von 292 Millionen US-Dollar und den Drift-Protocol-Verlust von 285 Millionen US-Dollar sinkt der Anteil der Verluste durch Angriffe außerhalb des Audit-Bereichs in derselben auditierten Stichprobe auf 72,1 %.

Trotz dieser Einschränkungen offenbart die Studie ein grundlegendes Sicherheitsvertrauensproblem: Ein Projekt behauptet, auditiert worden zu sein, aber Nutzer können nicht wissen, ob das tatsächlich laufende System, die Geldflüsse und die zugehörigen Kontrollmechanismen geprüft wurden.

Was die Daten wirklich bedeuten

Die Studie von ack3 umfasst den Zeitraum vom 1. Januar bis 29. Juni 2025 mit insgesamt 122 bestätigten Angriffen und 13 Verdachtsfällen. In der gesamten Stichprobe wurden bei 35 Vorfällen keine Audit-Aufzeichnungen gefunden und bei 32 war die Audit-Historie unbekannt; diese beiden Kategorien wurden nicht in die Statistik der oben genannten 68 Vorfälle einbezogen.

In der Stichprobe von 68 Vorfällen beliefen sich die Verluste außerhalb des Audit-Bereichs auf 680,97 Millionen US-Dollar bei Gesamtverlusten von 721,24 Millionen US-Dollar, woraus sich der Wert von 94,4 % ergibt. Ohne Kelp DAO und Drift Protocol betrugen die Verluste außerhalb des Audit-Bereichs 103,97 Millionen US-Dollar bei Gesamtverlusten von 144,24 Millionen US-Dollar, also 72,1 %. Die JSON-Datei des Datensatzes ermöglicht die Reproduktion der Ereignisklassifizierung und Verlustbeträge.

Die Kennzeichnung „innerhalb/außerhalb des Audit-Bereichs“ basiert auf der Einschätzung der Forscher anhand öffentlicher Belege. Das Forschungsteam durchsuchte Archive von Projekten und Audit-Firmen, fand Audit-Berichte vor den Angriffen und verglich den endgültigen Angriffspfad mit dem geprüften Code, den Versionen und den Audit-Ausschlüssen. Die Studie ist ein sechsseitiges Preprint, das gemeinsam mit dem Herausgeber des Datensatzes erstellt wurde; zwei Autoren gehören zum Sicherheitsaudit-Unternehmen ack3.

Der Studie fehlt eine Kontrollgruppe nicht angegriffener Systeme und sie erfasst nicht die Dauer der Risikoexposition der einzelnen Systeme. Daher kann sie nicht belegen, dass auditierte Protokolle insgesamt sicherer sind, keine Ereigniswahrscheinlichkeiten schätzen und nicht bestätigen, dass „außerhalb des Audit-Bereichs“ die direkte Ursache jedes Verlusts war. Einige nicht öffentliche Audits und private Vorfälle könnten fehlen, und die gemeldeten Verlustdaten sind nicht vollständig vergleichbar.

Die Studie kann daher nur begrenzte Schlussfolgerungen ziehen: Audit-Aufzeichnungen und Audit-Abdeckung sind zwei unabhängige Indikatoren. Ein geprüfter Smart Contract bedeutet nicht, dass Vertrags-Upgrades, privilegierte Schlüssel, Frontends, Relayer, Orakel, Cloud-Dienste oder Notfallprozesse denselben Sicherheitsstandard genießen.

Zwei Vorfälle im August bestätigen diesen Unterschied aus unterschiedlichen Blickwinkeln. Der ICON-Network-Fall zeigt anschaulich, wie zwei geprüfte Codeabschnitte an der Grenze zweier Prüfschritte versagten; der aelf-Sicherheitsvorfall im August ist ein anderer Fall, bei dem die vorhandenen Audit-Belege den Angriffspfad nicht dem vorherigen Audit-Bereich zuordnen können.

ICON Network: Ein Beispiel für Versagen an Prüfgrenzen

Beim Replay-Angriff auf das ICON Network am 27. August interpretierten zwei Module der Auszahlungskette dieselbe Nachricht unterschiedlich.

Laut dem nachträglichen Bericht der ICON Foundation stützte sich der Migrationsvertrag auf die höherwertigen Bits der Auszahlungsnachrichten-Sequenznummer, um die Einzigartigkeit der Nachricht zu bestimmen; die kryptografische Signatur deckte jedoch nur die niedrigeren 256 Bits der Sequenznummer ab. Der Angreifer veränderte die nicht signierten höherwertigen Bits und reichte innerhalb von etwa 20 Minuten zwei legitim signierte Auszahlungsnachrichten 1492 Mal erneut ein, wobei 1490 Aufrufe erfolgreich ausgeführt wurden.

Der Replay-Angriff setzte 119,866 Millionen ICX und 531.600 bnUSD frei. Zum Zeitpunkt der Veröffentlichung des Berichts bestätigte ICON einen Nettoverlust von etwa 150,2 ETH plus 31.204 USDC. Die Stiftung gab an, dass 531.600 bnUSD und 1,366 Millionen SODA wiederhergestellt wurden und Nutzereinlagen, Kontostände und Positionen nicht betroffen waren.

ICON erklärte, dass der Migrationsvertrag extern auditiert worden sei und die Audit-Empfehlungen umgesetzt wurden, einschließlich entsprechender Änderungen im selben Modulbereich; die zugehörige Relayer-Logik wurde ebenfalls separat geprüft. Die Audit-Liste der Sodax-Entwicklungsdokumentation enthält 8 Berichte zu verschiedenen Komponenten, darunter einen Sodax-Relayer-Auditbericht vom November 2025.

Der nachträgliche Bericht stellt jedoch fest, dass die präzise Diskrepanz zwischen der Einzigartigkeitsprüfung und dem signierten Prüfwert nicht in den Ergebnissen dieser Audits enthalten war. Ein einfaches Label „auditiert“ kann Nutzern nicht zeigen, ob beide Enden der Auszahlungskette dieselben Kriterien für „Nachrichteneinzigartigkeit“ anwenden.

Die Reaktionszeitachse offenbart eine weitere Art von Grenzproblem. Die erste automatisierte Warnung von ICON wurde um 02:08 UTC ausgelöst, etwa 7 Minuten nach Angriffsbeginn. Das Personal begann gegen 03:40 mit der Untersuchung, pausierte um 03:53 die betroffenen Verträge und um 06:18:54 das gesamte Netzwerk.

Zwischen der ersten Warnung und der vollständigen Notfallbehandlung lagen etwa 90 Minuten. ICON führt dies auf Anpassungen des Warnmechanismus zurück; die Warnregel hatte bei früheren Netzwerkverbindungsfehlern viele Fehlalarme erzeugt und wurde daher nicht mit hoher Priorität an das Bereitschaftspersonal gemeldet. Die Stiftung plant die Einführung automatischer Abschaltauslöser, die Senkung der Sicherungsschwellen und eine gezielte Überprüfung der Nachrichteneinzigartigkeit und des Replay-Schutzes.

Solche Risikokontrollmechanismen ersetzen kein Audit, aber sie beantworten eine andere entscheidende Frage: Kann das System Risiken schnell erkennen und isolieren, wenn präventive Maßnahmen versagen?

aelf: Sicherheitsgarantien müssen kontinuierlich aktualisiert werden

Der Sicherheitsvorfall bei aelf im August bestätigt diese Ansicht aus einem anderen Blickwinkel. Öffentliche Informationen beschreiben eine Laufzeit-Intrusion und kontrollierte Wiederherstellung, aber die vorhandenen Belege reichen nicht aus, um den Angriffspfad einem bestimmten vorherigen Audit-Bereich zuzuordnen.

Die offizielle Ankündigung des Projekts erklärt: Es existierte ein nicht autorisierter Smart Contract, der über Transaktionsparameter kodierte .NET-Assemblys und Anweisungen in die Ausführungskette der Knoten einschleusen konnte.

Der vorläufige Untersuchungsbericht führt den Vorfall auf Mängel bei der Laufzeit-Reflexion und der Prüfung des dynamischen Ladens sowie auf unzureichende Isolierung zwischen der Vertragsausführungsumgebung und sensiblen Knoten- und Infrastrukturressourcen zurück. aelf identifizierte insgesamt 155 zugehörige Transaktionen und 5 unabhängige Payload-Assemblys; die Payloads waren in der Lage, Host-Befehle auszuführen, externe Kommunikation zu versuchen, auf Knotenschlüssel zuzugreifen und Infrastruktur auszukundschaften.

Fähigkeiten bedeuten nicht, dass alle Payloads erfolgreich ausgeführt wurden oder dass der Angreifer alle Ziel-Zugangsdaten erlangte und sensible Daten abflossen. aelf gab an, Signaturschlüssel und Infrastruktur-Zugangsdaten gemäß den Standards für potenzielle Kompromittierung rotiert zu haben.

Bis zum 11. September war diese Schlussfolgerung noch vorläufig. Der offizielle Blog von aelf veröffentlichte nach dem 26. August kein spezifisches Update zu diesem Vorfall. Die Ankündigung vom 26. August versprach Folge-Updates und eine abschließende Überprüfung.

Die technischen Sicherheitsdokumente von aelf besagen, dass die Blockchain und der ELF-Token-Vertrag mehreren Audit-Runden unterzogen wurden und keine Sicherheitsprobleme gefunden wurden. Die vorhandenen öffentlichen Seiten können jedoch den Laufzeitpfad des August-Angriffs keinem Audit-Bericht vor dem Vorfall zuordnen. Daher fehlen ausreichende Belege, um den Vorfall entweder als Audit-Versäumnis oder als Fehler außerhalb des Audit-Bereichs einzustufen.

Diese Unsicherheit selbst ist aufschlussreich. Ein zeitgestempelter Audit-Bericht entfernt sich allmählich vom aktuellen Systemcode, den Abhängigkeiten und dem tatsächlichen Betriebszustand. Nutzer benötigen einen versionierten Sicherheitsdatensatz, um diese Unterschiede abzubilden.

Dieser Sicherheitsdatensatz sollte Folgendes enthalten: geprüfte Repositories und Code-Commit-Versionen, bereitgestellte Vertragsadressen, ausgeschlossene Komponenten, privilegierte Rollen, Abhängigkeiten; außerdem Vertrags-Upgrades nach Abschluss des Audits, Schlüsselverwahrung und Rotationsmechanismen, Laufzeit-Isolationsrichtlinien, Warn- und Sicherungsmechanismen sowie den zeitgestempelten Status der Vermögenswiederherstellung, wobei bestätigte Verluste, eingefrorene Vermögenswerte und ungelöste Risikoexpositionen unterschieden werden.

Dies negiert nicht den Wert von Audits, sondern gleicht Audit-Werbung mit der tatsächlichen Arbeit ab und verknüpft sie mit dem aktuell laufenden System.

Ein Audit-Abzeichen kann nicht beantworten, ob die geprüften Komponenten, das bereitgestellte System und die Mechanismen zur Fehlerbehandlung noch innerhalb derselben Sicherheitsgrenze liegen.