Perte de 1,8 million de dollars pour le protocole DeFi Abracadabra
Le protocole DeFi Abracadabra a subi une perte de 1,8 million de dollars après qu’un attaquant a exploité une simple erreur de logique dans sa fonction de lot. Les analystes de Hacken affirment que l’attaquant a blanchi des fonds via Tornado Cash.
Contexte de l’attaque
Début octobre, Abracadabra, un protocole de prêt DeFi permettant aux utilisateurs d’emprunter son stablecoin MIM en utilisant des tokens déposés comme garantie, a de nouveau été victime d’une attaque. Cette fois, un attaquant a utilisé une faille logique dans la fonction de lot du protocole pour emprunter sans fournir de garantie, de la même manière qu’un projet forké avait été touché quelques jours auparavant, selon une note de recherche partagée par Hacken avec crypto.news.
Fonctionnement d’Abracadabra
Abracadabra a été conçu pour permettre aux utilisateurs d’utiliser des tokens générant des intérêts comme garantie afin d’emprunter un token indexé sur le dollar américain, appelé Magic Internet Money (MIM). Le système repose sur deux éléments : les Chaudrons, qui gèrent les règles d’emprunt, et le DegenBox, le coffre partagé qui détient réellement les tokens. En résumé, vous déposez une garantie dans un Chaudron, et le DegenBox garde une trace de l’argent en coulisses.
La faille exploitée
La version courte de ce qui a mal tourné est la suivante : un drapeau de sécurité, censé forcer une vérification finale pour s’assurer qu’un emprunteur dispose réellement d’une garantie, a été désactivé au sein d’une seule transaction. Comme le souligne le rapport de Hacken, l’attaquant
« a exploité une faille logique dans la fonction cook d’Abracadabra, lui permettant d’emprunter des tokens MIM puis de réinitialiser immédiatement le drapeau de validation qui était censé vérifier s’il avait suffisamment de garantie. »
Cela a permis un emprunt unique, sans garantie, à travers plusieurs Chaudrons.
Le mécanisme de l’attaque
Voici comment le flux a fonctionné, en termes simples. Abracadabra utilise une fonction groupée appelée cook, permettant aux utilisateurs d’effectuer plusieurs actions en une seule transaction. Par exemple, déposer une garantie et emprunter en un seul clic. L’une de ces actions, comme l’étape « emprunter », définit un drapeau nommé needsSolvencyCheck sur vrai, ce qui signifie « à la fin de cette transaction, vérifiez que l’emprunteur est solvable. » Cependant, une autre action pouvant être exécutée dans le même lot appelle _additionalCookAction(…). Comme le souligne Hacken, cette fonction a été déclarée comme « virtuelle » et n’a jamais été implémentée, renvoyant par défaut un objet vide où tout était défini sur faux, y compris le drapeau needsSolvencyCheck.
En conséquence, l’attaquant a appelé l’action d’emprunt, puis a exécuté l’action par défaut qui a réinitialisé le drapeau, et à la fin, le protocole n’a jamais vérifié la solvabilité. Les analystes affirment que l’attaquant a frappé six Chaudrons d’un coup, prenant environ 1,79 million de MIM et l’échangeant contre de l’ETH. Les attaquants ont exploité la vulnérabilité et ont systématiquement traversé six Chaudrons différents, drainant chacun « en utilisant la même technique avec un appel de fonction cook dédié, » expliquent les analystes.
Blanchiment des fonds
Après l’échange, l’attaquant a acheminé les fonds via Tornado Cash, un protocole de mixage crypto, en envoyant principalement 10 ETH chacun, progressivement au cours de la journée suivante. Ce n’est pas la première fois que le code CauldronV4 d’Abracadabra est impliqué dans des problèmes. D’autres incidents plus tôt cette année ont exploité différents cas limites dans la même famille de contrats.
Ce qui est intéressant, c’est la rapidité avec laquelle le déploiement forké a réagi. Selon le rapport, un fork appelé Synnax a mis en pause ou retiré de la liste blanche son maître CauldronV4 sur son propre DegenBox quelques jours avant le drain d’Abracadabra, suggérant que l’équipe du fork avait identifié le même schéma de vulnérabilité, indiquant que le risque était visible pour les équipes surveillant le code, s’il n’était pas corrigé.
