Analyse de l'attaque par réinjection de Prêts Flash sur le projet Jarvis Network
Le 15 janvier 2023, le projet Jarvis_Network a été attaqué sur le réseau Polygon, entraînant une perte d'environ 663 000 MATIC. L'analyse montre que les attaquants ont exploité des Prêts Flash et une vulnérabilité de réentrance pour mener l'attaque.
L'analyse de la pile d'appels de transaction d'attaque montre que lors du réentré, l'appel de la même fonction du même contrat avec les mêmes paramètres d'entrée renvoie des valeurs de retour très différentes. Les valeurs de retour avant et après réentré sont respectivement :
Avant la réinjection : 1002157321772769944
Réentré : 10091002696492234934
La réinsertion se produit dans la fonction remove_liquidity. Cette fonction renvoie les jetons ajoutés par l'utilisateur lors de la suppression de la liquidité. Étant donné que Polygon est compatible avec EVM, cela a déclenché une réinsertion lors du transfert de MATIC au contrat.
Une analyse approfondie révèle que le problème réside dans l'implémentation de la fonction getUnderlyingPrice. Cette fonction implique une série de calculs internes et d'appels externes, dont la clé est la valeur de retour de la fonction get_virtual_price. Cette valeur de retour est influencée par la variable self.D, dont la mise à jour se produit après le transfert de jetons.
Lors de la suppression de la liquidité, après que MATIC a été transféré au contrat d'attaque, l'attaquant a d'abord interrogé le prix du jeton via un rappel. Comme self.D n'avait pas encore été mis à jour, cela a entraîné une erreur dans l'obtention du prix. L'attaquant a profité de ce décalage temporel pour multiplier par environ 10 le prix de l'emprunt lors de la réentrée.
Bien que la fonction remove_liquidity utilise le décorateur @nonreentrant('lock') pour prévenir les réentrées, l'attaquant a contourné ce mécanisme de protection par une réentrée inter-contrats.
Cette attaque a révélé plusieurs problèmes clés :
La logique de modification des variables est située après l'appel externe, ce qui entraîne une anomalie dans l'obtention des prix.
Le réentré inter-contrats rend le verrou de réentré inopérant.
Ne pas suivre le modèle "Vérifications-Effects-Interactions" (Checks-Effects-Interactions).
Pour prévenir des attaques similaires, nous recommandons aux équipes de projet :
Effectuer un audit de sécurité rigoureux
Déplacer la modification des variables avant l'appel externe
Utiliser une méthode multi-sources pour obtenir le prix
Suivre la norme de codage "Vérifier-Effectuer-Interact"
Grâce à ces mesures, la sécurité et la stabilité du projet peuvent être considérablement améliorées.
Voir l'original
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.
Le réseau Jarvis a subi une attaque de réentrance par Prêts Flash, avec une perte de 663 000 MATIC.
Analyse de l'attaque par réinjection de Prêts Flash sur le projet Jarvis Network
Le 15 janvier 2023, le projet Jarvis_Network a été attaqué sur le réseau Polygon, entraînant une perte d'environ 663 000 MATIC. L'analyse montre que les attaquants ont exploité des Prêts Flash et une vulnérabilité de réentrance pour mener l'attaque.
L'analyse de la pile d'appels de transaction d'attaque montre que lors du réentré, l'appel de la même fonction du même contrat avec les mêmes paramètres d'entrée renvoie des valeurs de retour très différentes. Les valeurs de retour avant et après réentré sont respectivement :
La réinsertion se produit dans la fonction remove_liquidity. Cette fonction renvoie les jetons ajoutés par l'utilisateur lors de la suppression de la liquidité. Étant donné que Polygon est compatible avec EVM, cela a déclenché une réinsertion lors du transfert de MATIC au contrat.
Une analyse approfondie révèle que le problème réside dans l'implémentation de la fonction getUnderlyingPrice. Cette fonction implique une série de calculs internes et d'appels externes, dont la clé est la valeur de retour de la fonction get_virtual_price. Cette valeur de retour est influencée par la variable self.D, dont la mise à jour se produit après le transfert de jetons.
Lors de la suppression de la liquidité, après que MATIC a été transféré au contrat d'attaque, l'attaquant a d'abord interrogé le prix du jeton via un rappel. Comme self.D n'avait pas encore été mis à jour, cela a entraîné une erreur dans l'obtention du prix. L'attaquant a profité de ce décalage temporel pour multiplier par environ 10 le prix de l'emprunt lors de la réentrée.
Bien que la fonction remove_liquidity utilise le décorateur @nonreentrant('lock') pour prévenir les réentrées, l'attaquant a contourné ce mécanisme de protection par une réentrée inter-contrats.
Cette attaque a révélé plusieurs problèmes clés :
Pour prévenir des attaques similaires, nous recommandons aux équipes de projet :
Grâce à ces mesures, la sécurité et la stabilité du projet peuvent être considérablement améliorées.