Les risques de sécurité de THORChain (RUNE)

Selon le rapport de trésorerie de THORChain pour le premier trimestre 2022 publié le 1er avril, la chaîne a enregistré une croissance de ses revenus malgré le double impact de la morosité persistante du marché et de facteurs géopolitiques très instables. Les données publiques montrent que THORChain a enregistré un chiffre d’affaires de 2,17 milliards de dollars au premier trimestre 2022. THORChain, acclamé comme la « version inter-chaînes d’UniSwap », a pris pied sur le marché du commerce inter-chaînes en s’appuyant sur ses avantages uniques et a acquis une large reconnaissance auprès des investisseurs.

Derrière tous ces glamours, THORChain est également profondément troublé par le piratage. La chaîne a subi de fréquentes failles de sécurité depuis son lancement sur Ethereum, ce qui jette un doute sur sa sécurité. Le 11 avril, THORChain a tweeté sur les attaques de phishing, avertissant les utilisateurs de ne pas interagir avec [DeTHOR] ou d’autres jetons inconnus dans leurs portefeuilles, ce qui a une fois de plus soulevé des inquiétudes quant à ses problèmes de sécurité.

Tout en construisant un système de sécurité solide pour les produits CoinEx, l’équipe de sécurité CoinEx suit également les incidents de sécurité dans l’espace blockchain pour aider les utilisateurs à mieux comprendre la sécurité des différents projets du point de vue de la sécurité technique et à atténuer le risque d’investissement. Dans le but d’améliorer les critères de sécurité pour le secteur de la blockchain, l’équipe de sécurité de CoinEx a analysé les risques de sécurité de THORChain (RUNE). L’équipe espère que THORChain pourra noter et atténuer les risques suivants en optimisant les codes de contrat intelligents pertinents. De plus, cet article est également un avertissement pour les utilisateurs, leur rappelant d’être plus conscients de la sécurité des actifs et d’éviter les pertes d’actifs.

À quel point THORChain (RUNE) est-il sécurisé ?

Grâce à l’analyse du code de contrat et de la logique de THORChain (RUNE), l’équipe de sécurité de CoinEx a découvert les risques suivants :

Pour commencer, regardons le code de contrat de THORChain (RUNE):

https://etherscan.io/address/0x3155ba85d5f96b2d030a4966af206230e46849cb#code

Nous pouvons dire que RUNE est un jeton ERC-20 assez standard. A noter qu’en dehors de l’interface ERC-20, THORChain (RUNE) propose une interface supplémentaire :

Selon transferTo (comme illustré dans l’image ci-dessus), THORChain (RUNE) utilise tx.origin, qui est l’une des causes de ses risques de sécurité. Ici, nous devrions expliquer la différence entre tx.origin et msg.sender :

L’image ci-dessous décrit ce qui se passe lorsqu’une adresse normale appelle le contrat intelligent :

Dans de tels cas, msg.sender = account.address et tx.origin = account.address, ce qui signifie que msg.sender est identique à tx.origin.

Voici ce qui se passe lorsqu’un compte appelle le contrat A et que le contrat A appelle le contrat B :

Lorsque le contrat A appelle le contrat B (comme indiqué ci-dessus), nous pouvons dire que msg.sender est égal à tx.origin dans le contrat A.

Cependant, dans le contrat B, msg.sender = contractA.address, tandis que tx.origin = account.address. Par conséquent, tx.origin est comme une variable globale qui traverse toute la pile d’appels et renvoie l’adresse du compte qui a initialement envoyé la transaction. C’est le problème clé : à ce jour, presque toutes les attaques connues contre THORChain (RUNE) concernent tx.origin.

Découvrons maintenant comment les attaquants volent les jetons RUNE des utilisateurs via tx.origin :

Attaque n°1 : pillez une chèvre dans un troupeau

Les adresses sur Ethereum sont divisées en adresses externes et adresses contractuelles. Le transfert d’ETH vers ces deux types d’adresses via des adresses externes est fondamentalement différent. Le Documents officiels de solidité stipule qu’une adresse de contrat doit implémenter une fonction de réception Ether avant d’effectuer des transferts.

À la lumière des fonctionnalités de tx.origin, les pirates peuvent construire un contrat d’attaque :

Lorsque le contrat d’attaque reçoit un transfert ETH d’un utilisateur, il « volera une chèvre d’un troupeau » – le contrat volera les jetons RUNE de l’utilisateur dans le processus.

Attaque No.2 : Attaque Interne

Une attaque interne est un type spécial d’attaque. Lorsqu’il tente de voler la RUNE d’un utilisateur par le biais d’une attaque interne, le pirate doit disposer d’un jeton moyen. De plus, le jeton doit également appeler des contrats tiers. Selon les enregistrements de transfert de RUNE sur Ethereum, certains attaquants ont piraté RUNE via des transferts de jetons AMP.

AMP Token utilise la norme ERC-1820 pour gérer l’enregistrement de Hook et examiner si Hook est enregistré à chaque transfert. Si Hook a été enregistré, alors le Hook sera appelé.

Le code de contrat de AMP Token montre que la mise en œuvre finale du transfert est : _transferByPartition. Pendant ce temps, il y a deux appels impliquant transferHook : _callPreTransferHooks (avant le transfert) et _callPostTransferHooks (après le transfert). En particulier, _callPreTransferHooks est pour l’adresse de départ, tandis que _callPostTransferHooks est pour l’adresse de destination (c’est-à-dire l’adresse de réception).

Pour les utilisateurs réguliers, voler des jetons à eux-mêmes est inutile. Par conséquent, les attaquants peuvent exploiter _callPostTransferHooks. Voyons maintenant les codes de _callPostTransferHooks.

IAMPTokensRecipient(recipientImplementation).tokensReceived()

Nous pouvons dire que le seul rappel que les attaquants pourraient exploiter est IAMPTokensRecipient(recipientImplementation).tokensReceived()

Ensuite, nous illustrerons comment cet appel peut être utilisé pour transférer la RUNE d’un utilisateur tout en effectuant un transfert de jeton AMP.

Étape 1: Un contrat d’appel est nécessaire (comme indiqué ci-dessous):

Étape 2: Déployez le contrat pour obtenir l’adresse d’attaque.

Étape 3: Appelez l’interface de contrat ERC-1820 (setInterfaceImplementer) pour enregistrer l’interface.

Adresse ERC-1820 : 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24

Interface contrat : setInterfaceImplementer (adresse toAddr, bytes32 interfaceHash, implémenteur d’adresse)

En particulier, toAddr est l’adresse de réception du transfert AMP,

interfaceHash »AmpTokensRecipient »hash :

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

interfaceHash est le hachage de AmpTokensRecipient :

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

L’implémenteur est l’adresse d’attaque obtenue à l’étape 2.

Étape 4: Attirez un utilisateur pour qu’il transfère l’AMP vers le toAddr pour déclencher un rappel, et volez sa RUNE en même temps.

Attaque n°3 : attaque de phishing

Comme son nom l’indique, dans une attaque de phishing, l’attaquant promet de donner des avantages incroyables pour inciter les utilisateurs à effectuer certaines opérations contractuelles. Ici, nous allons présenter une attaque de phishing courante.

Étape 1: L’attaquant émet un jeton ERC-20 et peut l’écrire dans n’importe quelle interface de contrat impliquant des signatures.

Étape 2: Créez une paire de trading sur Uniswap ou tout autre swap ;

Étape 3: Offrir des parachutages à tous les utilisateurs/adresses qui détiennent des jetons RUNE ;

Le travail initial de l’attaque de phishing est essentiellement complété par les étapes ci-dessus. Ensuite, l’attaquant n’a qu’à attendre que les utilisateurs échangent sur un swap, et les utilisateurs risquent de perdre leur RUNE une fois qu’ils ont effectué des opérations telles que l’approbation, le transfert, etc.

De plus, afin de vérifier davantage le risque de sécurité du code de contrat THORChain, CoinEx a discuté avec l’équipe de sécurité de SlowMist et PeckShield, deux agences de sécurité bien connues dans l’industrie. Confirmé par SlowMist et PeckShield, le risque de sécurité mentionné ci-dessus existe bel et bien.

Jusqu’à présent, nous avons couvert plusieurs types d’attaques, ainsi que les risques de sécurité auxquels les utilisateurs sont exposés.

Comment l’équipe projet doit-elle optimiser le code du contrat pour se sécuriser et protéger les actifs des utilisateurs ?

La seule réponse est d’être prudent quant à l’utilisation de tx.origin.

Comment les utilisateurs réguliers peuvent-ils atténuer les risques et protéger leurs actifs face à des attaques qui semblent inévitables ? L’équipe de sécurité de CoinEx propose les suggestions suivantes :

1. Pour l’attaque n°1 : lors d’un transfert, gardez une trace de la consommation de gaz estimée. Pour un transfert ETH régulier, des frais de gaz de 21 000 sont plus que suffisants. Soyez prudent si la consommation de gaz dépasse de loin ce chiffre.
2. Pour l’attaque n°2 : isolez vos jetons en adoptant différents portefeuilles. Vous pouvez stocker différents jetons à différentes adresses. Une prudence supplémentaire est nécessaire en ce qui concerne l’adresse de portefeuille chaud offerte par les échanges.
3. Pour l’attaque n°3 : la cupidité est la source de tous les maux. Ne participez pas aveuglément à un événement de parachutage.

La sécurité a toujours été une préoccupation majeure dans le secteur de la blockchain. Tous les acteurs, y compris les équipes de projet et les échanges, doivent donner la priorité à la sécurité pendant le fonctionnement du projet, assurer la sécurité des actifs des utilisateurs et promouvoir conjointement la croissance saine de l’industrie de la blockchain.