Euler Finance a subi une attaque de prêts flash, avec des pertes proches de 200 millions de dollars.
Le 13 mars 2023, le projet Euler Finance a subi une attaque de Prêts Flash à grande échelle en raison d'une vulnérabilité dans la fonction donateToReserves de son contrat Etoken. L'attaquant a effectué plusieurs opérations en utilisant divers tokens, entraînant finalement une perte énorme d'environ 197 millions de dollars.
Analyse du processus d'attaque
L'attaquant a d'abord obtenu un Prêt Flash de 30 millions de DAI depuis une plateforme de prêt, puis a déployé deux contrats clés : un pour les opérations de prêt et l'autre pour la liquidation. Le processus d'attaque peut être divisé en plusieurs étapes :
Pledger 20 millions DAI dans le contrat du protocole Euler pour obtenir environ 19,5 millions eDAI.
Utilisez la fonctionnalité de levier de 10x du protocole Euler pour emprunter 195,6 millions d'eDAI et 200 millions de dDAI.
Utiliser les 10 millions de DAI restants pour rembourser une partie de la dette et détruire la quantité correspondante de dDAI, puis emprunter à nouveau une quantité équivalente d'eDAI et de dDAI.
En faisant un don de 100 millions d'eDAI par la fonction donateToReserves, puis en appelant la fonction liquidate pour procéder à la liquidation, on obtient 310 millions de dDAI et 250 millions d'eDAI.
Enfin, extraction de 38,9 millions de DAI, après remboursement des Prêts Flash, bénéfice net d'environ 8,87 millions de DAI.
Analyse des causes de la vulnérabilité
Le problème central de cette attaque réside dans le fait que la fonction donateToReserves 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 aux utilisateurs de contourner le mécanisme normal de vérification de la liquidité.
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, comme la fonction donateToReserves a omis cette étape, l'attaquant a pu d'abord se placer dans un état pouvant être liquidé, puis effectuer l'opération de liquidation.
Conseils de sécurité
À l'intention de ce type de vulnérabilité, nous recommandons aux projets DeFi :
Effectuer un audit de sécurité complet avant le lancement du contrat pour garantir la sécurité du contrat.
Accordez une attention particulière aux étapes clés telles que le remboursement des fonds, la détection de la liquidité et la liquidation des dettes dans les projets de prêt.
Mettre en œuvre des contrôles de liquidité stricts pour toutes les fonctions susceptibles d'affecter l'état des actifs des utilisateurs.
Effectuer régulièrement des revues de code et corriger rapidement les vulnérabilités potentielles.
Envisagez d'introduire des mesures de sécurité supplémentaires telles que des mécanismes de multi-signature ou des verrous temporels.
Cet événement souligne à nouveau l'importance de la sécurité des contrats intelligents. Les équipes de projet doivent toujours placer la sécurité en première position, en protégeant les actifs des utilisateurs et en favorisant le développement sain de l'écosystème du projet grâce à des pratiques de sécurité en constante amélioration.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
22 J'aime
Récompense
22
6
Partager
Commentaire
0/400
MevTears
· 07-07 18:24
Est-ce que le defi est agréable quand on compte l'argent en étant allongé ?
Voir l'originalRépondre0
rekt_but_vibing
· 07-06 05:25
Encore un projet Rug Pull.
Voir l'originalRépondre0
P2ENotWorking
· 07-06 05:23
C'est encore explosé, pas surprenant.
Voir l'originalRépondre0
token_therapist
· 07-06 05:14
Encore une fête pour se faire prendre pour des cons
Voir l'originalRépondre0
CryptoMom
· 07-06 05:10
l'univers de la cryptomonnaie pigeons encore pris pour des idiots
Euler Finance a subi une attaque de 200 millions de dollars par des Prêts Flash, la sécurité de la Finance décentralisée sonne à nouveau l'alarme.
Euler Finance a subi une attaque de prêts flash, avec des pertes proches de 200 millions de dollars.
Le 13 mars 2023, le projet Euler Finance a subi une attaque de Prêts Flash à grande échelle en raison d'une vulnérabilité dans la fonction donateToReserves de son contrat Etoken. L'attaquant a effectué plusieurs opérations en utilisant divers tokens, entraînant finalement une perte énorme d'environ 197 millions de dollars.
Analyse du processus d'attaque
L'attaquant a d'abord obtenu un Prêt Flash de 30 millions de DAI depuis une plateforme de prêt, puis a déployé deux contrats clés : un pour les opérations de prêt et l'autre pour la liquidation. Le processus d'attaque peut être divisé en plusieurs étapes :
Pledger 20 millions DAI dans le contrat du protocole Euler pour obtenir environ 19,5 millions eDAI.
Utilisez la fonctionnalité de levier de 10x du protocole Euler pour emprunter 195,6 millions d'eDAI et 200 millions de dDAI.
Utiliser les 10 millions de DAI restants pour rembourser une partie de la dette et détruire la quantité correspondante de dDAI, puis emprunter à nouveau une quantité équivalente d'eDAI et de dDAI.
En faisant un don de 100 millions d'eDAI par la fonction donateToReserves, puis en appelant la fonction liquidate pour procéder à la liquidation, on obtient 310 millions de dDAI et 250 millions d'eDAI.
Enfin, extraction de 38,9 millions de DAI, après remboursement des Prêts Flash, bénéfice net d'environ 8,87 millions de DAI.
Analyse des causes de la vulnérabilité
Le problème central de cette attaque réside dans le fait que la fonction donateToReserves 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 aux utilisateurs de contourner le mécanisme normal de vérification de la liquidité.
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, comme la fonction donateToReserves a omis cette étape, l'attaquant a pu d'abord se placer dans un état pouvant être liquidé, puis effectuer l'opération de liquidation.
Conseils de sécurité
À l'intention de ce type de vulnérabilité, nous recommandons aux projets DeFi :
Effectuer un audit de sécurité complet avant le lancement du contrat pour garantir la sécurité du contrat.
Accordez une attention particulière aux étapes clés telles que le remboursement des fonds, la détection de la liquidité et la liquidation des dettes dans les projets de prêt.
Mettre en œuvre des contrôles de liquidité stricts pour toutes les fonctions susceptibles d'affecter l'état des actifs des utilisateurs.
Effectuer régulièrement des revues de code et corriger rapidement les vulnérabilités potentielles.
Envisagez d'introduire des mesures de sécurité supplémentaires telles que des mécanismes de multi-signature ou des verrous temporels.
Cet événement souligne à nouveau l'importance de la sécurité des contrats intelligents. Les équipes de projet doivent toujours placer la sécurité en première position, en protégeant les actifs des utilisateurs et en favorisant le développement sain de l'écosystème du projet grâce à des pratiques de sécurité en constante amélioration.