Analyse de l'incident d'attaque par réinjection d'OrionProtocol
Le 2 février 2023 après-midi, le projet OrionProtocol sur Ethereum et la Binance Smart Chain a subi une attaque par réentrance en raison d'une vulnérabilité dans le contrat. Les attaquants ont réalisé un profit d'environ 2,9 millions de dollars, comprenant 2 844 766 USDT sur la chaîne Ethereum et 191 606 BUSD sur la Binance Smart Chain.
Analyse du processus d'attaque
L'attaquant a d'abord déployé un contrat de token personnalisé et a effectué une série d'opérations de transfert et d'autorisation pour préparer l'attaque suivante. Ensuite, l'attaquant a emprunté via la fonction de swap d'un certain DEX et a appelé la méthode ExchangeWithAtomic.swapThroughOrionPool d'OrionProtocol pour échanger des tokens. Le chemin d'échange est défini sur [USDC, Token de l'attaquant, USDT].
Lors de l'exécution de la méthode swapThroughOrionPool, un attaquant a profité d'une fonction de rappel dans le contrat Token, ce qui a déclenché une attaque de réentrance pendant le processus de transfert. L'attaquant a utilisé la méthode Token.Transfer pour appeler à plusieurs reprises la fonction ExchangeWithAtomic.depositAsset, ce qui a entraîné une accumulation continue du montant déposé. Finalement, l'attaquant a réalisé un profit grâce à l'opération de retrait.
Flux de fonds
Selon les données en chaîne, les fonds initiaux de l'attaquant proviennent d'un portefeuille chaud d'une plateforme d'échange. Parmi les 1 651 ETH réalisés, 657,5 sont toujours présents dans l'adresse du portefeuille de l'attaquant, tandis que le reste a été transféré par le biais de services de mélange.
Analyse des vulnérabilités
Le cœur de la vulnérabilité réside dans la fonction doSwapThroughOrionPool du contrat ExchangeWithAtomic. Cette fonction présente un défaut logique lors de l'exécution de l'opération _doSwapTokens. Plus précisément, le code met à jour la variable curBalance uniquement après l'exécution du transfert, ce qui crée des conditions propices à une attaque par réentrance.
L'attaquant a ajouté une logique de rappel dans la fonction transfer du Token personnalisé, appelant à plusieurs reprises la fonction depositAsset, ce qui a entraîné une mise à jour incorrecte de curBalance. Finalement, après avoir remboursé le prêt flash, l'attaquant a appelé la fonction withdraw pour retirer des fonds excessifs.
Conseils de prévention
Pour éviter des attaques similaires, l'équipe du projet doit prêter attention aux points suivants :
Lors de la mise en œuvre de la fonction d'échange de jetons, il est nécessaire de prendre en compte de manière exhaustive les risques de sécurité potentiels liés aux différents types de jetons et aux chemins d'échange.
Suivez strictement le modèle de codage "Checks-Effects-Interactions"(Checks-Effects-Interactions), c'est-à-dire effectuez d'abord la vérification des conditions, puis mettez à jour les variables d'état, et enfin exécutez les appels externes.
Renforcer le contrôle de sécurité des appels externes, en particulier lors du traitement des jetons personnalisés par l'utilisateur.
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.
Utilisez des bibliothèques de sécurité matures et des meilleures pratiques, telles que SafeERC20 d'OpenZeppelin.
En prenant ces mesures, il est possible de réduire considérablement le risque d'attaque des contrats intelligents et d'améliorer la sécurité globale du projet.
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.
11 J'aime
Récompense
11
6
Reposter
Partager
Commentaire
0/400
ser_ngmi
· Il y a 18h
Je n'ai plus d'argent.
Voir l'originalRépondre0
PretendingToReadDocs
· Il y a 18h
Il se passe toujours quelque chose, pourquoi continuer ?
Voir l'originalRépondre0
LiquidityWizard
· Il y a 18h
Rug Pull prédit~
Voir l'originalRépondre0
degenonymous
· Il y a 18h
pigeons encore pris pour des idiots
Voir l'originalRépondre0
CountdownToBroke
· Il y a 18h
Encore un qui a explosé
Voir l'originalRépondre0
BoredApeResistance
· Il y a 18h
Encore une vulnérabilité de contrat, j'ai trop mangé.
OrionProtocol a subi une attaque par réentrée, entraînant une perte d'environ 2,9 millions de dollars.
Analyse de l'incident d'attaque par réinjection d'OrionProtocol
Le 2 février 2023 après-midi, le projet OrionProtocol sur Ethereum et la Binance Smart Chain a subi une attaque par réentrance en raison d'une vulnérabilité dans le contrat. Les attaquants ont réalisé un profit d'environ 2,9 millions de dollars, comprenant 2 844 766 USDT sur la chaîne Ethereum et 191 606 BUSD sur la Binance Smart Chain.
Analyse du processus d'attaque
L'attaquant a d'abord déployé un contrat de token personnalisé et a effectué une série d'opérations de transfert et d'autorisation pour préparer l'attaque suivante. Ensuite, l'attaquant a emprunté via la fonction de swap d'un certain DEX et a appelé la méthode ExchangeWithAtomic.swapThroughOrionPool d'OrionProtocol pour échanger des tokens. Le chemin d'échange est défini sur [USDC, Token de l'attaquant, USDT].
Lors de l'exécution de la méthode swapThroughOrionPool, un attaquant a profité d'une fonction de rappel dans le contrat Token, ce qui a déclenché une attaque de réentrance pendant le processus de transfert. L'attaquant a utilisé la méthode Token.Transfer pour appeler à plusieurs reprises la fonction ExchangeWithAtomic.depositAsset, ce qui a entraîné une accumulation continue du montant déposé. Finalement, l'attaquant a réalisé un profit grâce à l'opération de retrait.
Flux de fonds
Selon les données en chaîne, les fonds initiaux de l'attaquant proviennent d'un portefeuille chaud d'une plateforme d'échange. Parmi les 1 651 ETH réalisés, 657,5 sont toujours présents dans l'adresse du portefeuille de l'attaquant, tandis que le reste a été transféré par le biais de services de mélange.
Analyse des vulnérabilités
Le cœur de la vulnérabilité réside dans la fonction doSwapThroughOrionPool du contrat ExchangeWithAtomic. Cette fonction présente un défaut logique lors de l'exécution de l'opération _doSwapTokens. Plus précisément, le code met à jour la variable curBalance uniquement après l'exécution du transfert, ce qui crée des conditions propices à une attaque par réentrance.
L'attaquant a ajouté une logique de rappel dans la fonction transfer du Token personnalisé, appelant à plusieurs reprises la fonction depositAsset, ce qui a entraîné une mise à jour incorrecte de curBalance. Finalement, après avoir remboursé le prêt flash, l'attaquant a appelé la fonction withdraw pour retirer des fonds excessifs.
Conseils de prévention
Pour éviter des attaques similaires, l'équipe du projet doit prêter attention aux points suivants :
Lors de la mise en œuvre de la fonction d'échange de jetons, il est nécessaire de prendre en compte de manière exhaustive les risques de sécurité potentiels liés aux différents types de jetons et aux chemins d'échange.
Suivez strictement le modèle de codage "Checks-Effects-Interactions"(Checks-Effects-Interactions), c'est-à-dire effectuez d'abord la vérification des conditions, puis mettez à jour les variables d'état, et enfin exécutez les appels externes.
Renforcer le contrôle de sécurité des appels externes, en particulier lors du traitement des jetons personnalisés par l'utilisateur.
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.
Utilisez des bibliothèques de sécurité matures et des meilleures pratiques, telles que SafeERC20 d'OpenZeppelin.
En prenant ces mesures, il est possible de réduire considérablement le risque d'attaque des contrats intelligents et d'améliorer la sécurité globale du projet.