WOOFi sPMM Preismanipulation

Am 5. März 2024 verlor die dezentrale Börse WOOFi rund 8,75 Millionen Dollar auf ihrer Arbitrum-Bereitstellung, nachdem ein Angreifer den Synthetic Proactive Market Making (sPMM)-Algorithmus des Projekts ausnutzte. Die unmittelbare Ursache: Das Preis-Orakel des WOO-Tokens war auf die Null-Adresse gesetzt — Chainlink war für dieses Token nie konfiguriert worden —, sodass der sPMM jeden extremen Preis akzeptierte, zu dem der Angreifer ihn drückte.

Was geschah

WOOFis sPMM-Algorithmus war darauf ausgelegt, DEX-Nutzern CEX-artige Ausführung zu geben, indem er Trades dynamisch gegen ein Referenz-Orakel bepreiste. Jedes Token im System sollte einen Chainlink-Preis-Feed haben, der über eine Admin-Funktion konfiguriert war, sodass der sPMM die generierten Preise sanity-checken konnte.

Für das WOO-Token selbst — den nativen Vermögenswert des Protokolls — war die Admin-Funktion zum Setzen des Chainlink-Orakels nie aufgerufen worden. Die Orakel-Adresse blieb auf ihrem Standardwert: address(0). Wenn der sPMM den WOO-Referenzpreis nachschlug, erhielt er keine nutzbare Grenze — und akzeptierte, was auch immer die interne Berechnung des Algorithmus produzierte, egal wie extrem.

Der Angriff:

1. Flash-borgte ~7,7M WOO plus mehrere andere Tokens.
2. Verkaufte das WOO in WOOFi und drückte den internen WOO-Preis des sPMM durch wiederholte Dumps gegen null.
3. Ohne Orakel zur Begrenzung der Berechnung fiel der interne Preis des sPMM auf praktisch null.
4. Tauschte 10M WOO aus WOOFi in derselben Transaktion heraus, zahlte fast nichts wegen des manipulierten internen Preises.
5. Wiederholte dies dreimal innerhalb von 13 Minuten.

Nettogewinn nach Rückzahlung der Flash Loans: ~8,75 Mio. $.

Nachwirkungen

• WOOFi pausierte den betroffenen sPMM-v2-Vertrag für rund zwei Wochen, während eine korrigierte Version mit ordentlicher Orakel-Konfiguration ausgeliefert wurde.
• Dem Angreifer wurde eine 10%-Whitehat-Bounty für die Rückgabe der Mittel angeboten; keine Rückgabe.
• Das Protokoll absorbierte den Verlust aus Team- und Treasury-Reserven.

Warum es zählt

WOOFi ist eine der klarsten Fallstudien dafür, warum „das Orakel ist die Trust Boundary" nur gilt, wenn das Orakel tatsächlich angeschlossen ist. Der sPMM-Code war korrekt. Die Orakel-Integration war korrekt. Das Deployment-Skript, das die Admin-Funktion aufruft, um das Orakel für jedes neue Token zu setzen, wurde für WOO übersehen — und das System degradierte stillschweigend zu „vertraue den internen Zahlen des Algorithmus" statt „verifiziere gegen eine externe Quelle".

Die Lehre — dass Deployment-Skripte auf Vollständigkeit end-to-end gegen die dokumentierten Vorbedingungen des Protokolls geprüft werden müssen — hat den breiteren Push vorangetrieben zu:

• Post-Deployment-Invariantenprüfungen, die jeden erwarteten Konfigurationswert verifizieren, bevor Verträge live gehen.
• Initialisierungs-Guards, die reverten, bis alle erforderliche Konfiguration gesetzt ist.
• In Code erzwungene Deployment-„Checklisten" — Modifier-Muster, die privilegierte Funktionen daran hindern, aufrufbar zu sein, bis die Konfiguration vollständig ist.

Ein Protokoll kann jedes Audit bestehen und immer noch mit einem ungesetzten Orakel in Produktion gehen. Die defensive Praxis ist, dies auf Vertragsebene unmöglich zu machen, statt sich allein auf operative Disziplin zu verlassen.