Multichain : Guerre de vulnérabilité entre attaque et défense : Sauvetage par des hackers éthiques et enseignements sur la sécurité de l'écosystème Web3
Analyse des vulnérabilités des projets Multichain : la sécurité de l'écosystème Web3 à travers les interventions d'urgence
Le 18 janvier 2022, notre système de surveillance des transactions anormales a détecté une attaque contre le projet Multichain. En raison d'une mauvaise mise en œuvre du mécanisme de vérification dans les fonctions concernées, les tokens autorisés par les utilisateurs pour ce projet pouvaient être retirés par des attaquants.
Bien que l'équipe du projet ait essayé de rappeler aux utilisateurs affectés de diverses manières, de nombreux utilisateurs n'ont pas pu répondre à temps, permettant aux attaquants de continuer à mener des attaques et à en profiter.
Étant donné que l'attaque se poursuit, afin de protéger les victimes potentielles, nous avons décidé de prendre des mesures d'intervention d'urgence. Cette opération de sauvetage concerne les comptes affectés sur Ethereum, et nous transférerons les fonds des comptes concernés vers un compte multi-signatures dédié aux "white hats". Afin d'assurer la transparence de l'opération, nous publierons la valeur de hachage des documents relatifs au plan ( plutôt que leur contenu ) à la communauté. Notre opération de sauvetage a commencé le 21 janvier 2022 et s'est terminée le 11 mars 2022.
Les interventions d'urgence font face à de nombreux défis techniques et non techniques. Maintenant que l'action est terminée, nous pouvons revoir l'ensemble du processus et partager nos réflexions avec la communauté. Nous espérons que ce partage sera utile à la sécurité de la communauté et de l'écosystème DeFi.
Résumé
Une concurrence féroce s'est développée entre les différents participants concernant l'utilisation généralisée de Flashbots, incluant les groupes de hackers éthiques et d'attaquants, et les frais payés à Flashbots ont également rapidement augmenté au fil du temps.
Flashbots ne sont pas toujours efficaces. Certains attaquants se tournent vers le mempool, utilisant des stratégies astucieuses pour organiser des transactions d'attaque et réussir à mener à bien leurs attaques.
Certains attaquants ont conclu un accord avec l'équipe du projet pour restituer une partie des gains obtenus lors de l'attaque, en conservant une partie comme récompense, réussissant ainsi à "blanchir" leur image. Ce phénomène a suscité des débats et des discussions au sein de la communauté sur l'équité des incitations.
D'un point de vue de la transparence, les white hats peuvent annoncer leurs actions à la communauté sans divulguer d'informations sensibles, cette méthode de gagner la confiance de la communauté fonctionne bien en pratique.
Les différentes forces de la communauté peuvent collaborer pour rendre les actions de secours plus rapides et efficaces. Par exemple, une collaboration peut être mise en place entre les hackers éthiques pour réduire ou éviter la concurrence inefficace.
Aperçu des situations d'attaque et de sauvetage
Résultat global
Dans la portée de notre observation (, du 18 janvier 2022 au 20 mars 2022 ), la situation générale des attaques et des secours est la suivante :
9 comptes de secours ont protégé 483.027693 ETH, dont 295.970554 ETH ont été payés en frais à Flashbots, représentant 61.27%(.
21 comptes attaquants ont réalisé un profit de 1433.092224 ETH, dont les frais payés à Flashbots s'élèvent à 148.903707 ETH) représentant 10.39%(
Il convient de noter que, en raison de certaines situations d'interaction complexes ), telles que le remboursement de certains bénéfices par des attaquants après avoir négocié avec l'équipe du projet, les étiquettes d'adresse concernées peuvent changer (. Les données ci-dessus ne sont qu'une estimation.
Les white hats doivent rivaliser avec les attaquants pour envoyer des transactions Flashbots afin de mettre en œuvre le sauvetage, et les tendances des frais payés à Flashbots peuvent refléter le niveau de concurrence. Nous avons statistiqué la part des frais Flashbots pour les transactions d'attaque et de sauvetage par bloc de transaction.
L'analyse montre que les frais de Flashbots pour les transactions d'attaque précoces étaient de 0, ce qui indique que les attaquants n'avaient pas encore utilisé Flashbots à ce moment-là. Par la suite, la part des frais de Flashbots a rapidement augmenté, atteignant même 80 % à 91 % dans certains blocs. Cette tendance reflète une course aux armements des frais due à la lutte pour le droit d'entrée sur la chaîne de Flashbots.
Les actions de sauvetage que nous mettons en œuvre et les défis auxquels nous faisons face
) La pensée de base de l'opération de sauvetage
Notre approche de sauvetage consiste à surveiller un certain nombre de comptes potentiellement victimes, qui ont autorisé des WETH à des contrats de projet problématiques. Lorsque des WETH sont transférés sur ce compte, nous exploitons une vulnérabilité du contrat pour les transférer vers un portefeuille multisignature de white hat. L'essentiel est de répondre aux exigences suivantes :
Localiser efficacement le transfert vers le compte de la victime pour la transaction ### de transfert (
Construire correctement la transaction pour sauver ) sauver la transaction (
Attaquant ayant réussi une attaque de frontrunning ) ou d'autres tiers ( transactions ) attaque transaction (
Les deux premières exigences ne constituent pas un obstacle pour nous. Cependant, la troisième reste un défi, même l'utilisation de Flashbots ne garantit pas toujours le succès. Nous devons également prendre en compte des facteurs tels que la stratégie de tarification, la position et l'ordre des transactions dans le mempool.
Nous avons tenté de protéger 171 comptes de victimes potentielles indépendants. Parmi eux, 10 ont révoqué leur autorisation à temps pour assurer leur protection. Parmi les 161 comptes restants, en raison de la concurrence de divers types, nous n'avons réussi à en sauver que 14. Les échecs concernent 3 comptes de sauvetage et 16 comptes d'attaque.
Au cours du processus de sauvetage, nous avons d'abord été battus par 12 concurrents utilisant Flashbots, y compris 2 comptes de sauvetage et 10 comptes d'attaque.
Notre stratégie de tarification des frais Flashbots est plutôt conservatrice, visant à minimiser autant que possible les frais pour protéger les intérêts des victimes. Cependant, la pratique a prouvé que cette stratégie n'est pas très fructueuse, car les attaquants ### et même certains white hats ( adoptent généralement des stratégies plus agressives pour fixer les frais afin de gagner la compétition.
Nous avons observé certains cas montrant que les concurrents fixent le pourcentage des frais Flashbots entre 70 et 86 %. Cela semble être un jeu à somme nulle, nécessitant un modélisation pour explorer les comportements des différentes parties prenantes. En pratique, réduire les coûts au maximum tout en trouvant une stratégie optimale pour gagner la compétition est une tâche difficile.
) Stratégies de planification des transactions Mempool
En raison de la concurrence intense provoquée par plusieurs parties, Flashbots n'est pas toujours efficace. Dans ce cas, même en fixant les frais Flashbots les plus élevés, il n'est pas garanti de remporter la compétition.
Une autre méthode viable consiste à envoyer des transactions ordinaires via le mempool. Si la transaction est placée au bon endroit ###, c'est-à-dire juste après la transaction de transfert (, elle pourrait également atteindre son objectif. Nous avons observé qu'un attaquant a réussi à tirer profit de cette stratégie, gagnant 312 ETH, sans payer de frais Flashbots.
Cette stratégie astucieuse allie praticité et inspiration, elle mérite d'être suivie et apprise.
) Définition des hackers éthiques et des attaquants
Identifier les white hats et leurs comportements peut ne pas être simple et direct. Nous avons observé un cas où une adresse a d'abord été marquée comme attaquant, puis a été reclassée comme white hat. Cela provient d'un accord conclu entre cette adresse et l'équipe du projet, acceptant de conserver une partie des bénéfices comme récompense et de restituer les autres bénéfices.
Ce phénomène n'est pas apparu pour la première fois, et l'équité des incitations a suscité de vives controverses et discussions au sein de la communauté.
Mécanisme de coordination entre les chapeaux blancs
Il est nécessaire d'établir un mécanisme de communication et de coordination au sein de la communauté pour réduire/éviter la compétition entre les white hats. Cette compétition non seulement gaspille les ressources de secours, mais augmente également le coût des opérations de sauvetage. Par exemple, lors de cette opération de sauvetage, nous et trois autres organisations de white hats ### avons simultanément essayé de protéger 54 victimes ( impliquant une perte de 450 ETH ).
Sans un mécanisme de coordination approprié, il est difficile pour les hackers éthiques d'abandonner ou d'arrêter une telle compétition.
( Suggestions pour améliorer les actions de secours
Les white hats peuvent annoncer leurs actions à la communauté sans divulguer d'informations sensibles, afin de gagner la confiance de la communauté.
Les différentes forces de la communauté peuvent collaborer pour rendre les secours plus rapides et efficaces :
Flashbots/Les mineurs peuvent fournir un accès privilégié aux white hats certifiés.
Les projets attaqués supportent le coût des frais Flashbots
L'équipe du projet adopte un mécanisme plus pratique pour alerter les utilisateurs en temps voulu.
L'équipe du projet a pris les mesures d'urgence nécessaires dans le code.
Grâce à la collaboration de toutes les parties, nous espérons construire un écosystème Web3 plus sûr et plus efficace.
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.
10 J'aime
Récompense
10
6
Partager
Commentaire
0/400
BuyHighSellLow
· Il y a 22h
Encore une perte, le chapeau blanc ne peut pas gérer ça.
Voir l'originalRépondre0
gas_fee_therapist
· Il y a 22h
Cette vague de gas semble folle...
Voir l'originalRépondre0
P2ENotWorking
· Il y a 22h
Je pensais que c'était fini, mais je ne savais pas que le chapeau blanc pouvait le récupérer.
Voir l'originalRépondre0
Degentleman
· Il y a 22h
Encore un problème avec le mécanisme de vérification ?
Voir l'originalRépondre0
PretendingSerious
· Il y a 22h
C'est un peu fou, les fonds ont été volés et ils se battent encore pour ça.
Voir l'originalRépondre0
GateUser-26d7f434
· Il y a 22h
Les chapeaux blancs et les hackers se disputent pour jouer, n'est-ce pas ?
Multichain : Guerre de vulnérabilité entre attaque et défense : Sauvetage par des hackers éthiques et enseignements sur la sécurité de l'écosystème Web3
Analyse des vulnérabilités des projets Multichain : la sécurité de l'écosystème Web3 à travers les interventions d'urgence
Le 18 janvier 2022, notre système de surveillance des transactions anormales a détecté une attaque contre le projet Multichain. En raison d'une mauvaise mise en œuvre du mécanisme de vérification dans les fonctions concernées, les tokens autorisés par les utilisateurs pour ce projet pouvaient être retirés par des attaquants.
Bien que l'équipe du projet ait essayé de rappeler aux utilisateurs affectés de diverses manières, de nombreux utilisateurs n'ont pas pu répondre à temps, permettant aux attaquants de continuer à mener des attaques et à en profiter.
Étant donné que l'attaque se poursuit, afin de protéger les victimes potentielles, nous avons décidé de prendre des mesures d'intervention d'urgence. Cette opération de sauvetage concerne les comptes affectés sur Ethereum, et nous transférerons les fonds des comptes concernés vers un compte multi-signatures dédié aux "white hats". Afin d'assurer la transparence de l'opération, nous publierons la valeur de hachage des documents relatifs au plan ( plutôt que leur contenu ) à la communauté. Notre opération de sauvetage a commencé le 21 janvier 2022 et s'est terminée le 11 mars 2022.
Les interventions d'urgence font face à de nombreux défis techniques et non techniques. Maintenant que l'action est terminée, nous pouvons revoir l'ensemble du processus et partager nos réflexions avec la communauté. Nous espérons que ce partage sera utile à la sécurité de la communauté et de l'écosystème DeFi.
Résumé
Une concurrence féroce s'est développée entre les différents participants concernant l'utilisation généralisée de Flashbots, incluant les groupes de hackers éthiques et d'attaquants, et les frais payés à Flashbots ont également rapidement augmenté au fil du temps.
Flashbots ne sont pas toujours efficaces. Certains attaquants se tournent vers le mempool, utilisant des stratégies astucieuses pour organiser des transactions d'attaque et réussir à mener à bien leurs attaques.
Certains attaquants ont conclu un accord avec l'équipe du projet pour restituer une partie des gains obtenus lors de l'attaque, en conservant une partie comme récompense, réussissant ainsi à "blanchir" leur image. Ce phénomène a suscité des débats et des discussions au sein de la communauté sur l'équité des incitations.
D'un point de vue de la transparence, les white hats peuvent annoncer leurs actions à la communauté sans divulguer d'informations sensibles, cette méthode de gagner la confiance de la communauté fonctionne bien en pratique.
Les différentes forces de la communauté peuvent collaborer pour rendre les actions de secours plus rapides et efficaces. Par exemple, une collaboration peut être mise en place entre les hackers éthiques pour réduire ou éviter la concurrence inefficace.
Aperçu des situations d'attaque et de sauvetage
Résultat global
Dans la portée de notre observation (, du 18 janvier 2022 au 20 mars 2022 ), la situation générale des attaques et des secours est la suivante :
Il convient de noter que, en raison de certaines situations d'interaction complexes ), telles que le remboursement de certains bénéfices par des attaquants après avoir négocié avec l'équipe du projet, les étiquettes d'adresse concernées peuvent changer (. Les données ci-dessus ne sont qu'une estimation.
![])https://img-cdn.gateio.im/webp-social/moments-502b402f7119932988948ba461367a19.webp(
) Tendance des frais Flashbots
Les white hats doivent rivaliser avec les attaquants pour envoyer des transactions Flashbots afin de mettre en œuvre le sauvetage, et les tendances des frais payés à Flashbots peuvent refléter le niveau de concurrence. Nous avons statistiqué la part des frais Flashbots pour les transactions d'attaque et de sauvetage par bloc de transaction.
L'analyse montre que les frais de Flashbots pour les transactions d'attaque précoces étaient de 0, ce qui indique que les attaquants n'avaient pas encore utilisé Flashbots à ce moment-là. Par la suite, la part des frais de Flashbots a rapidement augmenté, atteignant même 80 % à 91 % dans certains blocs. Cette tendance reflète une course aux armements des frais due à la lutte pour le droit d'entrée sur la chaîne de Flashbots.
![]###https://img-cdn.gateio.im/webp-social/moments-30d2c3346816e15ab7c89a6a25d0ad83.webp(
Les actions de sauvetage que nous mettons en œuvre et les défis auxquels nous faisons face
) La pensée de base de l'opération de sauvetage
Notre approche de sauvetage consiste à surveiller un certain nombre de comptes potentiellement victimes, qui ont autorisé des WETH à des contrats de projet problématiques. Lorsque des WETH sont transférés sur ce compte, nous exploitons une vulnérabilité du contrat pour les transférer vers un portefeuille multisignature de white hat. L'essentiel est de répondre aux exigences suivantes :
Les deux premières exigences ne constituent pas un obstacle pour nous. Cependant, la troisième reste un défi, même l'utilisation de Flashbots ne garantit pas toujours le succès. Nous devons également prendre en compte des facteurs tels que la stratégie de tarification, la position et l'ordre des transactions dans le mempool.
![])https://img-cdn.gateio.im/webp-social/moments-d22626977feebe325b02c899454022c7.webp(
) Situation concurrentielle
Nous avons tenté de protéger 171 comptes de victimes potentielles indépendants. Parmi eux, 10 ont révoqué leur autorisation à temps pour assurer leur protection. Parmi les 161 comptes restants, en raison de la concurrence de divers types, nous n'avons réussi à en sauver que 14. Les échecs concernent 3 comptes de sauvetage et 16 comptes d'attaque.
![]###https://img-cdn.gateio.im/webp-social/moments-3a365a505b5c5ac87a42a6d277af23ff.webp(
Leçons apprises
) Stratégie de réglage des frais Flashbots
Au cours du processus de sauvetage, nous avons d'abord été battus par 12 concurrents utilisant Flashbots, y compris 2 comptes de sauvetage et 10 comptes d'attaque.
Notre stratégie de tarification des frais Flashbots est plutôt conservatrice, visant à minimiser autant que possible les frais pour protéger les intérêts des victimes. Cependant, la pratique a prouvé que cette stratégie n'est pas très fructueuse, car les attaquants ### et même certains white hats ( adoptent généralement des stratégies plus agressives pour fixer les frais afin de gagner la compétition.
Nous avons observé certains cas montrant que les concurrents fixent le pourcentage des frais Flashbots entre 70 et 86 %. Cela semble être un jeu à somme nulle, nécessitant un modélisation pour explorer les comportements des différentes parties prenantes. En pratique, réduire les coûts au maximum tout en trouvant une stratégie optimale pour gagner la compétition est une tâche difficile.
![])https://img-cdn.gateio.im/webp-social/moments-cb547989448abc96498684cb89da8860.webp(
) Stratégies de planification des transactions Mempool
En raison de la concurrence intense provoquée par plusieurs parties, Flashbots n'est pas toujours efficace. Dans ce cas, même en fixant les frais Flashbots les plus élevés, il n'est pas garanti de remporter la compétition.
Une autre méthode viable consiste à envoyer des transactions ordinaires via le mempool. Si la transaction est placée au bon endroit ###, c'est-à-dire juste après la transaction de transfert (, elle pourrait également atteindre son objectif. Nous avons observé qu'un attaquant a réussi à tirer profit de cette stratégie, gagnant 312 ETH, sans payer de frais Flashbots.
Cette stratégie astucieuse allie praticité et inspiration, elle mérite d'être suivie et apprise.
![])https://img-cdn.gateio.im/webp-social/moments-adbfab235ed4a4c2a3ef7a58915c4deb.webp(
Autres réflexions
) Définition des hackers éthiques et des attaquants
Identifier les white hats et leurs comportements peut ne pas être simple et direct. Nous avons observé un cas où une adresse a d'abord été marquée comme attaquant, puis a été reclassée comme white hat. Cela provient d'un accord conclu entre cette adresse et l'équipe du projet, acceptant de conserver une partie des bénéfices comme récompense et de restituer les autres bénéfices.
Ce phénomène n'est pas apparu pour la première fois, et l'équité des incitations a suscité de vives controverses et discussions au sein de la communauté.
Mécanisme de coordination entre les chapeaux blancs
Il est nécessaire d'établir un mécanisme de communication et de coordination au sein de la communauté pour réduire/éviter la compétition entre les white hats. Cette compétition non seulement gaspille les ressources de secours, mais augmente également le coût des opérations de sauvetage. Par exemple, lors de cette opération de sauvetage, nous et trois autres organisations de white hats ### avons simultanément essayé de protéger 54 victimes ( impliquant une perte de 450 ETH ).
Sans un mécanisme de coordination approprié, il est difficile pour les hackers éthiques d'abandonner ou d'arrêter une telle compétition.
( Suggestions pour améliorer les actions de secours
Les white hats peuvent annoncer leurs actions à la communauté sans divulguer d'informations sensibles, afin de gagner la confiance de la communauté.
Les différentes forces de la communauté peuvent collaborer pour rendre les secours plus rapides et efficaces :
Grâce à la collaboration de toutes les parties, nous espérons construire un écosystème Web3 plus sûr et plus efficace.
![])https://img-cdn.gateio.im/webp-social/moments-f6e97c80d0049ad9d2cc45cbbaf91c5a.webp###