Euler Finance a subi une attaque par prêts flash, avec des pertes de près de 200 millions de dollars.
Le 13 mars, le projet Euler Finance a subi une attaque par prêts flash en raison d'une vulnérabilité dans son contrat intelligent, entraînant une perte massive d'environ 197 millions de dollars. Cette attaque impliquait 6 types de jetons cryptographiques différents.
Analyse du processus d'attaque
L'attaquant a d'abord obtenu un Prêt Flash de 30 millions de DAI d'une plateforme de prêt et a déployé deux contrats clés : un pour les opérations de prêt et un autre pour la liquidation.
Ensuite, l'attaquant a mis en jeu 20 millions de DAI dans le contrat du protocole Euler, obtenant environ 19,5 millions d'eDAI. En utilisant la fonctionnalité de levier de 10x du protocole Euler, l'attaquant a ensuite emprunté 195,6 millions d'eDAI et 20 millions de dDAI.
Ensuite, l'attaquant utilise les 10 millions de DAI restants pour rembourser une partie de la dette, détruisant ainsi la quantité correspondante de dDAI. Il emprunte à nouveau la même quantité d'eDAI et de dDAI.
Une étape clé est que l'attaquant a exploité la vulnérabilité de la fonction donateToReserves pour faire un don d'un montant dix fois supérieur au montant remboursé, soit 100 millions d'eDAI. Cette opération a permis à l'attaquant de déclencher le mécanisme de liquidation et d'obtenir 310 millions de dDAI et 250 millions d'eDAI.
Enfin, l'attaquant a obtenu 38,9 millions de DAI grâce à la fonction de retrait, a remboursé 30 millions de DAI de Prêts Flash, et a finalement réalisé un profit d'environ 8,87 millions de DAI.
Analyse des causes de la vulnérabilité
La vulnérabilité centrale de cette attaque réside dans le fait que la fonction donateToReserves d'Euler Finance manque de vérifications de liquidité nécessaires. Contrairement à d'autres fonctions clés (comme la fonction mint), la fonction donateToReserves n'appelle pas checkLiquidity pour valider la liquidité de l'utilisateur.
Dans des conditions normales, la fonction checkLiquidity s'assure, en appelant le module RiskManager, que le nombre d'eTokens de l'utilisateur est supérieur au nombre de dTokens, afin de maintenir la sécurité du système. Cependant, en raison de l'absence de cette étape clé dans la fonction donateToReserves, un attaquant a pu manipuler l'état de son compte pour répondre aux conditions de liquidation, puis exécuter la liquidation pour en tirer profit.
Conseils de sécurité
Pour ce type d'attaque, nous recommandons aux projets blockchain :
Effectuer un audit de sécurité complet avant le lancement du contrat intelligent, en portant une attention particulière aux étapes clés telles que l'emprunt de fonds, la gestion de la liquidité et le règlement des dettes.
Mettre en œuvre des contrôles de sécurité stricts pour toutes les fonctions susceptibles d'affecter l'état des actifs des utilisateurs, y compris mais sans s'y limiter à la vérification de la liquidité.
Effectuer régulièrement des audits de code et des scans de vulnérabilités, et corriger rapidement les failles de sécurité potentielles.
Établir un mécanisme de gestion des risques complet, en fixant des limites de prêt raisonnables et des seuils de liquidation.
Envisagez d'introduire des mesures de sécurité supplémentaires telles que des signatures multiples ou des verrous temporels pour éviter la perte massive de fonds.
En prenant ces mesures préventives, la sécurité des projets DeFi peut être considérablement améliorée, réduisant ainsi le risque de subir des attaques similaires.
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.
16 J'aime
Récompense
16
7
Reposter
Partager
Commentaire
0/400
ServantOfSatoshi
· 07-19 18:22
Encore un accident, c'est vraiment ennuyeux.
Voir l'originalRépondre0
MercilessHalal
· 07-19 08:53
Revoir la zone d'ombre des contrats
Voir l'originalRépondre0
DYORMaster
· 07-17 03:24
Encore une fois, le contrat est tombé dans un piège.
Euler Finance a subi une attaque de Prêts Flash de 200 millions de dollars, une vulnérabilité de smart contracts en est la cause.
Euler Finance a subi une attaque par prêts flash, avec des pertes de près de 200 millions de dollars.
Le 13 mars, le projet Euler Finance a subi une attaque par prêts flash en raison d'une vulnérabilité dans son contrat intelligent, entraînant une perte massive d'environ 197 millions de dollars. Cette attaque impliquait 6 types de jetons cryptographiques différents.
Analyse du processus d'attaque
L'attaquant a d'abord obtenu un Prêt Flash de 30 millions de DAI d'une plateforme de prêt et a déployé deux contrats clés : un pour les opérations de prêt et un autre pour la liquidation.
Ensuite, l'attaquant a mis en jeu 20 millions de DAI dans le contrat du protocole Euler, obtenant environ 19,5 millions d'eDAI. En utilisant la fonctionnalité de levier de 10x du protocole Euler, l'attaquant a ensuite emprunté 195,6 millions d'eDAI et 20 millions de dDAI.
Ensuite, l'attaquant utilise les 10 millions de DAI restants pour rembourser une partie de la dette, détruisant ainsi la quantité correspondante de dDAI. Il emprunte à nouveau la même quantité d'eDAI et de dDAI.
Une étape clé est que l'attaquant a exploité la vulnérabilité de la fonction donateToReserves pour faire un don d'un montant dix fois supérieur au montant remboursé, soit 100 millions d'eDAI. Cette opération a permis à l'attaquant de déclencher le mécanisme de liquidation et d'obtenir 310 millions de dDAI et 250 millions d'eDAI.
Enfin, l'attaquant a obtenu 38,9 millions de DAI grâce à la fonction de retrait, a remboursé 30 millions de DAI de Prêts Flash, et a finalement réalisé un profit d'environ 8,87 millions de DAI.
Analyse des causes de la vulnérabilité
La vulnérabilité centrale de cette attaque réside dans le fait que la fonction donateToReserves d'Euler Finance manque de vérifications de liquidité nécessaires. Contrairement à d'autres fonctions clés (comme la fonction mint), la fonction donateToReserves n'appelle pas checkLiquidity pour valider la liquidité de l'utilisateur.
Dans des conditions normales, la fonction checkLiquidity s'assure, en appelant le module RiskManager, que le nombre d'eTokens de l'utilisateur est supérieur au nombre de dTokens, afin de maintenir la sécurité du système. Cependant, en raison de l'absence de cette étape clé dans la fonction donateToReserves, un attaquant a pu manipuler l'état de son compte pour répondre aux conditions de liquidation, puis exécuter la liquidation pour en tirer profit.
Conseils de sécurité
Pour ce type d'attaque, nous recommandons aux projets blockchain :
Effectuer un audit de sécurité complet avant le lancement du contrat intelligent, en portant une attention particulière aux étapes clés telles que l'emprunt de fonds, la gestion de la liquidité et le règlement des dettes.
Mettre en œuvre des contrôles de sécurité stricts pour toutes les fonctions susceptibles d'affecter l'état des actifs des utilisateurs, y compris mais sans s'y limiter à la vérification de la liquidité.
Effectuer régulièrement des audits de code et des scans de vulnérabilités, et corriger rapidement les failles de sécurité potentielles.
Établir un mécanisme de gestion des risques complet, en fixant des limites de prêt raisonnables et des seuils de liquidation.
Envisagez d'introduire des mesures de sécurité supplémentaires telles que des signatures multiples ou des verrous temporels pour éviter la perte massive de fonds.
En prenant ces mesures préventives, la sécurité des projets DeFi peut être considérablement améliorée, réduisant ainsi le risque de subir des attaques similaires.