Analyse de l'incident d'attaque par réentrance d'OrionProtocol
Le 2 février 2023 à 15h40:20 (heure UTC), Orion Protocol sur Ethereum et Binance Smart Chain a subi une attaque par réinjection en raison d'une vulnérabilité de contrat. L'attaquant a réussi à voler environ 2,9 millions de dollars de fonds, 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 effectué les opérations de transfert et d'autorisation nécessaires pour préparer l'attaque suivante. 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 tokens.
Le chemin d'échange est défini sur [USDC, Token de l'attaquant, USDT], où le Token de l'attaquant est clé. Au cours du processus d'échange, en raison de la fonctionnalité de rappel incluse dans ce contrat de Token personnalisé, l'attaquant est capable de déclencher la méthode ExchangeWithAtomic.depositAsset lors du transfert de Token, permettant ainsi une attaque par réentrance. Cela entraîne une accumulation incorrecte du montant déposé, et finalement, l'attaquant réalise un profit en effectuant une opération de retrait.
Flux de fonds
Les fonds initiaux de l'attaquant proviennent d'un portefeuille chaud d'une plateforme d'échange. Parmi les 1 651 ETH obtenus lors 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 mélange.
Analyse des vulnérabilités
Le cœur de la vulnérabilité réside dans les fonctions doSwapThroughOrionPool et _doSwapTokens du contrat ExchangeWithAtomic. Ces fonctions mettent à jour la variable curBalance uniquement après l'exécution du transfert de jetons, créant ainsi des conditions propices à une attaque par réentrance. L'attaquant a réussi à déclencher la fonction depositAsset en ajoutant une logique de rappel dans la fonction transfer de son Token personnalisé, ce qui a entraîné une mise à jour incorrecte de curBalance. En fin de compte, après avoir remboursé le prêt éclair, l'attaquant a retiré des fonds excédentaires via la fonction withdraw.
Conseils de prévention
Suivre le modèle "Vérifications - Effets - Interactions" (Checks-Effects-Interactions) : mettre à jour l'état du contrat avant d'effectuer des appels externes.
Utiliser un verrou de réentrance : verrouiller avant le début des opérations sensibles et déverrouiller après, pour empêcher la réentrance.
Prendre en compte tous les types de jetons et les chemins d'échange : Lors de la conception de la fonction d'échange, il est nécessaire de prendre en compte toutes les situations possibles et les conditions limites.
Limiter le montant de la transaction unique : définir des limites de transaction raisonnables pour réduire les pertes potentielles.
Effectuer des audits de sécurité réguliers : engager une équipe de sécurité professionnelle pour réaliser un audit complet des contrats, afin de détecter et de corriger rapidement les vulnérabilités potentielles.
Mettre en œuvre un mécanisme de signature multiple : les opérations clés nécessitent une confirmation de plusieurs parties, augmentant ainsi la difficulté d'attaque.
Optimiser la logique du code : s'assurer que les appels externes ne sont effectués qu'après la mise à jour des variables d'état clés.
Renforcer le mécanisme de réponse d'urgence : élaborer un plan d'urgence complet pour réagir rapidement en cas d'attaque et minimiser les pertes.
Cet événement souligne à nouveau l'importance de la sécurité des contrats intelligents. Les équipes de projets doivent rester vigilantes tout au long du processus de développement et prendre des mesures de sécurité complètes pour protéger les actifs des utilisateurs et la réputation du projet. En même temps, cela rappelle aux investisseurs d'être prudents dans le choix des projets et de prêter attention à la sécurité et à la solidité technologique des projets.
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.
6 J'aime
Récompense
6
5
Partager
Commentaire
0/400
ZenMiner
· Il y a 19h
La sécurité des contrats dépend également de l'audit.
Voir l'originalRépondre0
DAOplomacy
· Il y a 19h
encore un échec de gouvernance sous-optimal smh...
Voir l'originalRépondre0
GweiTooHigh
· Il y a 19h
Un autre qui coupe les poireaux
Voir l'originalRépondre0
DeFiAlchemist
· Il y a 19h
*ajuste ses lunettes éthérées* une autre âme tombe dans les arts sombres de la réentrée... les barrières mystiques du protocole étaient trop faibles
OrionProtocol a subi une attaque par réentrance, 2,9 millions de dollars de fonds ont été volés.
Analyse de l'incident d'attaque par réentrance d'OrionProtocol
Le 2 février 2023 à 15h40:20 (heure UTC), Orion Protocol sur Ethereum et Binance Smart Chain a subi une attaque par réinjection en raison d'une vulnérabilité de contrat. L'attaquant a réussi à voler environ 2,9 millions de dollars de fonds, 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 effectué les opérations de transfert et d'autorisation nécessaires pour préparer l'attaque suivante. 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 tokens.
Le chemin d'échange est défini sur [USDC, Token de l'attaquant, USDT], où le Token de l'attaquant est clé. Au cours du processus d'échange, en raison de la fonctionnalité de rappel incluse dans ce contrat de Token personnalisé, l'attaquant est capable de déclencher la méthode ExchangeWithAtomic.depositAsset lors du transfert de Token, permettant ainsi une attaque par réentrance. Cela entraîne une accumulation incorrecte du montant déposé, et finalement, l'attaquant réalise un profit en effectuant une opération de retrait.
Flux de fonds
Les fonds initiaux de l'attaquant proviennent d'un portefeuille chaud d'une plateforme d'échange. Parmi les 1 651 ETH obtenus lors 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 mélange.
Analyse des vulnérabilités
Le cœur de la vulnérabilité réside dans les fonctions doSwapThroughOrionPool et _doSwapTokens du contrat ExchangeWithAtomic. Ces fonctions mettent à jour la variable curBalance uniquement après l'exécution du transfert de jetons, créant ainsi des conditions propices à une attaque par réentrance. L'attaquant a réussi à déclencher la fonction depositAsset en ajoutant une logique de rappel dans la fonction transfer de son Token personnalisé, ce qui a entraîné une mise à jour incorrecte de curBalance. En fin de compte, après avoir remboursé le prêt éclair, l'attaquant a retiré des fonds excédentaires via la fonction withdraw.
Conseils de prévention
Suivre le modèle "Vérifications - Effets - Interactions" (Checks-Effects-Interactions) : mettre à jour l'état du contrat avant d'effectuer des appels externes.
Utiliser un verrou de réentrance : verrouiller avant le début des opérations sensibles et déverrouiller après, pour empêcher la réentrance.
Prendre en compte tous les types de jetons et les chemins d'échange : Lors de la conception de la fonction d'échange, il est nécessaire de prendre en compte toutes les situations possibles et les conditions limites.
Limiter le montant de la transaction unique : définir des limites de transaction raisonnables pour réduire les pertes potentielles.
Effectuer des audits de sécurité réguliers : engager une équipe de sécurité professionnelle pour réaliser un audit complet des contrats, afin de détecter et de corriger rapidement les vulnérabilités potentielles.
Mettre en œuvre un mécanisme de signature multiple : les opérations clés nécessitent une confirmation de plusieurs parties, augmentant ainsi la difficulté d'attaque.
Optimiser la logique du code : s'assurer que les appels externes ne sont effectués qu'après la mise à jour des variables d'état clés.
Renforcer le mécanisme de réponse d'urgence : élaborer un plan d'urgence complet pour réagir rapidement en cas d'attaque et minimiser les pertes.
Cet événement souligne à nouveau l'importance de la sécurité des contrats intelligents. Les équipes de projets doivent rester vigilantes tout au long du processus de développement et prendre des mesures de sécurité complètes pour protéger les actifs des utilisateurs et la réputation du projet. En même temps, cela rappelle aux investisseurs d'être prudents dans le choix des projets et de prêter attention à la sécurité et à la solidité technologique des projets.