Analyse des attaques de ré-entrée d’OrionProtocol

Le 2 février 2023 à 15:40:20 UTC, Orion Protocol sur Ethereum et Binance Smart Chain a subi une attaque par réentrance en raison d'une vulnérabilité de contrat. L'attaquant a tiré un profit de 2 844 766 USDT du réseau Ethereum et de 191 606 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 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 comprend l'adresse du contrat Token créé par l'attaquant, ce qui prépare le terrain pour une attaque de rappel ultérieure.

Lors du processus d'échange, en raison de la logique de rappel intégrée dans le contrat Token de l'attaquant, chaque transfert déclenche un appel de réentrer à la méthode ExchangeWithAtomic.depositAsset. Cela entraîne une accumulation multiple du montant du dépôt, permettant finalement à l'attaquant de réaliser un profit excessif par le biais d'opérations de retrait.

Flux de fonds

Les fonds initiaux de l'attaquant proviennent du portefeuille chaud d'une certaine plateforme de trading. Après le succès de l'attaque, parmi les 1 651 ETH de profits, 657,5 ETH restent dans l'adresse du portefeuille de l'attaquant, tandis que le reste a é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, offrant ainsi aux attaquants la possibilité d'exploiter une attaque par réentrance. Les attaquants ajoutent une logique de rappel dans la fonction transfer de leur Token personnalisé, ce qui entraîne une mise à jour incorrecte de curBalance, leur permettant ainsi de retirer des fonds supplémentaires même après le remboursement du prêt flash.

Reproduction d'attaque

Les chercheurs ont fourni une partie du code POC, simulant le processus d'attaque. Les résultats des tests montrent que l'attaquant a réussi à exploiter la faille du contrat pour obtenir des USDT supplémentaires.

Conseils de sécurité

Concernant ce type d'attaque, il est conseillé aux équipes de projet :

1. Lors de la mise en œuvre de la fonction d'échange de jetons dans le contrat, il est nécessaire de prendre en compte les risques de sécurité potentiels liés aux différents types de jetons et aux chemins d'échange.
2. Suivre strictement le modèle de codage "Vérifications-Effects-Interactions" (Checks-Effects-Interactions), c'est-à-dire effectuer d'abord les vérifications de conditions, puis mettre à jour les variables d'état, et enfin exécuter les appels externes.
3. Utilisez un verrou de réentrance ou un mécanisme similaire pour empêcher les attaques par réentrance avant de mettre à jour les variables d'état critiques.
4. Effectuer régulièrement des audits de code et des tests de sécurité pour détecter et corriger rapidement les vulnérabilités potentielles.

Cet événement met à nouveau en évidence l'importance de la sécurité des contrats intelligents. Les équipes de projet doivent continuer à se concentrer sur les problèmes de sécurité et prendre des mesures de protection complètes pour garantir la sécurité des actifs des utilisateurs et le développement stable à long terme du projet.