Exploit de périphérie d'Exactly Protocol
L'attaquant a passé un faux marché et un permit forgé au DebtManager d'Exactly sur Optimism ; leverage() ne validait rien, drainant 7,3 M$ sur 117 comptes.
- Date
- Victime
- Exactly Protocol
- Chaîne(s)
- Statut
- Fonds dérobés
Le 18 août 2023, le protocole de prêt basé sur Optimism Exactly Protocol a été exploité pour environ 7,3 millions de dollars en ETH. Le bug se trouvait dans le contrat de périphérie DebtManager — spécifiquement, la fonction leverage() qui acceptait à la fois une adresse de contrat de marché et une signature de permit comme entrées et ne validait ni l'une ni l'autre. 117 comptes utilisateurs ont vu leurs dépôts drainés. La TVL du protocole est tombée de 37 M$ à 11,74 M$ — une baisse de 70 % — en quelques heures.
Ce qui s'est passé
Les marchés de prêt principaux d'Exactly étaient rigoureusement audités ; les contrats de périphérie les entourant — des contrats utilitaires qui aidaient les utilisateurs à effectuer des opérations en plusieurs étapes comme l'emprunt avec effet de levier — étaient à l'origine hors du périmètre d'audit. Le DebtManager était un tel contrat de périphérie.
La fonction leverage() sur DebtManager acceptait :
- Un paramètre
marketidentifiant avec quel marché Exactly interagir. - Une signature
permitautorisant les transferts de tokens pour le compte de l'utilisateur.
La fonction utilisait ces entrées pour effectuer une série d'opérations qui déplaçaient finalement la valeur des positions existantes de l'utilisateur dans des marchés Exactly légitimes. La faille fatale : aucun des deux paramètres n'était validé :
- Le paramètre
marketétait accepté tel quel, donc un attaquant pouvait passer l'adresse d'un faux contrat de marché qu'il avait déployé. - Le
permitétait traité via la logique ERC-2612 standard, mais la fonction ne vérifiait pas que le permit avait été signé pour le bon objet ou par le participant légitime du marché.
L'attaquant :
- A déployé un faux contrat « marché » qui implémentait l'interface attendue mais faisait ce que l'attaquant voulait en interne.
- A forgé un permit pour l'opération — la signature du permit était techniquement valide pour l'appel de fonction, mais sa sémantique ne correspondait pas à une opération de leverage Exactly légitime.
- A appelé
leverage()avec les deux entrées — la fonction a utilisé les réponses du faux marché pour contrôler comment la valeur était déplacée entre les contrats légitimes d'Exactly, routant finalement le collatéral utilisateur vers l'attaquant.
Drainé depuis 117 comptes pour un total d'environ 7,3 M$.
Conséquences
- Exactly a suspendu le protocole en quelques heures, suivant son runbook de procédure d'urgence.
- L'équipe a publiquement ré-engagé ABDK, l'auditeur original, pour un nouveau cycle d'audits — cette fois incluant les contrats de périphérie qui avaient été exclus du périmètre d'audit original.
- Un plan de remboursement a été lancé, financé par les revenus du protocole et les réserves de l'équipe.
- Les fonds volés ont été blanchis via Tornado Cash ; aucune récupération publique.
Pourquoi c'est important
L'incident d'Exactly Protocol est l'un des cas les plus clairs pour le périmètre d'audit comme contrôle de sécurité à part entière. Les marchés de prêt étaient correctement audités et fonctionnaient comme prévu. Le bug était dans les contrats qui parlaient aux marchés — du code de périphérie que l'équipe avait déployé pour améliorer l'UX mais qui n'était pas sous la même rigueur de sécurité que le protocole principal.
Les leçons structurelles :
-
Les contrats de périphérie font partie de la surface d'attaque du protocole même quand ils ne détiennent pas directement de fonds utilisateurs. Si un contrat de périphérie peut déplacer des fonds utilisateurs via des permits ou des approvals, il a les mêmes exigences de sécurité que le cœur.
-
Le périmètre d'audit doit être explicite sur ce qui n'est pas couvert — et tout contrat exclu de l'audit devrait être exclu du déploiement en production jusqu'à ce qu'il ait sa propre revue dédiée.
-
Les signatures de permit sont une primitive puissante qui requiert une validation sémantique soigneuse — une signature ERC-2612 valide ne vous dit pas pourquoi le signataire a autorisé l'opération, seulement qu'il a signé une opération. Toute fonction qui consomme des permits doit valider que les paramètres du permit correspondent à son objet prévu.
La réponse d'Exactly Protocol — ré-engager l'auditeur original avec un périmètre étendu — est devenue un pattern récurrent dans la remédiation post-incident à travers la DeFi. La leçon, payée en 7,3 M$ des utilisateurs affectés, est la bonne même si le coût a été élevé.
Sources & preuves on-chain
- [01]halborn.comhttps://www.halborn.com/blog/post/explained-the-exactly-protocol-hack-august-2023
- [02]theblock.cohttps://www.theblock.co/post/246196/exactly-protocol-exploited-7-million-optimism-layer-2-network
- [03]olympix.securityhttps://olympix.security/blog/exactly-protocol-lost-7-3m-the-code-worked-the-assumptions-didnt