Analyse de l'attaque par réentrance des Prêts Flash sur le projet Jarvis Network

Les données montrent qu'au 15 janvier 2023 à 17:43:37 UTC, le projet Jarvis_Network a été attaqué, entraînant une perte de 663 101 MATIC.

En analysant la pile d'appels de transaction, il a été constaté qu'il existe une logique de réentrance lors du processus de retrait de liquidité. Avant et après la réentrance, l'appel de la même fonction sur le même contrat avec les mêmes paramètres entraîne des valeurs de retour très différentes :

• Avant la réinsertion : 1,002,157,321,772,769,944
• Réentré : 10,091,002,696,492,234,934

La réinjection se produit dans la fonction remove_liquidity. Cette fonction renvoie les tokens ajoutés par l'utilisateur lors de la suppression de la liquidité. Étant donné que Polygon et EVM sont des chaînes isomorphes, le transfert de MATIC au contrat déclenchera la réinjection du contrat.

Une analyse approfondie a révélé que le problème résidait 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.

La valeur de retour de la fonction get_virtual_price est influencée par la variable self.D. Dans la fonction remove_liquidity, la mise à jour de self.D se produit après le transfert de jetons. Lors de la suppression de la liquidité, MATIC est transféré au contrat d'attaque, et lors de l'appel de fallback, le prix du jeton est d'abord interrogé. Comme self.D n'a pas encore été mis à jour, cela entraîne une erreur dans l'obtention du prix.

Processus de la fonction remove_liquidity :

1. Détruire le LP de l'utilisateur
2. Envoyer les fonds de mise en jeu des utilisateurs
3. Mettre à jour self.D

L'attaquant a effectué une réinjection à l'étape 2, utilisant une valeur self.D non mise à jour pour emprunter et obtenir des fonds équivalents à 10 fois le prix normal.

Bien que la fonction remove_liquidity utilise @nonreentrant('lock') pour empêcher les réentrées, l'attaquant a contourné ce mécanisme de protection par des réentrées inter-contrats.

Cette attaque a révélé plusieurs problèmes clés :

1. La logique de modification des variables après l'appel externe a entraîné une anomalie dans l'obtention des prix.
2. La réentrance inter-contrat rend le verrou de réentrance inefficace
3. Ne pas suivre le modèle "Vérifications-Effectifs-Interactions" (Checks-Effects-Interactions)

Pour améliorer la sécurité, l'équipe du projet doit :

• Effectuer un audit de sécurité rigoureux
• Placez la modification de la variable avant l'appel externe.
• Utiliser plusieurs sources de données pour obtenir les prix
• Suivre la norme de codage "d'abord juger, puis écrire dans la variable, puis effectuer l'appel externe".

Grâce à ces mesures, il est possible d'améliorer considérablement la sécurité et la stabilité du projet, tout en prévenant efficacement des attaques similaires.