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 une perte de 663 101 MATIC. Cette attaque a principalement exploité les Prêts Flash et une vulnérabilité de réentrance, entraînant une perte de fonds du projet.
En analysant la pile d'appels de transactions, il a été découvert que l'attaquant avait mis en œuvre une attaque par réentrance dans la fonction remove_liquidity. Cette fonction est responsable de la suppression de la liquidité et du retour des jetons aux utilisateurs. Étant donné que Polygon a une structure similaire à celle de la chaîne EVM, une réentrance de contrat a été déclenchée lors du transfert de MATIC.
L'attaque de réentrance se produit lors de la vérification des prix. L'attaquant transfère MATIC au contrat de l'attaquant lors de la suppression de la liquidité. Pendant le processus de rappel, l'attaquant interroge d'abord le prix d'un certain jeton. En raison de la mise à jour du variable self.D dans le contrat qui est retardée par rapport à l'opération de transfert, cela conduit à une erreur dans l'obtention du prix initial.
Le processus d'exécution de la fonction remove_liquidity est le suivant :
Brûler les tokens LP des utilisateurs
Envoyer des fonds de mise en gage à l'utilisateur
Mettre à jour la variable self.D
La variable self.D est utilisée pour le calcul des prix et est mise à jour lors de l'ajout et du retrait de liquidité. Un attaquant a exploité des opérations de grande envergure, entraînant une augmentation significative de la valeur de self.D lors de l'ajout de liquidité, tandis que la mise à jour lors du retrait n'a pas été effectuée à temps.
Bien que la fonction remove_liquidity utilise le décorateur @nonreentrant('lock') pour prévenir les réentrées, les attaquants ont contourné cette restriction en empruntant à travers les contrats.
Cette attaque a révélé des vulnérabilités de sécurité dans le code du projet. Pour éviter des problèmes similaires, il est conseillé aux équipes du projet de prendre les mesures suivantes :
Effectuer un audit de sécurité rigoureux
Placer l'opération de modification de variable avant l'appel externe.
Utiliser plusieurs sources de données pour obtenir les prix
Suivre la norme de codage "Vérifications-Effets-Interactions" (Checks-Effects-Interactions)
En optimisant la logique du code et en renforçant les mesures de sécurité, on peut efficacement améliorer la sécurité et la stabilité du projet, empêchant ainsi la récurrence d'attaques 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.
23 J'aime
Récompense
23
9
Partager
Commentaire
0/400
MEV_Whisperer
· 07-22 15:42
Cette casserole ne peut être développée que pour supporter.
Voir l'originalRépondre0
AirdropCollector
· 07-22 15:27
On n'a même pas envie d'acheter.
Voir l'originalRépondre0
GateUser-e87b21ee
· 07-20 04:01
projet de fête la protection n'est pas efficace.
Voir l'originalRépondre0
StakeOrRegret
· 07-19 19:17
Encore un projet s'est fait piller...
Voir l'originalRépondre0
ZenMiner
· 07-19 19:09
Que fait ce garde ?
Voir l'originalRépondre0
LayerZeroEnjoyer
· 07-19 19:09
Eh, encore une réentrante, vieux piège.
Voir l'originalRépondre0
LiquidityOracle
· 07-19 19:05
Qui a dit que ne pas prendre le codage au sérieux est acceptable
Voir l'originalRépondre0
DecentralizedElder
· 07-19 19:01
Encore hacké, vraiment pas de mémoire.
Voir l'originalRépondre0
WhaleWatcher
· 07-19 18:54
Un autre projet à moitié fini a été durement frappé.
Jarvis Network a subi une attaque de réentrance par des Prêts Flash, entraînant une perte de 663,101 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é, entraînant une perte de 663 101 MATIC. Cette attaque a principalement exploité les Prêts Flash et une vulnérabilité de réentrance, entraînant une perte de fonds du projet.
En analysant la pile d'appels de transactions, il a été découvert que l'attaquant avait mis en œuvre une attaque par réentrance dans la fonction remove_liquidity. Cette fonction est responsable de la suppression de la liquidité et du retour des jetons aux utilisateurs. Étant donné que Polygon a une structure similaire à celle de la chaîne EVM, une réentrance de contrat a été déclenchée lors du transfert de MATIC.
L'attaque de réentrance se produit lors de la vérification des prix. L'attaquant transfère MATIC au contrat de l'attaquant lors de la suppression de la liquidité. Pendant le processus de rappel, l'attaquant interroge d'abord le prix d'un certain jeton. En raison de la mise à jour du variable self.D dans le contrat qui est retardée par rapport à l'opération de transfert, cela conduit à une erreur dans l'obtention du prix initial.
Le processus d'exécution de la fonction remove_liquidity est le suivant :
La variable self.D est utilisée pour le calcul des prix et est mise à jour lors de l'ajout et du retrait de liquidité. Un attaquant a exploité des opérations de grande envergure, entraînant une augmentation significative de la valeur de self.D lors de l'ajout de liquidité, tandis que la mise à jour lors du retrait n'a pas été effectuée à temps.
Bien que la fonction remove_liquidity utilise le décorateur @nonreentrant('lock') pour prévenir les réentrées, les attaquants ont contourné cette restriction en empruntant à travers les contrats.
Cette attaque a révélé des vulnérabilités de sécurité dans le code du projet. Pour éviter des problèmes similaires, il est conseillé aux équipes du projet de prendre les mesures suivantes :
En optimisant la logique du code et en renforçant les mesures de sécurité, on peut efficacement améliorer la sécurité et la stabilité du projet, empêchant ainsi la récurrence d'attaques similaires.