Euler Finance a subi une attaque de prêt flash, avec des pertes s'élevant à 197 millions de dollars.

Le 13 mars 2023, le projet Euler Finance a subi une attaque par Prêts Flash en raison d'une vulnérabilité dans le contrat, entraînant d'énormes pertes. L'attaquant a exploité une faille dans la fonction donateToReserves du contrat, qui manquait de vérification de liquidité, pour obtenir d'importants fonds par plusieurs opérations. Cet incident a impliqué 6 types de jetons, avec une perte totale atteignant 197 millions de dollars.

Analyse du processus d'attaque

1. L'attaquant a d'abord emprunté 30 millions de DAI via un Prêt Flash sur une plateforme de prêt, et a déployé deux contrats : un contrat de prêt et un contrat de liquidation.

2. L'attaquant a staké 20 millions de DAI dans le contrat du protocole Euler, obtenant 195 000 eDAI.

3. En utilisant la fonction de levier de 10x du protocole Euler, l'attaquant a emprunté 1,956 millions d'eDAI et 2 millions de dDAI.

4. L'attaquant utilise les 10 millions de DAI restants pour rembourser une partie de la dette et détruit le dDAI correspondant, puis emprunte à nouveau 1,956,000 eDAI et 2,000,000 dDAI.

5. Étapes clés : l'attaquant appelle la fonction donateToReserves et fait un don de 1 million d'eDAI (ce qui représente 10 fois le montant remboursé). Ensuite, l'attaquant appelle la fonction liquidate pour procéder à la liquidation, obtenant 3,1 millions de dDAI et 2,5 millions d'eDAI.

6. Enfin, l'attaquant a extrait 389 000 DAI et a remboursé le prêt flash de 30 millions DAI, réalisant finalement un bénéfice de 8,87 millions DAI.

Analyse des causes des vulnérabilités

Le problème central de cette attaque réside dans le fait que la fonction donateToReserves du contrat Euler Finance manque de vérifications de liquidité nécessaires. Contrairement à la fonction mint, la fonction donateToReserves n'exécute pas l'étape checkLiquidity, ce qui permet à l'attaquant de contourner les vérifications de liquidité normales.

Dans des conditions normales, la fonction checkLiquidity appelle le module RiskManager pour s'assurer que le nombre d'eTokens de l'utilisateur est supérieur au nombre de dTokens. Cependant, en raison de l'absence de cette étape clé dans la fonction donateToReserves, l'attaquant a pu exploiter cette faille, se plaçant d'abord dans un état pouvant être liquidé, puis réalisant l'opération de liquidation.

Conseils de sécurité

Pour ce type d'attaque, nous recommandons aux projets DeFi :

1. Effectuer un audit de sécurité complet avant le lancement du contrat pour garantir la sécurité du contrat.

2. Pour les projets de prêt, il est particulièrement important de prêter attention aux étapes clés telles que le remboursement des fonds, la détection de la liquidité et le règlement de la dette.

3. Des contrôles de liquidité stricts doivent être mis en œuvre dans chaque fonction susceptible d'affecter l'état des fonds des utilisateurs.

4. Effectuer des examens et des mises à jour de code réguliers, en réparant rapidement les vulnérabilités découvertes.

5. Envisagez d'introduire des mécanismes de signature multiple ou des mesures de sécurité supplémentaires telles que le verrouillage temporel.

Cet incident nous rappelle une fois de plus que, dans le domaine en pleine expansion de la DeFi, la sécurité des contrats est toujours cruciale. Les équipes de projet doivent constamment renforcer leur sensibilisation à la sécurité et adopter des mesures de protection multiples pour protéger la sécurité des actifs des utilisateurs.