Euler Finance a subi une perte de 197 millions de dollars en raison d'une attaque par prêts flash.
Le 13 mars, le projet Euler Finance a subi une attaque de prêt flash en raison d'une vulnérabilité dans son contrat intelligent, entraînant des pertes allant jusqu'à 197 millions de dollars. Cette attaque a impliqué 6 types de jetons et est l'un des plus grands événements d'attaque DeFi récents.
Analyse du processus d'attaque
L'attaquant a d'abord obtenu un prêt flash de 30 millions de DAI sur une plateforme de prêt, puis a déployé un contrat de prêt et un contrat de liquidation. Ensuite, il a mis en garantie 20 millions de DAI sur Euler Protocol pour obtenir 19,5 millions d'eDAI.
En utilisant un effet de levier de 10 fois sur le protocole Euler, l'attaquant a emprunté 195,6 millions d'eDAI et 200 millions de dDAI. Ensuite, il a remboursé une partie de la dette avec les 10 millions de DAI restants et détruit le dDAI correspondant, puis a de nouveau emprunté des quantités équivalentes d'eDAI et de dDAI.
L'étape clé consiste à appeler la fonction donateToReserves pour donner 100 millions d'eDAI, puis à liquider via la fonction liquidate pour obtenir 310 millions de dDAI et 250 millions d'eDAI. Enfin, retirez 38,9 millions de DAI, remboursez 30 millions de Prêts Flash, pour un bénéfice net d'environ 8,87 millions de DAI.
Analyse des causes de la vulnérabilité
La vulnérabilité existe dans la fonction donateToReserves d'Euler Finance. Contrairement à d'autres fonctions comme mint, donateToReserves manque d'une étape clé de vérification de la liquidité. Cela permet aux utilisateurs de contourner le contrôle de la liquidité, de créer artificiellement des conditions de liquidation et d'en tirer profit.
Dans des conditions normales, checkLiquidity appelle le module RiskManager pour vérifier si le eToken de l'utilisateur est supérieur au dToken, afin de garantir la santé du compte. L'absence de cette étape permet à l'attaquant de manipuler l'état de son compte, entraînant un remboursement inapproprié.
Conseils de sécurité
Pour ce type d'attaque, les projets DeFi devraient se concentrer sur les aspects suivants :
Effectuer un audit de sécurité complet avant le lancement du contrat, en accordant une attention particulière aux étapes clés telles que le remboursement des fonds, la détection de liquidités et le règlement des dettes.
Ajouter les vérifications de sécurité nécessaires dans toutes les fonctions susceptibles d'affecter l'état des actifs des utilisateurs.
Effectuer régulièrement des revues de code pour détecter et corriger rapidement les vulnérabilités potentielles.
Établir un mécanisme de gestion des risques efficace, définir des limites de prêt raisonnables et des seuils de liquidation.
Envisagez d'introduire des mécanismes tels que la signature multiple pour augmenter la difficulté des attaques.
Avec le développement continu de l'écosystème DeFi, les projets doivent accorder une plus grande attention à la sécurité des contrats intelligents et adopter des mesures de protection complètes pour réduire au maximum ce type de risque.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
19 J'aime
Récompense
19
8
Partager
Commentaire
0/400
rekt_but_not_broke
· 07-07 15:13
Les failles se faire prendre pour des cons ont atteint un nouveau sommet.
Voir l'originalRépondre0
Layer2Observer
· 07-07 04:02
Une autre ronde de fuite de contrat piège, le code ne trompe jamais.
Voir l'originalRépondre0
GasFeeWhisperer
· 07-06 16:17
Les smart contracts ne sont pas non plus intelligents.
Voir l'originalRépondre0
ForeverBuyingDips
· 07-06 16:16
prendre les gens pour des idiots prendre les gens pour des idiots prendre les gens pour des idiots, c'est de nouveau la saison des récoltes.
Voir l'originalRépondre0
ser_we_are_ngmi
· 07-06 16:16
Encore une fois, c'est le Prêts Flash qui m'a fait tomber.
Voir l'originalRépondre0
TradFiRefugee
· 07-06 16:12
Finance décentralisée une journée trois frayeurs
Voir l'originalRépondre0
TokenBeginner'sGuide
· 07-06 16:11
Petit rappel : l'importance de la sécurité des smart contracts a de nouveau été vérifiée. Les données montrent que 85 % des projets n'ont pas effectué d'audit complet avant leur lancement.
Euler Finance a subi une attaque par Prêts Flash de 197 millions de dollars, la sécurité de la Finance décentralisée sonne à nouveau l'alarme.
Euler Finance a subi une perte de 197 millions de dollars en raison d'une attaque par prêts flash.
Le 13 mars, le projet Euler Finance a subi une attaque de prêt flash en raison d'une vulnérabilité dans son contrat intelligent, entraînant des pertes allant jusqu'à 197 millions de dollars. Cette attaque a impliqué 6 types de jetons et est l'un des plus grands événements d'attaque DeFi récents.
Analyse du processus d'attaque
L'attaquant a d'abord obtenu un prêt flash de 30 millions de DAI sur une plateforme de prêt, puis a déployé un contrat de prêt et un contrat de liquidation. Ensuite, il a mis en garantie 20 millions de DAI sur Euler Protocol pour obtenir 19,5 millions d'eDAI.
En utilisant un effet de levier de 10 fois sur le protocole Euler, l'attaquant a emprunté 195,6 millions d'eDAI et 200 millions de dDAI. Ensuite, il a remboursé une partie de la dette avec les 10 millions de DAI restants et détruit le dDAI correspondant, puis a de nouveau emprunté des quantités équivalentes d'eDAI et de dDAI.
L'étape clé consiste à appeler la fonction donateToReserves pour donner 100 millions d'eDAI, puis à liquider via la fonction liquidate pour obtenir 310 millions de dDAI et 250 millions d'eDAI. Enfin, retirez 38,9 millions de DAI, remboursez 30 millions de Prêts Flash, pour un bénéfice net d'environ 8,87 millions de DAI.
Analyse des causes de la vulnérabilité
La vulnérabilité existe dans la fonction donateToReserves d'Euler Finance. Contrairement à d'autres fonctions comme mint, donateToReserves manque d'une étape clé de vérification de la liquidité. Cela permet aux utilisateurs de contourner le contrôle de la liquidité, de créer artificiellement des conditions de liquidation et d'en tirer profit.
Dans des conditions normales, checkLiquidity appelle le module RiskManager pour vérifier si le eToken de l'utilisateur est supérieur au dToken, afin de garantir la santé du compte. L'absence de cette étape permet à l'attaquant de manipuler l'état de son compte, entraînant un remboursement inapproprié.
Conseils de sécurité
Pour ce type d'attaque, les projets DeFi devraient se concentrer sur les aspects suivants :
Effectuer un audit de sécurité complet avant le lancement du contrat, en accordant une attention particulière aux étapes clés telles que le remboursement des fonds, la détection de liquidités et le règlement des dettes.
Ajouter les vérifications de sécurité nécessaires dans toutes les fonctions susceptibles d'affecter l'état des actifs des utilisateurs.
Effectuer régulièrement des revues de code pour détecter et corriger rapidement les vulnérabilités potentielles.
Établir un mécanisme de gestion des risques efficace, définir des limites de prêt raisonnables et des seuils de liquidation.
Envisagez d'introduire des mécanismes tels que la signature multiple pour augmenter la difficulté des attaques.
Avec le développement continu de l'écosystème DeFi, les projets doivent accorder une plus grande attention à la sécurité des contrats intelligents et adopter des mesures de protection complètes pour réduire au maximum ce type de risque.