La vulnérabilité de réentrée n'a pas été corrigée, FutureSwap a subi une série d'attaques entraînant une perte de 74 000 dollars.

Le protocole FutureSwap déployé sur Arbitrum a été victime de deux attaques en seulement quatre jours. Selon l’analyse de l’organisme de sécurité blockchain BlockSec, après la première attaque le 10 janvier, le protocole a de nouveau été ciblé le 11 janvier, avec une perte d’environ 74 000 dollars. Plus inquiétant encore, les deux attaques ont exploité la même vulnérabilité de réentrée, ce qui suggère que les mesures correctives après la première attaque n’ont peut-être pas complètement résolu le problème fondamental.

Analyse des techniques d’attaque

Principe de la vulnérabilité

La vulnérabilité de réentrée est l’un des risques de sécurité les plus courants et les plus dangereux dans les protocoles DeFi. Dans le cas de FutureSwap, la faille se trouve dans la fonction de réentrée 0x5308fcb1. L’attaquant a exploité cette porte d’entrée en profitant d’un défaut logique dans l’interaction avec le protocole.

Étapes spécifiques de l’attaque

• Déclenchement d’un appel exceptionnel via la fonction de réentrée 0x5308fcb1
• Répétition de l’appel de la fonction lors de l’exécution du contrat, contournant la vérification du solde
• Sur-émission de tokens LP (tokens de fournisseur de liquidité)
• Attente de la fin de la période de refroidissement pour racheter les actifs en sur-mortgage
• Extraction des profits

L’aspect clé de cette méthode d’attaque réside dans le décalage temporel : l’attaquant accumule une position LP fictive durant la refroidissement, puis, après dégel du système, récupère légitimement les actifs. Apparemment, il s’agit d’une transaction normale, mais en réalité, la quantité d’actifs obtenue dépasse largement ce qui aurait dû être.

Évaluation de l’impact de l’événement

Menace pour FutureSwap

Les attaques répétées indiquent que la correction de sécurité du protocole pourrait être insuffisante. Après la première attaque, l’équipe du projet a généralement effectué une audit d’urgence et une mise à jour du patch, mais la deuxième attaque a quand même réussi, ce qui suggère :

• La première correction n’était peut-être pas complète
• D’autres vulnérabilités similaires pourraient exister
• Le mécanisme de refroidissement pourrait nécessiter une refonte

Risque pour les fonds des utilisateurs

Bien que la perte cette fois soit “seulement” de 74 000 dollars, pour un protocole dont la sécurité est douteuse, cela porte un coup sérieux à la confiance des utilisateurs. Les fonds déjà présents dans le protocole exposent leurs détenteurs non seulement à un risque de perte directe, mais aussi à des difficultés de liquidité.

Leçons pour l’industrie

De mon point de vue, cet incident met en lumière plusieurs problématiques concrètes dans l’écosystème DeFi :

Premièrement, la latence dans la réalisation des audits de sécurité. Beaucoup de protocoles sont audités avant leur lancement, mais les hackers parviennent souvent à repérer des angles non couverts. La vulnérabilité de réentrée, bien qu’elle ne soit pas nouvelle, reste une arme couramment utilisée par les attaquants.

Deuxièmement, la pression pour réparer rapidement. Lorsqu’une faille est découverte, l’équipe doit agir en un temps très court pour corriger, auditer et déployer la mise à jour, ce qui peut entraîner des erreurs.

Troisièmement, la responsabilité de la diligence des utilisateurs. Même un protocole audité peut comporter des risques, et il incombe à l’utilisateur de gérer ses propres fonds avec prudence.

Conclusion

Les attaques successives contre FutureSwap soulignent que la vulnérabilité de réentrée demeure une menace majeure pour les protocoles DeFi. Ce n’est pas seulement un problème spécifique à ce protocole, mais une problématique à laquelle toute l’écosystème doit rester vigilant. Pour les utilisateurs, il est nécessaire de réévaluer la sécurité de ce protocole et de réfléchir à continuer ou non à l’utiliser ; pour l’industrie, il faut instaurer des standards de sécurité plus stricts et des mécanismes de réponse aux urgences plus rapides. La suite dépendra de la capacité du protocole à effectuer une mise à jour de sécurité plus approfondie et de l’éventuelle nécessité de dédommager d’autres utilisateurs affectés.