Wie ein veralteter Aztec-Vertrag drei Jahre nach seiner Stilllegung 2,1 Millionen Dollar verlor

Wie der Angreifer die ZK-Rollup-Verifikation aushebelte

Der Angriff zielte auf die Schnittstelle zwischen der Logik zur Überprüfung der Zero-Knowledge-Beweise und der endgültigen Abwicklung auf dem Ethereum-Layer-1. Laut CertiK überprüfte eine der Verifikationsfunktionen des Vertrags nur den Anfang eines eingereichten Beweises. Das bedeutete, dass die Parameter, die für die Autorisierung von Token-Transfers zuständig waren, nie vollständig validiert wurden . So konnte der Angreifer einen Beweis einreichen, der die ersten Prüfungen bestand, während er in den tieferen Nutzdaten schädliche Auszahlungsanweisungen enthielt.

Die anschließende Analyse des Sicherheitsunternehmens SlowMist identifizierte eine Ursache in den Traversal-Limits der L1-Abwicklungsschleife innerhalb von RollupV3. Der Angreifer nutzte eine Diskrepanz zwischen numRealTxs und decoded_slots aus, was die Einreichung von 31 leeren Slots zum L2-State-Root über einen ZK-Beweis ermöglichte, ohne dass diese auf dem L1-Vertrag vollständig verifiziert wurden . Letztlich konstruierte der Angreifer 14 ZK-Rollup-Beweise; die letzten sieben Beweise leerten jeweils einen anderen Vermögenswert in separaten Transaktionen aus dem Vertrag .

Eine bewusste Aufgabe der Kontrolle

Was diesen Vorfall einzigartig macht, ist die Tatsache, dass der Angriff strukturell nicht zu stoppen war – und zwar konstruktionsbedingt. Aztec Connect wurde im März 2023 abgeschaltet, und die Nutzer hatten über ein Jahr Zeit, ihre Gelder abzuheben . Im Jahr 2024 ging Aztec Labs sogar noch einen Schritt weiter und gab alle Admin-Schlüssel und die Kontrolle über das System vollständig ab. Die Verträge wurden damit vollständig unveränderlich: kein Upgrade-Mechanismus, kein Besitzer und entscheidend – keine Pausefunktion .

„Aztec Connect wurde vor 3 Jahren eingestellt. Aztec Labs besitzt keine Admin-Schlüssel oder Kontrolle über das System; es kann weder pausiert noch aktualisiert werden“, erklärte das Team auf X nur wenige Stunden nach dem Exploit und bestätigte, dass etwa 2,1 Millionen Dollar aus dem unveränderlichen Vertrag verschoben worden waren . Sie betonten, dass das aktuelle Aztec Network und sein AZTEC ERC-20-Token nicht betroffen seien, räumten jedoch ein, dass es keinen Mechanismus gebe, um die verlorenen Gelder zurückzuholen .

Trotz des verlängerten Auszahlungsfensters und der Kommunikation rund um die Stilllegung blieben zum Zeitpunkt des Angriffs noch etwa 2,1 Millionen Dollar an verbliebenen Nutzergeldern in den alten Verträgen stecken . Die Mittel befanden sich in einer Art Schwebezustand: Niemand konnte sie legitim abrufen, ohne mit dem veralteten Rollup zu interagieren, und niemand konnte eingreifen, als die Schwachstelle ausgelöst wurde.

Das große Ganze: Zombie-Verträge im DeFi-Bereich

Der Aztec Connect-Exploit ist ein Paradebeispiel für das sogenannte „Zombie-Vertrag“-Problem in der dezentralen Finanzwelt. Unveränderliche Smart Contracts lösen sich nicht einfach in Luft auf, wenn ein Projekt den Betrieb einstellt. Sie existieren mit ihrer gesamten Logik – und den darin enthaltenen Werten – auf der Blockchain weiter und halten oft auf unbestimmte Zeit Nutzergelder fest. Wenn Admin-Schlüssel im Streben nach vollständiger Dezentralisierung aufgegeben werden, wird der Vertrag zu einem permanenten, nicht korrigierbaren Honigtopf. Jede unentdeckte Schwachstelle wird so zu einer Zeitbombe, die Jahre später ohne jede Abwehrmöglichkeit gezündet werden kann .

Dieses Risiko ist asymmetrisch. Projekte, die die Kontrolle aufgeben, gewinnen an Glaubwürdigkeit, weil sie keine Hintertür haben. Nutzer jedoch, die ihre Gelder während der Abschaltungsphase nicht abziehen, tragen das volle Verlustrisiko. Der Fall Aztec zeigt, dass selbst nach drei Jahren Millionen von Dollar in einem Vertrag stecken bleiben können, den alle für tot hielten.

Für DeFi-Teams, die ein Protokoll stilllegen wollen, ist die Lektion eindeutig. Vor der Aufgabe der Admin-Schlüssel müssen Projekte entweder alle Auszahlungen zwangsweise abschließen oder einen zeitbasierten Notfallmechanismus implementieren, der keine langfristige Admin-Kontrolle erfordert. Ohne diese Sicherheitsvorkehrungen wird verlassene, aber unveränderliche Infrastruktur unweigerlich Angreifer anziehen, die nach nicht behebbaren Schwachstellen suchen .