Analyse de l'incident de réentrance 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. L'attaquant a volé environ 2,84 millions de USDT de la chaîne Ethereum et environ 190 000 BUSD de la Binance Smart Chain, pour une perte totale d'environ 2,9 millions de dollars.
Analyse du processus d'attaque
L'attaquant a d'abord déployé un contrat de Token personnalisé et a effectué une série de préparations. Ensuite, l'attaquant a emprunté des fonds via la fonction swap d'un certain DEX, en appelant la méthode ExchangeWithAtomic.swapThroughOrionPool d'OrionProtocol pour échanger des tokens. Le chemin d'échange comprenait l'adresse du contrat Token créé par l'attaquant.
Dans le processus d'échange, l'attaquant a exploité la fonction de rappel du contrat Token personnalisé en appelant à plusieurs reprises la méthode ExchangeWithAtomic.depositAsset, entraînant une accumulation multiple du montant déposé. Finalement, l'attaquant a réalisé des bénéfices en effectuant une opération de retrait.
Flux de fonds
Selon le suivi, les fonds initiaux des attaquants proviennent d'un portefeuille chaud d'une certaine plateforme d'échange. Parmi les 1651 ETH obtenus par l'attaque, environ 657,5 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 réside dans la fonction doSwapThroughOrionPool du contrat ExchangeWithAtomic. Cette fonction met à jour la variable curBalance après avoir exécuté le transfert de jetons, ce qui crée une opportunité de réentrance pour l'attaquant. L'attaquant, en ajoutant une logique de rappel dans la fonction transfer de Token personnalisé, appelle à plusieurs reprises la fonction depositAsset, ce qui entraîne une mise à jour incorrecte de curBalance.
L'attaquant a exploité cette vulnérabilité pour retirer des fonds excédentaires après avoir remboursé le prêt éclair.
Reproduction de l'attaque
Les chercheurs ont fourni une partie du code PoC, simulant le processus d'attaque. Le code comprend des étapes telles que la création d'un Token personnalisé, l'établissement d'une piscine de liquidités, l'autorisation des opérations et l'exécution de l'attaque. Les résultats des tests montrent que l'attaque a été reproduite avec succès, concordant avec les résultats de la pile d'appels de l'attaque réelle.
Conseils de sécurité
Dans la conception des contrats, il est nécessaire de prendre en compte les risques de sécurité potentiels liés à la diversité des tokens et des chemins d'échange.
Suivre le modèle de codage "Vérifications-Effects-Interactions" (Checks-Effects-Interactions), c'est-à-dire d'abord effectuer des vérifications de conditions, puis mettre à jour les variables d'état, et enfin interagir avec des contrats externes.
Soyez particulièrement prudent lors du traitement des appels externes, surtout lorsqu'il s'agit d'opérations de transfert de fonds.
Effectuer des audits de sécurité réguliers pour détecter et corriger rapidement les vulnérabilités potentielles.
Mettre en œuvre un contrôle d'accès raisonnable et un mécanisme de quota pour réduire les pertes potentielles causées par une attaque unique.
Cet événement rappelle une fois de plus aux équipes de développement de projets Web3 qu'il est impératif de prêter attention à la sécurité des contrats intelligents tout en recherchant l'innovation. Ce n'est qu'en construisant des infrastructures plus sûres et fiables que l'on pourra favoriser le développement sain de l'ensemble du secteur.
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
8
Reposter
Partager
Commentaire
0/400
ShadowStaker
· 07-08 21:29
un autre jour, une autre exploitation de defi... quand les développeurs apprendront-ils à vérifier la réentrance smh
Voir l'originalRépondre0
TokenTherapist
· 07-07 15:54
Un autre est tombé.
Voir l'originalRépondre0
GasWaster
· 07-06 14:26
Encore une fois, volé.
Voir l'originalRépondre0
SigmaBrain
· 07-05 22:13
C'est encore une attaque par réentrance, la défense est brisée.
Voir l'originalRépondre0
ponzi_poet
· 07-05 22:13
La sécurité ? Où est-elle allée ?
Voir l'originalRépondre0
GetRichLeek
· 07-05 22:13
Les premiers rangs mangent des pastèques. Ils ne réussissent même pas à auditer les contrats. C'est une grosse perte.
Voir l'originalRépondre0
BearMarketGardener
· 07-05 22:07
Le contrat a encore explosé, sigh.
Voir l'originalRépondre0
DaoGovernanceOfficer
· 07-05 22:00
*soupir* empiriquement parlant, 99 % de ces hacks proviennent d'erreurs de gestion d'état basiques...
Analyse approfondie de la perte de 2,9 millions de dollars d'OrionProtocol suite à une attaque par réentrance
Analyse de l'incident de réentrance 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. L'attaquant a volé environ 2,84 millions de USDT de la chaîne Ethereum et environ 190 000 BUSD de la Binance Smart Chain, pour une perte totale d'environ 2,9 millions de dollars.
Analyse du processus d'attaque
L'attaquant a d'abord déployé un contrat de Token personnalisé et a effectué une série de préparations. Ensuite, l'attaquant a emprunté des fonds via la fonction swap d'un certain DEX, en appelant la méthode ExchangeWithAtomic.swapThroughOrionPool d'OrionProtocol pour échanger des tokens. Le chemin d'échange comprenait l'adresse du contrat Token créé par l'attaquant.
Dans le processus d'échange, l'attaquant a exploité la fonction de rappel du contrat Token personnalisé en appelant à plusieurs reprises la méthode ExchangeWithAtomic.depositAsset, entraînant une accumulation multiple du montant déposé. Finalement, l'attaquant a réalisé des bénéfices en effectuant une opération de retrait.
Flux de fonds
Selon le suivi, les fonds initiaux des attaquants proviennent d'un portefeuille chaud d'une certaine plateforme d'échange. Parmi les 1651 ETH obtenus par l'attaque, environ 657,5 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 réside dans la fonction doSwapThroughOrionPool du contrat ExchangeWithAtomic. Cette fonction met à jour la variable curBalance après avoir exécuté le transfert de jetons, ce qui crée une opportunité de réentrance pour l'attaquant. L'attaquant, en ajoutant une logique de rappel dans la fonction transfer de Token personnalisé, appelle à plusieurs reprises la fonction depositAsset, ce qui entraîne une mise à jour incorrecte de curBalance.
L'attaquant a exploité cette vulnérabilité pour retirer des fonds excédentaires après avoir remboursé le prêt éclair.
Reproduction de l'attaque
Les chercheurs ont fourni une partie du code PoC, simulant le processus d'attaque. Le code comprend des étapes telles que la création d'un Token personnalisé, l'établissement d'une piscine de liquidités, l'autorisation des opérations et l'exécution de l'attaque. Les résultats des tests montrent que l'attaque a été reproduite avec succès, concordant avec les résultats de la pile d'appels de l'attaque réelle.
Conseils de sécurité
Dans la conception des contrats, il est nécessaire de prendre en compte les risques de sécurité potentiels liés à la diversité des tokens et des chemins d'échange.
Suivre le modèle de codage "Vérifications-Effects-Interactions" (Checks-Effects-Interactions), c'est-à-dire d'abord effectuer des vérifications de conditions, puis mettre à jour les variables d'état, et enfin interagir avec des contrats externes.
Soyez particulièrement prudent lors du traitement des appels externes, surtout lorsqu'il s'agit d'opérations de transfert de fonds.
Effectuer des audits de sécurité réguliers pour détecter et corriger rapidement les vulnérabilités potentielles.
Mettre en œuvre un contrôle d'accès raisonnable et un mécanisme de quota pour réduire les pertes potentielles causées par une attaque unique.
Cet événement rappelle une fois de plus aux équipes de développement de projets Web3 qu'il est impératif de prêter attention à la sécurité des contrats intelligents tout en recherchant l'innovation. Ce n'est qu'en construisant des infrastructures plus sûres et fiables que l'on pourra favoriser le développement sain de l'ensemble du secteur.