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é, entraînant le vol de 663 101 MATIC. Cet incident a suscité des préoccupations concernant la sécurité du projet.

En analysant la pile d'appels de transactions, il a été découvert que l'attaquant a exploité une vulnérabilité de réentrance. Au cours du processus de réentrance, bien que les paramètres d'entrée soient identiques, les retours de fonction des mêmes appels sur le même contrat présentent des différences significatives. Cette différence se produit principalement dans la fonction remove_liquidity.

Les attaques par réentrance ciblent principalement la fonction remove_liquidity d'un certain contrat intelligent. Cette fonction renvoie les jetons ajoutés par l'utilisateur lors de la suppression de la liquidité. En raison de l'homogénéité entre Polygon et les chaînes EVM, la logique de réentrance a été déclenchée lors du transfert de MATIC au contrat.

Une analyse plus approfondie révèle que le problème réside dans l'implémentation de la fonction getUnderlyingPrice. Cette fonction implique plusieurs contrats non open source, ce qui complique l'analyse. Cependant, en examinant les emplacements de stockage et la pile d'appels, nous pouvons déduire les valeurs des variables clés et le chemin d'appel de la fonction.

Le cœur de l'attaque réside dans le fait que la valeur de retour de la fonction get_virtual_price a changé de manière significative avant et après la réinsertion. Ce changement est lié au moment de la mise à jour de la variable self.D. Dans des conditions normales, self.D devrait être mis à jour après la finalisation du transfert, mais lors de cette attaque, en raison de la réinsertion, le calcul des prix a été erroné.

Le processus d'exécution de la fonction remove_liquidity comprend : 1) destruction des jetons LP de l'utilisateur ; 2) envoi des fonds de mise en jeu à l'utilisateur ; 3) mise à jour de la valeur self.D. L'attaquant effectue une réinjection à l'étape deux, exploitant la valeur self.D qui n'a pas été mise à jour à temps pour emprunter, obtenant ainsi un profit indu.

Il convient de noter que, bien que la fonction remove_liquidity utilise le décorateur @nonreentrant('lock') pour prévenir les réentrées, ce verrou de réentrée n'a pas eu l'effet escompté car l'attaquant a réentré d'autres contrats pour emprunter.

Cette attaque a mis en évidence l'importance du moment de mise à jour des variables dans les contrats intelligents. Pour améliorer la sécurité, il est conseillé aux équipes de projet de prendre les mesures suivantes :

1. Effectuer un audit de sécurité rigoureux
2. Assurez-vous que les modifications de variables sont terminées avant l'appel externe.
3. Utiliser une méthode multi-sources pour obtenir des informations sur les prix
4. Rédigez le code en suivant le modèle "Vérifications-Effects-Interactions" (Checks-Effects-Interactions)

En mettant en œuvre ces meilleures pratiques, il est possible d'améliorer considérablement la sécurité et la stabilité des contrats intelligents, offrant ainsi une infrastructure plus fiable pour l'écosystème Web3.