Analyse des événements 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é de 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 la Binance Smart Chain.
Analyse du processus d'attaque
L'attaquant a d'abord déployé un contrat Token spécial et effectué une série de préparatifs. Ensuite, l'attaquant a emprunté des fonds via la fonction swap d'un DEX et a appelé la méthode ExchangeWithAtomic.swapThroughOrionPool d'OrionProtocol pour échanger des tokens. Le chemin d'échange inclut l'adresse du contrat Token créé par l'attaquant, ce qui prépare le terrain pour une attaque par rappel ultérieure.
Lors du processus d'échange, une attaque a eu lieu en raison de la logique de rappel incluse dans le contrat Token de l'attaquant, ce qui a entraîné des appels répétés à la méthode ExchangeWithAtomic.depositAsset lors de l'opération de transfert. Cette attaque par réentrance a permis d'accumuler de manière répétée le montant déposé, permettant finalement à l'attaquant de retirer des fonds dépassant les limites normales.
Flux de fonds
Le capital initial de l'attaquant provient du portefeuille chaud d'une certaine plateforme d'échange. Parmi les 1 651 ETH de bénéfices de l'attaque, 657,5 ETH restent dans l'adresse du portefeuille de l'attaquant, tandis que le reste a été transféré via un outil de mélange.
Analyse des vulnérabilités
Le problème central de l'attaque se situe dans la fonction doSwapThroughOrionPool du contrat ExchangeWithAtomic. Cette fonction, lors du traitement des échanges de jetons, ne gère pas correctement les éventuelles situations de réentrance. Plus précisément, dans la fonction _doSwapTokens, la variable curBalance n'est mise à jour qu'après l'opération de transfert de jetons, ce qui offre une opportunité à l'attaquant.
L'attaquant a ajouté une logique de rappel dans la fonction transfer du Token personnalisé, déclenchant l'appel de la fonction depositAsset à chaque transfert, ce qui a conduit à une mise à jour incorrecte de la variable curBalance. Finalement, après avoir remboursé le prêt éclair, l'attaquant a retiré des fonds excédentaires via la fonction withdraw.
Reproduction de la vulnérabilité
Les chercheurs ont fourni un certain code POC, démontrant comment exploiter cette vulnérabilité pour mener des attaques. Le code simule principalement le processus d'opération de l'attaquant, y compris la création de tokens falsifiés, la configuration d'une piscine de liquidités, la réalisation d'un prêt flash et l'attaque par réinjection, etc.
Conseils de sécurité
Pour éviter des attaques similaires, les équipes de projet doivent prêter attention aux points suivants lors de la conception des contrats :
Lors de la mise en œuvre de la fonctionnalité d'échange de jetons, il est nécessaire de prendre en compte les risques potentiels liés aux différents types de jetons et aux chemins d'échange.
Écrivez le code du contrat en suivant le modèle "Vérifications-Effects-Interactions" (Checks-Effects-Interactions), c'est-à-dire d'abord effectuer les vérifications des conditions, puis mettre à jour les variables d'état, et enfin exécuter les appels externes.
Utilisez des verrous de réentrance ou d'autres mécanismes de protection contre la réentrance pour protéger les fonctions critiques.
Effectuer des audits de sécurité réguliers pour détecter et corriger rapidement les vulnérabilités potentielles.
Envisagez d'introduire des limites sur le montant des transactions ou sur la fréquence des transactions afin de réduire l'impact des attaques potentielles.
En prenant ces mesures, le projet peut considérablement améliorer la sécurité des contrats et réduire le risque d'attaques. Dans l'écosystème Web3, la sécurité doit toujours être une priorité.
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
4
Partager
Commentaire
0/400
SleepTrader
· Il y a 8h
Un autre débutant en contrat s'est fait frapper.
Voir l'originalRépondre0
StablecoinEnjoyer
· Il y a 8h
Encore une fois, ils se sont échappés, ils n'ont pas de mémoire.
Voir l'originalRépondre0
GetRichLeek
· Il y a 9h
Récupérer des coupons avec des contrats au quotidien 哈哈哈哈
Voir l'originalRépondre0
MemeEchoer
· Il y a 9h
Encore allongé, il semble que les smart contracts doivent être écrits sérieusement.
OrionProtocol a subi une attaque par réentrance, entraînant une perte d'actifs de 2,9 millions de dollars.
Analyse des événements 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é de 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 la Binance Smart Chain.
Analyse du processus d'attaque
L'attaquant a d'abord déployé un contrat Token spécial et effectué une série de préparatifs. Ensuite, l'attaquant a emprunté des fonds via la fonction swap d'un DEX et a appelé la méthode ExchangeWithAtomic.swapThroughOrionPool d'OrionProtocol pour échanger des tokens. Le chemin d'échange inclut l'adresse du contrat Token créé par l'attaquant, ce qui prépare le terrain pour une attaque par rappel ultérieure.
Lors du processus d'échange, une attaque a eu lieu en raison de la logique de rappel incluse dans le contrat Token de l'attaquant, ce qui a entraîné des appels répétés à la méthode ExchangeWithAtomic.depositAsset lors de l'opération de transfert. Cette attaque par réentrance a permis d'accumuler de manière répétée le montant déposé, permettant finalement à l'attaquant de retirer des fonds dépassant les limites normales.
Flux de fonds
Le capital initial de l'attaquant provient du portefeuille chaud d'une certaine plateforme d'échange. Parmi les 1 651 ETH de bénéfices de l'attaque, 657,5 ETH restent dans l'adresse du portefeuille de l'attaquant, tandis que le reste a été transféré via un outil de mélange.
Analyse des vulnérabilités
Le problème central de l'attaque se situe dans la fonction doSwapThroughOrionPool du contrat ExchangeWithAtomic. Cette fonction, lors du traitement des échanges de jetons, ne gère pas correctement les éventuelles situations de réentrance. Plus précisément, dans la fonction _doSwapTokens, la variable curBalance n'est mise à jour qu'après l'opération de transfert de jetons, ce qui offre une opportunité à l'attaquant.
L'attaquant a ajouté une logique de rappel dans la fonction transfer du Token personnalisé, déclenchant l'appel de la fonction depositAsset à chaque transfert, ce qui a conduit à une mise à jour incorrecte de la variable curBalance. Finalement, après avoir remboursé le prêt éclair, l'attaquant a retiré des fonds excédentaires via la fonction withdraw.
Reproduction de la vulnérabilité
Les chercheurs ont fourni un certain code POC, démontrant comment exploiter cette vulnérabilité pour mener des attaques. Le code simule principalement le processus d'opération de l'attaquant, y compris la création de tokens falsifiés, la configuration d'une piscine de liquidités, la réalisation d'un prêt flash et l'attaque par réinjection, etc.
Conseils de sécurité
Pour éviter des attaques similaires, les équipes de projet doivent prêter attention aux points suivants lors de la conception des contrats :
Lors de la mise en œuvre de la fonctionnalité d'échange de jetons, il est nécessaire de prendre en compte les risques potentiels liés aux différents types de jetons et aux chemins d'échange.
Écrivez le code du contrat en suivant le modèle "Vérifications-Effects-Interactions" (Checks-Effects-Interactions), c'est-à-dire d'abord effectuer les vérifications des conditions, puis mettre à jour les variables d'état, et enfin exécuter les appels externes.
Utilisez des verrous de réentrance ou d'autres mécanismes de protection contre la réentrance pour protéger les fonctions critiques.
Effectuer des audits de sécurité réguliers pour détecter et corriger rapidement les vulnérabilités potentielles.
Envisagez d'introduire des limites sur le montant des transactions ou sur la fréquence des transactions afin de réduire l'impact des attaques potentielles.
En prenant ces mesures, le projet peut considérablement améliorer la sécurité des contrats et réduire le risque d'attaques. Dans l'écosystème Web3, la sécurité doit toujours être une priorité.