Analyse de l'incident d'attaque par réentrance d'OrionProtocol
Le 2 février 2023, l'OrionProtocol sur Ethereum et Binance Smart Chain a subi une attaque de réentrance en raison d'une vulnérabilité de contrat, entraînant une perte d'environ 2,9 millions de dollars, dont 2 844 766 USDT sur Ethereum et 191 606 BUSD sur Binance Smart Chain.
Analyse du processus d'attaque
L'attaquant a d'abord créé un contrat de Token et a effectué les opérations de transfert et d'autorisation nécessaires pour préparer l'attaque ultérieure. Ensuite, l'attaquant a emprunté via la méthode swap de UNI-V2 et a appelé la méthode swapThroughOrionPool du contrat ExchangeWithAtomic pour échanger des tokens. Le chemin d'échange est défini comme USDC → Token créé par l'attaquant → USDT.
Au cours du processus d'échange, en raison de la fonction de rappel contenue dans le contrat de Token créé par l'attaquant, cela a conduit à ce que lors de l'exécution de la méthode ExchangeWithAtomic.swapThroughOrionPool, la méthode ExchangeWithAtomic.depositAsset soit rappelée via Token.Transfer, entraînant une attaque par réentrance. Cela a permis au montant du dépôt de s'accumuler continuellement, 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 du compte de portefeuille chaud d'une plateforme d'échange. Parmi les 1 651 ETH réalisés, 657,5 ETH sont toujours dans l'adresse du portefeuille de l'attaquant, le reste ayant été transféré via un service de mélange.
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, dans laquelle l'opération de transfert de jetons se produit avant la mise à jour de curBalance. Les attaquants exploitent la fonctionnalité de rappel ajoutée dans la fonction transfer du Token personnalisé, en appelant à nouveau la fonction depositAsset avant la mise à jour de curBalance, ce qui entraîne une mise à jour incorrecte de curBalance. Finalement, après avoir remboursé le prêt éclair, les attaquants extraient des fonds en appelant la fonction withdraw pour compléter l'attaque.
Conseils de prévention
Lors de la conception du contrat, il convient de prendre en compte les risques potentiels liés à la diversité des tokens et des chemins d'échange.
Suivre la norme de codage "d'abord évaluer, puis mettre à jour les variables, et enfin effectuer les appels externes" (modèle Checks-Effects-Interactions) peut efficacement améliorer la sécurité des contrats.
Lors de la mise en œuvre de la fonction d'échange de jetons, il est particulièrement important de prêter attention au risque d'attaques par réentrance, et il peut être envisagé d'utiliser des mécanismes de verrouillage de réentrance pour se protéger.
Pour les fonctions clés impliquant des opérations financières, il est recommandé de procéder à un audit de sécurité complet et à des tests, y compris la simulation de divers cas limites et scénarios exceptionnels.
Effectuer régulièrement des vérifications de sécurité des contrats et mettre à jour et réparer rapidement les vulnérabilités potentielles.
En prenant ces mesures, il est possible de réduire considérablement le risque d'attaques sur les contrats intelligents, augmentant ainsi la sécurité globale du projet. Dans l'écosystème Web3, la sécurité reste l'un des facteurs les plus importants.
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.
12 J'aime
Récompense
12
6
Reposter
Partager
Commentaire
0/400
GasFeeCrier
· Il y a 17h
Vous ne faites même pas bien la protection des contrats ? Tant pis pour vous !
Voir l'originalRépondre0
AirdropBuffet
· 08-12 21:06
Encore un smart contract qui a échoué~
Voir l'originalRépondre0
ZenMiner
· 08-12 21:05
La faille est si grande, pourquoi ne m'as-tu pas appelé pour l'audit ?
Voir l'originalRépondre0
HallucinationGrower
· 08-12 21:00
Encore une opportunité de Rug Pull
Voir l'originalRépondre0
TokenStorm
· 08-12 20:57
Ah, le script est déjà écrit, il ne manque qu'une étape.
OrionProtocol a subi une attaque par réentrance, entraînant une perte de 2,9 millions de dollars en chiffrement.
Analyse de l'incident d'attaque par réentrance d'OrionProtocol
Le 2 février 2023, l'OrionProtocol sur Ethereum et Binance Smart Chain a subi une attaque de réentrance en raison d'une vulnérabilité de contrat, entraînant une perte d'environ 2,9 millions de dollars, dont 2 844 766 USDT sur Ethereum et 191 606 BUSD sur Binance Smart Chain.
Analyse du processus d'attaque
L'attaquant a d'abord créé un contrat de Token et a effectué les opérations de transfert et d'autorisation nécessaires pour préparer l'attaque ultérieure. Ensuite, l'attaquant a emprunté via la méthode swap de UNI-V2 et a appelé la méthode swapThroughOrionPool du contrat ExchangeWithAtomic pour échanger des tokens. Le chemin d'échange est défini comme USDC → Token créé par l'attaquant → USDT.
Au cours du processus d'échange, en raison de la fonction de rappel contenue dans le contrat de Token créé par l'attaquant, cela a conduit à ce que lors de l'exécution de la méthode ExchangeWithAtomic.swapThroughOrionPool, la méthode ExchangeWithAtomic.depositAsset soit rappelée via Token.Transfer, entraînant une attaque par réentrance. Cela a permis au montant du dépôt de s'accumuler continuellement, 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 du compte de portefeuille chaud d'une plateforme d'échange. Parmi les 1 651 ETH réalisés, 657,5 ETH sont toujours dans l'adresse du portefeuille de l'attaquant, le reste ayant été transféré via un service de mélange.
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, dans laquelle l'opération de transfert de jetons se produit avant la mise à jour de curBalance. Les attaquants exploitent la fonctionnalité de rappel ajoutée dans la fonction transfer du Token personnalisé, en appelant à nouveau la fonction depositAsset avant la mise à jour de curBalance, ce qui entraîne une mise à jour incorrecte de curBalance. Finalement, après avoir remboursé le prêt éclair, les attaquants extraient des fonds en appelant la fonction withdraw pour compléter l'attaque.
Conseils de prévention
Lors de la conception du contrat, il convient de prendre en compte les risques potentiels liés à la diversité des tokens et des chemins d'échange.
Suivre la norme de codage "d'abord évaluer, puis mettre à jour les variables, et enfin effectuer les appels externes" (modèle Checks-Effects-Interactions) peut efficacement améliorer la sécurité des contrats.
Lors de la mise en œuvre de la fonction d'échange de jetons, il est particulièrement important de prêter attention au risque d'attaques par réentrance, et il peut être envisagé d'utiliser des mécanismes de verrouillage de réentrance pour se protéger.
Pour les fonctions clés impliquant des opérations financières, il est recommandé de procéder à un audit de sécurité complet et à des tests, y compris la simulation de divers cas limites et scénarios exceptionnels.
Effectuer régulièrement des vérifications de sécurité des contrats et mettre à jour et réparer rapidement les vulnérabilités potentielles.
En prenant ces mesures, il est possible de réduire considérablement le risque d'attaques sur les contrats intelligents, augmentant ainsi la sécurité globale du projet. Dans l'écosystème Web3, la sécurité reste l'un des facteurs les plus importants.