Le 5 mars 2024, l'échange décentralisé WOOFi a perdu environ 8,75 millions de dollars sur son déploiement Arbitrum après qu'un attaquant a exploité l'algorithme synthetic proactive market making (sPMM) du projet. La cause immédiate : l'oracle de prix du jeton WOO était fixé à l'adresse zéro — Chainlink n'avait jamais été configuré pour ce jeton — donc le sPMM acceptait tout prix extrême vers lequel l'attaquant le poussait.
Ce qui s'est passé
L'algorithme sPMM de WOOFi était conçu pour donner aux utilisateurs DEX une exécution similaire aux CEX en tarifant dynamiquement les trades contre un oracle de référence. Chaque jeton dans le système était censé avoir un feed de prix Chainlink configuré via une fonction admin pour que le sPMM puisse vérifier la cohérence des prix qu'il générait.
Pour le jeton WOO lui-même — l'actif natif du protocole — la fonction admin définissant l'oracle Chainlink n'avait jamais été appelée. L'adresse de l'oracle est restée à sa valeur par défaut : address(0). Lorsque le sPMM cherchait le prix de référence de WOO, il ne recevait aucune borne utilisable — et acceptait tout ce que le calcul interne de l'algorithme produisait, peu importe combien extrême.
L'attaque :
- Emprunt flash de ~7,7M WOO plus plusieurs autres jetons.
- Vente du WOO dans WOOFi, poussant le prix WOO interne du sPMM vers zéro via des dumps répétés.
- Sans oracle pour borner le calcul, le prix interne du sPMM a chuté à essentiellement zéro.
- Échange de 10M WOO hors de WOOFi dans la même transaction, payant presque rien à cause du prix interne manipulé.
- Répété trois fois en 13 minutes.
Profit net après remboursement des flash loans : ~8,75 M$.
Conséquences
- WOOFi a mis en pause le contrat sPMM v2 affecté pendant environ deux semaines en livrant une version corrigée avec configuration d'oracle appropriée.
- L'attaquant s'est vu offrir une prime white-hat de 10 % pour le retour des fonds ; aucun retour.
- Le protocole a absorbé la perte depuis les réserves d'équipe et de trésor.
Pourquoi c'est important
WOOFi est l'une des études de cas les plus claires pour pourquoi « l'oracle est la frontière de confiance » s'applique seulement si l'oracle est effectivement câblé. Le code sPMM était correct. L'intégration de l'oracle était correcte. Le script de déploiement qui appelle la fonction admin pour définir l'oracle pour chaque nouveau jeton a été manqué pour WOO — et le système a silencieusement dégradé vers « fais confiance aux nombres internes de l'algorithme » au lieu de « vérifie contre une source externe ».
La leçon — que les scripts de déploiement doivent être vérifiés pour leur complétude, de bout en bout, contre les préconditions documentées du protocole — a poussé l'élan plus large vers :
- Des contrôles d'invariants post-déploiement qui vérifient chaque valeur de configuration attendue avant que les contrats ne soient mis en service.
- Des gardes d'initialisation qui revert jusqu'à ce que toute la configuration requise ait été définie.
- Des « checklists » de déploiement imposées dans le code — patterns de modifiers qui empêchent les fonctions privilégiées d'être appelables jusqu'à ce que la configuration soit complète.
Un protocole peut passer chaque audit et toujours livrer en production avec un oracle non défini. La pratique défensive est de rendre cela impossible au niveau du contrat, pas en s'appuyant uniquement sur la discipline opérationnelle.
Sources & preuves on-chain
- [01]halborn.comhttps://www.halborn.com/blog/post/explained-the-woofi-hack-march-2024
- [02]cyfrin.iohttps://www.cyfrin.io/blog/hack-analysis-into-woofi-exploit
- [03]woox.iohttps://woox.io/en/blog/woofi-spmm-exploit-post-mortem