Analyse de l'incident de vulnérabilité d'Euler Finance : l'attaque par prêts flash a entraîné des pertes de 197 millions de dollars
Le 13 mars 2023, le projet Euler Finance a subi un incident de sécurité majeur. Selon les données de surveillance en chaîne, en raison d'une vulnérabilité de vérification de liquidité dans la fonction donateToReserves de Etoken, le projet a été victime d'une attaque par prêts flash. L'attaquant a causé des pertes énormes s'élevant à 197 millions de dollars en effectuant plusieurs opérations avec différentes devises, impliquant 6 types de jetons. Actuellement, ces fonds restent dans le compte de l'attaquant.
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é deux contrats : un pour l'emprunt et un autre pour la liquidation.
L'attaquant a mis en garantie 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 emprunté 195,6 millions d'eDAI et 200 millions de dDAI.
L'attaquant utilise les 10 millions de DAI restants pour rembourser une partie de sa dette et détruire les dDAI correspondants, puis emprunte à nouveau 195,6 millions d'eDAI et 200 millions de dDAI.
Étapes clés : l'attaquant appelle la fonction donateToReserves, donant un montant égal à 10 fois le montant remboursé, soit 100 millions d'eDAI. Ensuite, l'attaquant déclenche la fonction de liquidation, obtenant 310 millions de dDAI et 250 millions d'eDAI.
Enfin, l'attaquant a extrait 38,9 millions de Dai, a remboursé 30 millions de Prêts Flash, et a finalement réalisé un profit d'environ 8,87 millions de Dai.
Analyse des causes des vulnérabilités
Le problème central de cette attaque réside dans la fonction donateToReserves. Par rapport à d'autres fonctions clés (comme la fonction mint), la fonction donateToReserves manque une étape cruciale : checkLiquidity.
La fonction checkLiquidity a pour rôle d'appeler le module RiskManager pour vérifier l'utilisateur, en s'assurant que l'Etoken est supérieur au Dtoken, garantissant ainsi la situation de liquidité de l'utilisateur. Normalement, chaque opération nécessite cette vérification. Cependant, la fonction donateToReserves manque cette étape, permettant à un attaquant de se placer d'abord dans un état pouvant être liquidé, puis de réaliser l'opération de liquidation.
Conseils de sécurité
Concernant ce type de vulnérabilités, nous conseillons aux équipes de projet de procéder à un audit de sécurité complet avant le lancement afin d'assurer la sécurité du contrat. Pour les projets de prêt, il est particulièrement important de prêter attention aux aspects suivants :
L'intégrité du mécanisme de remboursement des fonds
L'exhaustivité de la détection de la liquidité
La sécurité du processus de liquidation de la dette
Il est essentiel de réduire au maximum la probabilité d'occurrence d'événements de sécurité similaires en passant par des audits de sécurité rigoureux et une évaluation complète des risques, afin de garantir la sécurité des fonds des projets et des utilisateurs.
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.
17 J'aime
Récompense
17
3
Partager
Commentaire
0/400
AirdropChaser
· 08-05 08:04
Encore prendre les gens pour des idiots, être pris pour un idiot tous les jours.
Voir l'originalRépondre0
DefiSecurityGuard
· 08-05 08:04
*sigh* encore un jour, un autre protocole rekt par la vulnérabilité de donateToReserves de base... j'en ai parlé il y a des mois, pour être honnête. rappel critique : TOUJOURS sanitiser les vérifications de liquidité ffs. ces erreurs d'amateur continuent de coûter 9 chiffres smh
Voir l'originalRépondre0
GasGrillMaster
· 08-05 07:50
Frère, cette défense de base n'est même pas à la hauteur, c'est vraiment nul.
Euler Finance a été victime d'une attaque par Prêts Flash de 197 millions de dollars, la vulnérabilité de la fonction donateToReserves étant la cause.
Analyse de l'incident de vulnérabilité d'Euler Finance : l'attaque par prêts flash a entraîné des pertes de 197 millions de dollars
Le 13 mars 2023, le projet Euler Finance a subi un incident de sécurité majeur. Selon les données de surveillance en chaîne, en raison d'une vulnérabilité de vérification de liquidité dans la fonction donateToReserves de Etoken, le projet a été victime d'une attaque par prêts flash. L'attaquant a causé des pertes énormes s'élevant à 197 millions de dollars en effectuant plusieurs opérations avec différentes devises, impliquant 6 types de jetons. Actuellement, ces fonds restent dans le compte de l'attaquant.
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é deux contrats : un pour l'emprunt et un autre pour la liquidation.
L'attaquant a mis en garantie 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 emprunté 195,6 millions d'eDAI et 200 millions de dDAI.
L'attaquant utilise les 10 millions de DAI restants pour rembourser une partie de sa dette et détruire les dDAI correspondants, puis emprunte à nouveau 195,6 millions d'eDAI et 200 millions de dDAI.
Étapes clés : l'attaquant appelle la fonction donateToReserves, donant un montant égal à 10 fois le montant remboursé, soit 100 millions d'eDAI. Ensuite, l'attaquant déclenche la fonction de liquidation, obtenant 310 millions de dDAI et 250 millions d'eDAI.
Enfin, l'attaquant a extrait 38,9 millions de Dai, a remboursé 30 millions de Prêts Flash, et a finalement réalisé un profit d'environ 8,87 millions de Dai.
Analyse des causes des vulnérabilités
Le problème central de cette attaque réside dans la fonction donateToReserves. Par rapport à d'autres fonctions clés (comme la fonction mint), la fonction donateToReserves manque une étape cruciale : checkLiquidity.
La fonction checkLiquidity a pour rôle d'appeler le module RiskManager pour vérifier l'utilisateur, en s'assurant que l'Etoken est supérieur au Dtoken, garantissant ainsi la situation de liquidité de l'utilisateur. Normalement, chaque opération nécessite cette vérification. Cependant, la fonction donateToReserves manque cette étape, permettant à un attaquant de se placer d'abord dans un état pouvant être liquidé, puis de réaliser l'opération de liquidation.
Conseils de sécurité
Concernant ce type de vulnérabilités, nous conseillons aux équipes de projet de procéder à un audit de sécurité complet avant le lancement afin d'assurer la sécurité du contrat. Pour les projets de prêt, il est particulièrement important de prêter attention aux aspects suivants :
Il est essentiel de réduire au maximum la probabilité d'occurrence d'événements de sécurité similaires en passant par des audits de sécurité rigoureux et une évaluation complète des risques, afin de garantir la sécurité des fonds des projets et des utilisateurs.