Analyse de l'incident d'attaque par réinjection d'OrionProtocol
Le 2 février 2023, l'Orion Protocol sur Ethereum et Binance Smart Chain a subi une attaque par réentrance en raison d'une vulnérabilité dans le contrat, entraînant une perte totale d'environ 2,9 millions de dollars d'actifs, y compris 2 844 766 USDT sur Ethereum et 191 606 BUSD sur Binance Smart Chain.
Analyse du processus d'attaque
L'attaquant a d'abord déployé un contrat Token personnalisé et a effectué les opérations de transfert et d'autorisation pertinentes pour préparer l'attaque ultérieure. Ensuite, l'attaquant a emprunté via la fonction swap de Uniswap V2 et a appelé la méthode ExchangeWithAtomic.swapThroughOrionPool d'OrionProtocol pour échanger des jetons.
Le chemin d'échange est défini comme [USDC, Token de l'attaquant, USDT], où le Token de l'attaquant est utilisé pour exécuter l'opération de rappel. Au cours du processus d'échange, en raison de la logique de rappel contenue dans le contrat du Token de l'attaquant, cela entraîne un rappel de la fonction ExchangeWithAtomic.depositAsset via Token.Transfer lors de l'exécution de la méthode ExchangeWithAtomic.swapThroughOrionPool, permettant ainsi une attaque par réentrance. Cela permet au montant du dépôt d'être accumulé plusieurs fois, et finalement, l'attaquant réalise 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 de trading. Parmi les 1 651 ETH tirés de l'attaque, 657,5 ETH restent dans l'adresse du portefeuille de l'attaquant, le reste ayant é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 appelle la fonction _doSwapTokens, qui met à jour la variable curBalance après avoir effectué une opération de transfert. L'attaquant exploite la logique de rappel ajoutée dans la fonction transfer du Token personnalisé, ce qui entraîne un nouvel appel à la fonction depositAsset lors du processus de transfert, entraînant une mise à jour incorrecte de la variable curBalance. Cela permet à l'attaquant de retirer des fonds supplémentaires via la fonction withdraw après avoir remboursé le prêt flash.
Conseils de sécurité
Pour prévenir des attaques similaires, l'équipe du projet doit prêter attention aux points suivants :
Lors de la mise en œuvre de la fonctionnalité d'échange de tokens, il est nécessaire de prendre en compte les risques de sécurité potentiels liés à la diversité des types de tokens et des chemins d'échange.
Suivre strictement le modèle de codage "Vérifications-Effets-Interactions" (Checks-Effects-Interactions), c'est-à-dire d'abord effectuer des vérifications d'état, puis mettre à jour l'état du contrat, et enfin interagir avec des contrats externes.
Mettre en œuvre des mécanismes de sécurité tels que des verrous réentrants pour prévenir les attaques par réentrance.
Pour les fonctions clés impliquant des opérations financières, un audit de sécurité et des tests complets doivent être effectués.
Envisagez d'introduire des mesures de sécurité supplémentaires telles que des retraits différés ou des signatures multiples pour augmenter la difficulté des attaques.
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. Dans l'écosystème Web3, la sécurité devrait toujours être un facteur de considération 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.
8 J'aime
Récompense
8
5
Partager
Commentaire
0/400
EntryPositionAnalyst
· Il y a 12h
Une autre équipe a été négligente, elle va apprendre à ses dépens.
Voir l'originalRépondre0
BearMarketSurvivor
· Il y a 12h
Le champ de bataille principal a de nouveau été attaqué, pertes de 2,9 millions.
Voir l'originalRépondre0
PaperHandSister
· Il y a 12h
Encore Rekt, pourquoi toujours surveiller les failles des contrats pour en profiter ?
Voir l'originalRépondre0
NeverVoteOnDAO
· Il y a 12h
Encore une faille dans le contrat, c'est sans fin.
Voir l'originalRépondre0
BearMarketSurvivor
· Il y a 12h
Il fait encore noir ? Quels portefeuilles sont sûrs ?
OrionProtocol a subi une attaque par réentrance, entraînant une perte de 2,9 millions de dollars d'actifs.
Analyse de l'incident d'attaque par réinjection d'OrionProtocol
Le 2 février 2023, l'Orion Protocol sur Ethereum et Binance Smart Chain a subi une attaque par réentrance en raison d'une vulnérabilité dans le contrat, entraînant une perte totale d'environ 2,9 millions de dollars d'actifs, y compris 2 844 766 USDT sur Ethereum et 191 606 BUSD sur Binance Smart Chain.
Analyse du processus d'attaque
L'attaquant a d'abord déployé un contrat Token personnalisé et a effectué les opérations de transfert et d'autorisation pertinentes pour préparer l'attaque ultérieure. Ensuite, l'attaquant a emprunté via la fonction swap de Uniswap V2 et a appelé la méthode ExchangeWithAtomic.swapThroughOrionPool d'OrionProtocol pour échanger des jetons.
Le chemin d'échange est défini comme [USDC, Token de l'attaquant, USDT], où le Token de l'attaquant est utilisé pour exécuter l'opération de rappel. Au cours du processus d'échange, en raison de la logique de rappel contenue dans le contrat du Token de l'attaquant, cela entraîne un rappel de la fonction ExchangeWithAtomic.depositAsset via Token.Transfer lors de l'exécution de la méthode ExchangeWithAtomic.swapThroughOrionPool, permettant ainsi une attaque par réentrance. Cela permet au montant du dépôt d'être accumulé plusieurs fois, et finalement, l'attaquant réalise 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 de trading. Parmi les 1 651 ETH tirés de l'attaque, 657,5 ETH restent dans l'adresse du portefeuille de l'attaquant, le reste ayant é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 appelle la fonction _doSwapTokens, qui met à jour la variable curBalance après avoir effectué une opération de transfert. L'attaquant exploite la logique de rappel ajoutée dans la fonction transfer du Token personnalisé, ce qui entraîne un nouvel appel à la fonction depositAsset lors du processus de transfert, entraînant une mise à jour incorrecte de la variable curBalance. Cela permet à l'attaquant de retirer des fonds supplémentaires via la fonction withdraw après avoir remboursé le prêt flash.
Conseils de sécurité
Pour prévenir des attaques similaires, l'équipe du projet doit prêter attention aux points suivants :
Lors de la mise en œuvre de la fonctionnalité d'échange de tokens, il est nécessaire de prendre en compte les risques de sécurité potentiels liés à la diversité des types de tokens et des chemins d'échange.
Suivre strictement le modèle de codage "Vérifications-Effets-Interactions" (Checks-Effects-Interactions), c'est-à-dire d'abord effectuer des vérifications d'état, puis mettre à jour l'état du contrat, et enfin interagir avec des contrats externes.
Mettre en œuvre des mécanismes de sécurité tels que des verrous réentrants pour prévenir les attaques par réentrance.
Pour les fonctions clés impliquant des opérations financières, un audit de sécurité et des tests complets doivent être effectués.
Envisagez d'introduire des mesures de sécurité supplémentaires telles que des retraits différés ou des signatures multiples pour augmenter la difficulté des attaques.
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. Dans l'écosystème Web3, la sécurité devrait toujours être un facteur de considération primordial.