Seneca Chamber Approval-Drain

Am 28. Februar 2024 verlor das Stablecoin-Protokoll Seneca 6,4 Millionen Dollar, die Nutzern entzogen wurden, die dem Chamber-Vertrag des Protokolls unbegrenzte Token-Approvals erteilt hatten. Der Vertrag hatte keine Pausable-Funktion — als der Angriff erkannt wurde, hatte das Team keine Möglichkeit, ihn während des Ablaufs zu stoppen. Der Angreifer gab 80 % der gestohlenen Mittel gegen eine Bug-Bounty von 20 % zurück.

Was geschah

Senecas Chamber-Vertrag war ein privilegierter Pfad, der Token-Bewegungen im Namen von Nutzern abwickelte, die Seneca die Berechtigung zum Ausgeben ihrer Token erteilt hatten. Dem Vertrag fehlte eine kritische Validierung: Er akzeptierte vom Aufrufer gelieferte Parameter, die bestimmten, wessen Token bewegt und wohin sie geschickt werden sollten, ohne zu überprüfen, ob der Vorgang vom betroffenen Nutzer autorisiert war.

Für Nutzer, die Senecas Chamber-Vertrag unbegrenzte Token-Approvals erteilt hatten — das Standardmuster für jedes DeFi-Protokoll, das Nutzer-Token routinemäßig bewegen muss — bedeutete die fehlende Validierung, dass jeder Aufrufer:

1. Eine Wallet mit aktiver unbegrenzter Approval an Seneca identifizieren konnte.
2. Die anfällige Funktion des Chamber mit der Adresse des Opfers als Quelle und der Adresse des Angreifers als Ziel aufrufen konnte.
3. Die genehmigten Token des Opfers direkt abziehen konnte.

Der Angriff fegte innerhalb eines kurzen Zeitfensters ~6,4 Mio. $ über mehrere Opfer-Wallets hinweg.

Erschwerend kam hinzu: Senecas Vertrag hatte das Pausable-Muster nie implementiert — eine standardisierte OpenZeppelin-Primitive, die einem Protokoll-Admin erlaubt, bestimmte Funktionen oder den gesamten Vertrag im Notfall zu pausieren. Als das Team auf den laufenden Exploit aufmerksam wurde, hatte es keine Möglichkeit, ihn zu stoppen. Der Drain lief für die gesamte Dauer weiter, die der Angreifer wählte.

Nachwirkungen

• Seneca kontaktierte den Angreifer öffentlich und bot eine 20 %-Bug-Bounty für die Rückgabe der Mittel an.
• Am 29. Februar gab der Angreifer rund 1.537 ETH (~5,3 Mio. $) an eine von Seneca kontrollierte Wiederherstellungsadresse zurück und behielt 300 ETH (~1 Mio. $) als Bounty.
• Seneca stellte den Betrieb ein — indem es Nutzern empfahl, alle Approvals für den Chamber-Vertrag zu widerrufen, da das Protokoll selbst nicht pausiert werden konnte.
• Das Team lieferte ein neu entworfenes Protokoll mit ordentlichen Pausable-Kontrollen und Parameter-Validierung; die breitere Vertrauenswiederherstellung verlief ungleichmäßig.

Warum es zählt

Der Vorfall bei Seneca ist das Lehrbuchbeispiel dafür, warum Notfall-Pause-Funktionen für jedes Protokoll, das Nutzer-Approvals hält, nicht optional sind. Das Pausable-Muster ist:

• In der Standardvertragsbibliothek von OpenZeppelin dokumentiert.
• Als einzeiliger Modifier verfügbar, der jede Funktion schützt.
• Zur Deployment-Zeit trivial zu implementieren.

Dennoch war es in Senecas Vertrag weggelassen worden — höchstwahrscheinlich als bewusste Designentscheidung, um die „Dezentralisierung" durch Entfernung administrativer Kontrollpunkte zu maximieren. Der Preis dieser Entscheidung war, dass das Team zum Zuschauer wurde, während die Mittel seiner Nutzer aktiv abgezogen wurden.

Die strukturellen Lehren:

1. Dezentralisierung als Designbegründung für das Weglassen von Sicherheitskontrollen ist ein wiederkehrendes Muster, das wiederkehrende Verluste produziert. Der Trade-off — „keine Admin-Pause" vs. „Nutzer tragen die volle Auswirkung jedes Bugs" — wird Nutzern beim Einzahlen selten so klar dargestellt.

2. Approval-basierte Protokolle erben die Verantwortung, sicher pausierbar zu sein, weil jeder Nutzer, der ihnen Berechtigungen erteilt hat, jedem zukünftigen Bug ausgesetzt ist. Der Maßstab für diese Protokolle sollte höher liegen, nicht niedriger als bei Protokollen mit begrenzter Exposition.

3. Die Rückgabe von 80 % ist einer von mehreren jüngsten Fällen, in denen Angreifer lieber verhandelt als gewaschen haben — wahrscheinlich, weil die On-Chain-Forensik gut genug geworden ist, dass ein vollständiges Auscashen eines 6-Mio.-$-Exploits riskant und langsam ist. Die effektive Bounty des Angreifers von 1 Mio. $ auf eine 6,4-Mio.-$-Operation könnte die rationale Wahl gewesen sein.

Moderne Protokolle werden zunehmend mit Pausable + Notfall-Multi-Sig + community-gesteuerten Circuit Breakers als Standard ausgeliefert. Senecas Verlust ist einer von mehreren Vorfällen, die diese Muster zu verbindlicher Praxis statt zu nice-to-haves gemacht haben.