Analyse de l'attaque par réinjection de Prêts Flash sur le réseau Jarvis
Le 15 janvier 2023, le projet Jarvis_Network a été victime d'une attaque de hackers, entraînant une perte de 663101 MATIC. Grâce à l'analyse des données de transaction, il a été découvert que cette attaque impliquait des Prêts Flash et une vulnérabilité de réentrance.
L'attaquant a exploité une vulnérabilité dans la fonction remove_liquidity. Lors de la suppression de la liquidité, cette fonction retourne les jetons ajoutés par l'utilisateur. Étant donné que Polygon et EVM sont des chaînes isomorphes, le transfert de MATIC au contrat déclenche la logique de réentrance du contrat.
Il est essentiel de se concentrer sur le processus d'appel de la fonction getUnderlyingPrice. Cette fonction implique l'interaction de plusieurs contrats, dont certains ne sont pas open source. L'analyse a révélé que le problème réside dans la valeur de retour de la fonction get_virtual_price. Cette valeur de retour présente des différences significatives avant et après la réentrante.
Plus précisément, la mise à jour de la variable self.D se produit après le transfert de jetons. Lorsque l'attaquant retire la liquidité, le MATIC est transféré vers le contrat de l'attaquant. Lors de l'appel de la fonction fallback, l'attaquant interroge d'abord le prix d'un certain jeton. En raison du décalage de la mise à jour de self.D par rapport au transfert, cela entraîne une erreur dans l'obtention du prix précédent.
Le processus de retrait de liquidité comprend : 1) la destruction des jetons LP de l'utilisateur ; 2) l'envoi de fonds de mise en jeu à l'utilisateur ; 3) la mise à jour de self.D. self.D est utilisé pour le calcul des prix et est mis à jour lors de l'ajout et du retrait de liquidité. Un attaquant a exploité une vulnérabilité liée à la liquidité importante et au timing de la mise à jour de self.D, procédant à une réentrée à l'étape 2 et empruntant à un prix 10 fois supérieur au prix d'origine.
Bien que la fonction remove_liquidity utilise le décorateur @nonreentrant('lock') pour prévenir les réentrées, un attaquant a contourné ce mécanisme de protection par le biais de prêts inter-contrats.
Cette attaque a révélé des lacunes dans la logique de modification des variables et la sécurité des appels inter-contrats du projet. Pour prévenir des attaques similaires, il est conseillé aux équipes de projet de prendre les mesures suivantes :
Effectuer un audit de sécurité rigoureux.
Placez la modification des variables avant l'appel externe.
Utiliser une méthode à plusieurs sources de données pour obtenir le prix.
Suivre les normes de codage "Vérifications-Effects-Interactions" (Checks-Effects-Interactions).
Grâce à ces mesures, la sécurité et la stabilité du projet peuvent être considérablement améliorées, empêchant ainsi la récurrence d'événements d'attaque similaires.
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.
22 J'aime
Récompense
22
6
Partager
Commentaire
0/400
NFTHoarder
· Il y a 9h
Le test de ce projet est vraiment trop facile, il a été facilement compromis.
Voir l'originalRépondre0
RektDetective
· 07-19 06:12
Encore quelqu'un a eu un problème, pas de vérification des transferts matic, un débutant écrit du code ?
Voir l'originalRépondre0
DuskSurfer
· 07-18 23:29
Tu es encore allongé à copier le contrat, tu n'as même pas compris la réentrance~
Voir l'originalRépondre0
StableGenius
· 07-18 23:29
lmao un autre jour, un autre hack... comme prévu, pour être honnête
Voir l'originalRépondre0
HypotheticalLiquidator
· 07-18 23:18
Le vieux problème est revenu. Tu ne vas pas mettre un verrou de réentrance ?
Voir l'originalRépondre0
failed_dev_successful_ape
· 07-18 23:11
projet de fête dort pendant que d'autres essaient de forcer la serrure~
Le réseau Jarvis a subi une attaque de réinjection par prêts flash, entraînant une perte de 660 000 MATIC.
Analyse de l'attaque par réinjection de Prêts Flash sur le réseau Jarvis
Le 15 janvier 2023, le projet Jarvis_Network a été victime d'une attaque de hackers, entraînant une perte de 663101 MATIC. Grâce à l'analyse des données de transaction, il a été découvert que cette attaque impliquait des Prêts Flash et une vulnérabilité de réentrance.
L'attaquant a exploité une vulnérabilité dans la fonction remove_liquidity. Lors de la suppression de la liquidité, cette fonction retourne les jetons ajoutés par l'utilisateur. Étant donné que Polygon et EVM sont des chaînes isomorphes, le transfert de MATIC au contrat déclenche la logique de réentrance du contrat.
Il est essentiel de se concentrer sur le processus d'appel de la fonction getUnderlyingPrice. Cette fonction implique l'interaction de plusieurs contrats, dont certains ne sont pas open source. L'analyse a révélé que le problème réside dans la valeur de retour de la fonction get_virtual_price. Cette valeur de retour présente des différences significatives avant et après la réentrante.
Plus précisément, la mise à jour de la variable self.D se produit après le transfert de jetons. Lorsque l'attaquant retire la liquidité, le MATIC est transféré vers le contrat de l'attaquant. Lors de l'appel de la fonction fallback, l'attaquant interroge d'abord le prix d'un certain jeton. En raison du décalage de la mise à jour de self.D par rapport au transfert, cela entraîne une erreur dans l'obtention du prix précédent.
Le processus de retrait de liquidité comprend : 1) la destruction des jetons LP de l'utilisateur ; 2) l'envoi de fonds de mise en jeu à l'utilisateur ; 3) la mise à jour de self.D. self.D est utilisé pour le calcul des prix et est mis à jour lors de l'ajout et du retrait de liquidité. Un attaquant a exploité une vulnérabilité liée à la liquidité importante et au timing de la mise à jour de self.D, procédant à une réentrée à l'étape 2 et empruntant à un prix 10 fois supérieur au prix d'origine.
Bien que la fonction remove_liquidity utilise le décorateur @nonreentrant('lock') pour prévenir les réentrées, un attaquant a contourné ce mécanisme de protection par le biais de prêts inter-contrats.
Cette attaque a révélé des lacunes dans la logique de modification des variables et la sécurité des appels inter-contrats du projet. Pour prévenir des attaques similaires, il est conseillé aux équipes de projet de prendre les mesures suivantes :
Grâce à ces mesures, la sécurité et la stabilité du projet peuvent être considérablement améliorées, empêchant ainsi la récurrence d'événements d'attaque similaires.