Analyse de l'incident d'attaque par réinjection d'OrionProtocol
Vue d'ensemble de l'événement
Selon les données de surveillance en chaîne, le 2 février 2023 à 15h40:20 UTC, OrionProtocol a subi une attaque par réentrance sur Ethereum et Binance Smart Chain en raison d'une vulnérabilité de contrat. L'attaquant a réalisé un bénéfice de 2,844,766 USDT sur le réseau Ethereum et de 191,606 BUSD sur Binance Smart Chain, soit un total d'environ 2,9 millions de dollars.
Analyse du processus d'attaque
Détails de l'attaque sur la chaîne Ethereum
Token personnalisé
Lors du processus d'échange, en raison de la fonction de rappel incluse dans le contrat Token créé par l'attaquant, l'attaquant a pu appeler plusieurs fois la fonction ExchangeWithAtomic.depositAsset via la méthode Token.Transfer pendant l'exécution de ExchangeWithAtomic.swapThroughOrionPool. Cela a entraîné une accumulation continue du montant déposé, permettant finalement à l'attaquant de réaliser un profit par le biais d'opérations de retrait.
Flux de fonds
Les fonds initiaux de l'attaquant proviennent d'un portefeuille chaud d'une grande plateforme d'échange. Parmi les 1 651 ETH obtenus par l'attaque, 657,5 ETH restent dans le portefeuille de l'attaquant, tandis que le reste a été transféré via un service de mixage.
Analyse des vulnérabilités
Le problème central de la vulnérabilité se situe dans la fonction doSwapThroughOrionPool. Cette fonction met à jour la variable curBalance après l'exécution du transfert de jetons, sans suivre le modèle "vérification - effet - interaction" (Checks-Effects-Interactions). Un attaquant exploite le mécanisme de rappel ajouté dans la fonction transfer du Token personnalisé, en appelant de manière répétée la fonction depositAsset avant la mise à jour de curBalance, ce qui entraîne une erreur dans le calcul du solde.
Conseils de prévention
L'équipe du projet doit prendre en compte les risques de sécurité potentiels liés à différents types de jetons et aux chemins d'échange lors de la conception des contrats impliquant des fonctionnalités d'échange de jetons.
Suivre strictement les spécifications de codage "vérification - effet - interaction", c'est-à-dire d'abord effectuer la vérification des conditions, puis mettre à jour les variables d'état, et enfin exécuter les appels externes.
Pour les fonctions susceptibles de présenter un risque de réentrance, utilisez des mécanismes de protection tels que des verrous de réentrance.
Ajouter une vérification de solde avant et après les opérations clés pour assurer l'atome et la cohérence des transactions.
Effectuer régulièrement des audits de code et des tests de sécurité pour détecter et corriger rapidement les vulnérabilités potentielles.
Envisagez d'implémenter des limites sur le montant des transactions ou sur la fréquence des transactions pour réduire les pertes causées par une attaque unique.
En prenant ces mesures, le projet peut considérablement améliorer la sécurité des contrats et réduire le risque de subir des attaques similaires. Dans l'écosystème Web3 en pleine évolution, la sécurité devrait toujours être un facteur de préoccupation primordial.
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.
10 J'aime
Récompense
10
3
Partager
Commentaire
0/400
Token_Sherpa
· Il y a 8h
ugh... un autre jour, une autre attaque de réentrance. Quand les développeurs apprendront-ils à vérifier les effets et les interactions, smh
OrionProtocol a subi une attaque par réentrance de 2,9 millions de dollars : analyse des vulnérabilités et recommandations de prévention.
Analyse de l'incident d'attaque par réinjection d'OrionProtocol
Vue d'ensemble de l'événement
Selon les données de surveillance en chaîne, le 2 février 2023 à 15h40:20 UTC, OrionProtocol a subi une attaque par réentrance sur Ethereum et Binance Smart Chain en raison d'une vulnérabilité de contrat. L'attaquant a réalisé un bénéfice de 2,844,766 USDT sur le réseau Ethereum et de 191,606 BUSD sur Binance Smart Chain, soit un total d'environ 2,9 millions de dollars.
Analyse du processus d'attaque
Détails de l'attaque sur la chaîne Ethereum
Token personnalisé
Lors du processus d'échange, en raison de la fonction de rappel incluse dans le contrat Token créé par l'attaquant, l'attaquant a pu appeler plusieurs fois la fonction ExchangeWithAtomic.depositAsset via la méthode Token.Transfer pendant l'exécution de ExchangeWithAtomic.swapThroughOrionPool. Cela a entraîné une accumulation continue du montant déposé, permettant finalement à l'attaquant de réaliser un profit par le biais d'opérations de retrait.
Flux de fonds
Les fonds initiaux de l'attaquant proviennent d'un portefeuille chaud d'une grande plateforme d'échange. Parmi les 1 651 ETH obtenus par l'attaque, 657,5 ETH restent dans le portefeuille de l'attaquant, tandis que le reste a été transféré via un service de mixage.
Analyse des vulnérabilités
Le problème central de la vulnérabilité se situe dans la fonction doSwapThroughOrionPool. Cette fonction met à jour la variable curBalance après l'exécution du transfert de jetons, sans suivre le modèle "vérification - effet - interaction" (Checks-Effects-Interactions). Un attaquant exploite le mécanisme de rappel ajouté dans la fonction transfer du Token personnalisé, en appelant de manière répétée la fonction depositAsset avant la mise à jour de curBalance, ce qui entraîne une erreur dans le calcul du solde.
Conseils de prévention
L'équipe du projet doit prendre en compte les risques de sécurité potentiels liés à différents types de jetons et aux chemins d'échange lors de la conception des contrats impliquant des fonctionnalités d'échange de jetons.
Suivre strictement les spécifications de codage "vérification - effet - interaction", c'est-à-dire d'abord effectuer la vérification des conditions, puis mettre à jour les variables d'état, et enfin exécuter les appels externes.
Pour les fonctions susceptibles de présenter un risque de réentrance, utilisez des mécanismes de protection tels que des verrous de réentrance.
Ajouter une vérification de solde avant et après les opérations clés pour assurer l'atome et la cohérence des transactions.
Effectuer régulièrement des audits de code et des tests de sécurité pour détecter et corriger rapidement les vulnérabilités potentielles.
Envisagez d'implémenter des limites sur le montant des transactions ou sur la fréquence des transactions pour réduire les pertes causées par une attaque unique.
En prenant ces mesures, le projet peut considérablement améliorer la sécurité des contrats et réduire le risque de subir des attaques similaires. Dans l'écosystème Web3 en pleine évolution, la sécurité devrait toujours être un facteur de préoccupation primordial.