SharkTeam : analyse du principe d'attaque de proposition Tornado.Cash

La raison de cet incident était que la communauté n'a pas découvert les risques de la proposition lors de la vérification de la proposition et n'a pas soigneusement vérifié si le code du contrat de proposition présentait des failles de sécurité.

Écrit par : SharkTeam

Le 20 mai 2023, heure de Pékin, Tornado.Cash a subi une attaque par proposition, et l'attaquant a réalisé un bénéfice d'environ 680 000 dollars américains. SharkTeam a effectué une analyse technique de cet incident pour la première fois et a résumé les précautions de sécurité, en espérant que les projets ultérieurs pourront en tirer des leçons et construire une ligne de défense de sécurité pour l'industrie de la blockchain.

1. Analyse des événements

Adresse de l'attaquant :

0x092123663804f8801b9b086b03B98D706f77bD59

0x592340957eBC9e4Afb0E9Af221d06fDDDF789de9

Contrat d'attaque :

0xAF54612427d97489707332efe0b6290F129DbAcb

0x03ecf0d22f9ccd21144a7d492cf63b471916497a

0x7dc86183274b28e9f1a100a0152dac975361353d (contrat de déploiement)

0xc503893b3e3c0c6b909222b45f2a3a259a52752d (contrat de proposition fictive)

Contrat attaqué :

0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce

Initier une transaction de proposition :

0x34605f1d6463a48b818157f7b26d040f8dd329273702a0618e9e74fe350e6e0d

Transactions d'attaque :

0x3274b6090685b842aca80b304a4dcee0f61ef8b6afee10b7c7533c32fb75486d

Processus d'attaque :

(1) Tout d'abord, l'attaquant (0x08e80ecb) lance une proposition au contrat attaqué (0x5efda50f), affirmant que cette proposition est un complément à la proposition 16

(2) Mais il y a en fait une fonction d'autodestruction supplémentaire dans la proposition.

(3) Malheureusement, la communauté n'a trouvé aucun problème dans cette proposition, et la plupart des membres ont voté pour l'adopter.

(4) L'attaquant a créé de nombreux contrats pour mettre en œuvre le transfert de jetons

(5) L'attaquant (0x08e80ecb) détruit le contrat de proposition (0xc503893b) et son contrat de création (0x7dc86183). Le contrat d'attaque (0xc503893b) a ensuite été redéployé à la même adresse.

(6) Après avoir modifié le contrat de proposition, l'attaquant (0x08e80ecb) exécute la proposition et modifie le montant du verrouillage du jeton de l'adresse du contrat sous son contrôle à 10000.

(7) Une fois la proposition exécutée, l'attaquant (0x08e80ecb) transfère les jetons à sa propre adresse et obtient la propriété du contrat attaqué.

Analyse de vulnérabilité : étant donné que le contrat de création (0x7dc86183) du contrat de proposition (0xc503893b) est déployé via creat2, après la destruction des deux contrats, un nouveau contrat logique peut être déployé sur la même adresse, et l'exécution de la proposition est invoquée sous la forme Le contrat attaquant peut modifier arbitrairement la valeur dans le contrat attaqué.

Résumé de l'incident : La raison de cet incident était que la communauté n'a pas découvert les risques de la proposition lors de la vérification de la proposition et n'a pas soigneusement vérifié si le code du contrat de proposition présentait des failles de sécurité.

2. Recommandations de sécurité

En réponse à cette attaque, nous devons suivre les précautions suivantes pendant le processus de développement :

  • Lors de la conception des propositions, tenez pleinement compte de la sécurité du mécanisme de proposition et minimisez le risque que les propositions soient contrôlées de manière centralisée. Envisagez de réduire la valeur des attaques, d'augmenter le coût d'obtention des droits de vote et d'augmenter le coût d'exécution des attaques, etc.
  • Avant de voter sur la proposition, la communauté doit soigneusement vérifier si le code du contrat a une porte dérobée.
  • Avant l'approbation de la proposition, une société d'audit de sécurité tierce peut être contactée pour effectuer un audit de sécurité du code logique du contrat.
Voir l'original
  • Récompense
  • Commentaire
  • Partager
Commentaire
Aucun commentaire
  • Rubrique