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

Récemment, un projet nommé Jarvis_Network a subi une attaque de réinjection de Prêts Flash, entraînant une perte d'environ 663 000 jetons MATIC. Cet événement s'est produit le soir du 15 janvier 2023.

Grâce à une analyse approfondie de la pile d'appels de transactions, nous avons découvert que l'attaquant a exploité une vulnérabilité de réentrance. Au cours du processus de réentrance, la même fonction du même contrat a été appelée plusieurs fois, mais les valeurs de retour de chaque appel présentaient d'énormes différences. Cette différence se manifeste principalement dans la fonction remove_liquidity.

L'attaque par réinjection se produit lors du processus de retrait de liquidité. Étant donné que Polygon et EVM sont des chaînes homomorphes, lorsque MATIC est transféré au contrat, cela déclenche la logique de réinjection du contrat. En analysant en détail la pile d'appels, nous avons découvert que le problème se trouvait dans la fonction getUnderlyingPrice.

Une enquête plus approfondie a révélé que les attaquants ont exploité une vulnérabilité dans le timing de mise à jour de la variable self.D lors de la suppression de la liquidité. Normalement, le processus de la méthode remove_liquidity devrait être : 1) détruire le LP de l'utilisateur ; 2) envoyer les fonds de mise à l'utilisateur ; 3) mettre à jour self.D. Cependant, les attaquants ont effectué une opération de réentrance à la deuxième étape, ce qui a entraîné une grave erreur de calcul des prix.

Bien que la fonction remove_liquidity utilise le décorateur @nonreentrant('lock') pour prévenir la réentrance, ce verrou de réentrance n'a pas fonctionné car l'attaquant a réentré des fonds de prêt dans d'autres contrats.

Cette attaque a principalement exposé deux problèmes :

1. La logique de modification des variables se trouve après l'appel externe, ce qui entraîne une anomalie dans l'obtention des prix.
2. La réentrance inter-contrats rend le verrou de réentrance inopérant.

Pour éviter des attaques similaires, il est conseillé aux équipes de projet de prendre les mesures suivantes :

1. Assurez-vous que le code a été soumis à un audit de sécurité rigoureux.
2. Placez la modification des variables avant l'appel externe.
3. Utilisation d'une méthode à plusieurs sources de données pour obtenir les prix.
4. Suivez la norme de codage "d'abord vérifier, ensuite écrire dans les variables, puis effectuer des appels externes" (Checks-Effects-Interactions).

En prenant ces mesures, le projet peut considérablement améliorer sa sécurité et sa stabilité, offrant aux utilisateurs des services plus fiables.

![Analyse de l'incident d'attaque par réinjection de Prêts Flash de Jarvis Network](https://img-cdn.gateio.im/webp-social/moments-fcd66f4cc03bb8e822c9414526681442.webp01

![Analyse des événements d'attaque par réentrance des Prêts Flash de Jarvis Network])https://img-cdn.gateio.im/webp-social/moments-9b2de9b00c52d3ff96d5a361df65769a.webp(

![Analyse de l'incident d'attaque par réinjection des Prêts Flash de Jarvis Network])https://img-cdn.gateio.im/webp-social/moments-88f9283ee0923cff2a22405715721cd2.webp(

![Analyse de l'incident d'attaque par réinjection de Prêts Flash de Jarvis Network])https://img-cdn.gateio.im/webp-social/moments-d41ac025ee561569cce3b941d7e07967.webp(

![Analyse de l'événement d'attaque par réinjection des Prêts Flash de Jarvis Network])https://img-cdn.gateio.im/webp-social/moments-2c4474781d661306bc8c432dad3942c0.webp(