Le 18 janvier 2022, notre système de surveillance des transactions anormales a détecté une attaque contre le projet AnySwap (, à savoir Multichain ). En raison d'une vulnérabilité dans la fonction anySwapOutUnderlyingWithPermit(), les tokens autorisés par les utilisateurs à ce projet peuvent être volés par des attaquants.
Bien que l'équipe du projet ait utilisé plusieurs moyens pour rappeler aux utilisateurs affectés (, comme l'envoi de rappels de transaction ), de nombreux utilisateurs n'ont pas retiré leur autorisation à temps, permettant aux attaquants de continuer à réaliser des bénéfices.
Étant donné que l'attaque est toujours en cours, l'équipe de BlockSec a décidé de prendre des mesures d'urgence pour protéger les victimes potentielles. Nous ciblons principalement les comptes affectés sur Ethereum, en transférant les fonds concernés vers un compte multi-signatures spécialement créé pour les hackers éthiques. Afin d'assurer la transparence de l'action, nous rendrons public le hachage du document de plan sommaire (, non contenu ), pour distinguer notre comportement de celui des attaquants, tout en ne divulguant pas de détails. L'opération de sauvetage a commencé le 21 janvier 2022 et s'est terminée le 11 mars.
Les opérations de secours d'urgence font face à de nombreux défis techniques et non techniques. Maintenant que l'action est terminée, nous pouvons revenir sur l'ensemble du processus et partager nos expériences et réflexions avec la communauté, en espérant contribuer à la sécurité de l'écosystème DeFi.
Résumé
L'utilisation généralisée de Flashbots a entraîné une concurrence féroce entre les hackers éthiques et les attaquants, ainsi qu'au sein de chaque groupe, les frais payés ayant également augmenté rapidement au fil du temps.
Flashbots n'est pas une solution universelle, certains attaquants utilisent plutôt le mempool, en organisant habilement des transactions d'attaque pour réussir à les exécuter.
Certains attaquants ont conclu un accord avec l'équipe du projet pour restituer une partie des gains tout en conservant une partie comme récompense, réussissant ainsi à "blanchir" leur action. Cette pratique a suscité des controverses au sein de la communauté.
Les hackers éthiques peuvent agir publiquement auprès de la communauté sans divulguer d'informations sensibles, cette méthode de confiance fonctionne bien.
La collaboration des différentes forces de la communauté peut rendre le secours plus rapide et efficace, comme la coopération entre les hackers éthiques pour réduire la concurrence inutile.
Nous allons aborder la discussion sous quatre aspects : d'abord, nous passerons en revue la situation générale de l'événement, puis nous présenterons les méthodes de sauvetage et les défis rencontrés, ensuite nous partagerons nos réflexions et expériences lors de l'action, et enfin nous proposerons quelques recommandations.
Aperçu des situations d'attaque et de sauvetage
Résultat global
La période que nous avons observée s'étend du 18 janvier 2022 au 20 mars 2022. La situation générale est la suivante :
9 comptes de secours ont protégé 483.027693 ETH, dont 295.970554 ETH ont payé des frais Flashbots( représentant 61.27%)
21 comptes attaquants ont réalisé un bénéfice de 1433.092224 ETH, payant des frais Flashbots de 148.903707 ETH( représente 10.39%)
Il est à noter que, en raison de certaines situations complexes (, telles que le retour d'une partie des bénéfices après négociation entre l'attaquant et l'équipe du projet ), ces données ne sont qu'une estimation.
Tendance des frais Flashbots
Les white hats doivent rivaliser avec les attaquants pour envoyer des transactions Flashbots afin de mettre en œuvre le sauvetage, les frais payés reflètent le niveau de concurrence. Nous avons statistiqué la part des frais Flashbots des transactions d'attaque et de sauvetage par bloc de transaction.
Initial Flashbots fees for some attack transactions were 0, indicating that attackers had not yet used Flashbots. Subsequently, the fee ratio rapidly increased, reaching 80% and 91% in certain blocks. This indicates that it has evolved into an arms race for the fees associated with on-chain rights to Flashbots.
Les actions de secours que nous mettons en œuvre et les défis auxquels nous sommes confrontés
La pensée de base de l'opération de secours
Nous avons surveillé un groupe de comptes potentiellement victimes qui ont autorisé des WETH à un contrat problématique. Lorsque des WETH sont transférés vers ces comptes, nous exploitons les vulnérabilités du contrat pour les transférer vers un portefeuille multisignature de white hat. L'essentiel est de satisfaire les trois conditions suivantes :
Localisation efficace du transfert vers la transaction du victim ( transaction de transfert )
Construire correctement des transactions de sauvetage ( sauver transaction )
Réussir à devancer les transactions d'un attaquant ( ou d'un autre tiers ) attaque de transaction (
Les deux premiers points ne constituent pas un obstacle pour nous, car nous avons un système de surveillance du mempool et des outils pour construire automatiquement des transactions de sauvetage. Mais le troisième point reste un défi.
Bien que théoriquement il soit possible de gagner des frontruns avec Flashbots, cela ne se révèle pas facile en pratique. Tout d'abord, les attaquants peuvent également utiliser Flashbots, et le taux de réussite dépend du montant des enchères. Ensuite, la concurrence intense rend Flashbots pas toujours le meilleur choix, nous envoyons également des transactions ordinaires via le mempool. Enfin, nous avons également une concurrence avec d'autres "chapeaux blancs", et certains comportements dits "chapeaux blancs" sont en réalité plutôt suspects.
) Situation concurrentielle
Nous avons tenté de protéger 171 comptes potentiels de victimes indépendants. Parmi eux, 10 ont annulé leur autorisation à temps, et parmi les 161 restants, nous n'avons réussi à en sauver que 14. Les cas d'échec impliquent 3 comptes de sauvetage et 16 comptes attaquants.
Au cours de l'opération de sauvetage, nous avons été battus 12 fois par d'autres concurrents, y compris 2 comptes de sauvetage et 10 comptes d'attaque.
Notre stratégie est plutôt conservatrice, tendant à établir des frais Flashbots relativement bas pour protéger les intérêts des victimes. À moins qu'il n'y ait déjà des transactions d'attaque réussies utilisant Flashbots, nous n'utiliserons pas activement ou n'augmenterons pas les frais. Cependant, cette stratégie n'est pas très efficace, les adversaires étant souvent plus agressifs :
Un attaquant a fixé le taux de frais à 70%
Un chapeau blanc a fixé le taux de frais à 79%, 80%
Un autre chapeau blanc a fixé le taux de frais à 81%
L'attaquant a ensuite augmenté le ratio des frais à 86%
Il semble s'agir d'un jeu à somme nulle, nécessitant de modéliser et d'explorer les comportements des différentes parties. Dans la pratique, il est à la fois nécessaire de réduire les coûts autant que possible et de trouver la stratégie optimale pour gagner la compétition, ce qui constitue une tâche extrêmement difficile.
La concurrence féroce fait que Flashbots n'est pas toujours efficace. En envoyant des transactions ordinaires via le mempool, si elles peuvent être positionnées correctement ### juste après les transactions de transfert (, il est également possible d'atteindre l'objectif.
Un attaquant a réussi à tirer profit de cette stratégie en gagnant 312 ETH, sans avoir à payer de frais Flashbots. Par exemple :
Bloc 14051020 : la transaction de transfert de la victime est située à 65, la transaction d'attaque est située à 66
Bloc 14052155 : la transaction de transfert de la victime est à 161, la transaction d'attaque est à 164
Cette stratégie ingénieuse allie praticité et inspiration, elle mérite d'être remarquée.
Identifier un white hat n'est pas toujours simple. Par exemple, un compte initialement signalé comme attaquant a ensuite, après des négociations avec l'équipe du projet, accepté de conserver 50 ETH en tant que récompense et de restituer les autres bénéfices, puis a été reclassé en white hat.
Ce phénomène n'est pas nouveau, et l'équité de son mécanisme d'incitation a suscité des controverses au sein de la communauté.
compétition entre chapeaux blancs
Il est nécessaire d'établir un mécanisme de coordination au sein de la communauté pour réduire la concurrence entre les hackers éthiques. Cette concurrence non seulement gaspille des ressources, mais augmente également les coûts de sauvetage. Par exemple, nous avons essayé de protéger simultanément 54 victimes ### impliquant 450 ETH( avec trois autres organisations de hackers éthiques. Sans mécanisme de coordination, il est difficile pour les hackers éthiques d'abandonner ou d'arrêter cette concurrence.
) améliorer les opérations de secours
Les hackers éthiques peuvent agir publiquement au sein de la communauté sans divulguer d'informations sensibles, et cette pratique est efficace.
Les différentes parties de la communauté peuvent collaborer pour améliorer l'efficacité des secours :
Flashbots/les mineurs offrent un accès privilégié aux white hats de confiance
Le projet prend en charge les frais de Flashbots
L'équipe du projet utilise un mécanisme d'alerte utilisateur plus pratique
L'équipe du projet a intégré des mesures d'urgence dans le code.
Grâce aux efforts conjoints de toutes les parties, nous pouvons mieux relever les défis de sécurité dans l'écosystème Web3 et protéger les intérêts des utilisateurs.
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.
16 J'aime
Récompense
16
5
Partager
Commentaire
0/400
SchrodingerAirdrop
· Il y a 18h
Il est essentiel de prévenir plutôt que de guérir.
Voir l'originalRépondre0
ShibaSunglasses
· 08-05 22:39
Analyse de cas de hackers classiques
Voir l'originalRépondre0
LiquiditySurfer
· 08-05 22:28
L'assistance est rapide et très professionnelle.
Voir l'originalRépondre0
MidnightTrader
· 08-05 22:25
La prévention est toujours plus importante que le secours.
Voir l'originalRépondre0
SmartContractWorker
· 08-05 22:18
Le code du contrat doit être vérifié plusieurs fois.
Web3 Sécurité: Expériences et enseignements de l'opération de sauvetage AnySwap
Retour et réflexion sur l'action d'urgence Web3
Le 18 janvier 2022, notre système de surveillance des transactions anormales a détecté une attaque contre le projet AnySwap (, à savoir Multichain ). En raison d'une vulnérabilité dans la fonction anySwapOutUnderlyingWithPermit(), les tokens autorisés par les utilisateurs à ce projet peuvent être volés par des attaquants.
Bien que l'équipe du projet ait utilisé plusieurs moyens pour rappeler aux utilisateurs affectés (, comme l'envoi de rappels de transaction ), de nombreux utilisateurs n'ont pas retiré leur autorisation à temps, permettant aux attaquants de continuer à réaliser des bénéfices.
Étant donné que l'attaque est toujours en cours, l'équipe de BlockSec a décidé de prendre des mesures d'urgence pour protéger les victimes potentielles. Nous ciblons principalement les comptes affectés sur Ethereum, en transférant les fonds concernés vers un compte multi-signatures spécialement créé pour les hackers éthiques. Afin d'assurer la transparence de l'action, nous rendrons public le hachage du document de plan sommaire (, non contenu ), pour distinguer notre comportement de celui des attaquants, tout en ne divulguant pas de détails. L'opération de sauvetage a commencé le 21 janvier 2022 et s'est terminée le 11 mars.
Les opérations de secours d'urgence font face à de nombreux défis techniques et non techniques. Maintenant que l'action est terminée, nous pouvons revenir sur l'ensemble du processus et partager nos expériences et réflexions avec la communauté, en espérant contribuer à la sécurité de l'écosystème DeFi.
Résumé
L'utilisation généralisée de Flashbots a entraîné une concurrence féroce entre les hackers éthiques et les attaquants, ainsi qu'au sein de chaque groupe, les frais payés ayant également augmenté rapidement au fil du temps.
Flashbots n'est pas une solution universelle, certains attaquants utilisent plutôt le mempool, en organisant habilement des transactions d'attaque pour réussir à les exécuter.
Certains attaquants ont conclu un accord avec l'équipe du projet pour restituer une partie des gains tout en conservant une partie comme récompense, réussissant ainsi à "blanchir" leur action. Cette pratique a suscité des controverses au sein de la communauté.
Les hackers éthiques peuvent agir publiquement auprès de la communauté sans divulguer d'informations sensibles, cette méthode de confiance fonctionne bien.
La collaboration des différentes forces de la communauté peut rendre le secours plus rapide et efficace, comme la coopération entre les hackers éthiques pour réduire la concurrence inutile.
Nous allons aborder la discussion sous quatre aspects : d'abord, nous passerons en revue la situation générale de l'événement, puis nous présenterons les méthodes de sauvetage et les défis rencontrés, ensuite nous partagerons nos réflexions et expériences lors de l'action, et enfin nous proposerons quelques recommandations.
Aperçu des situations d'attaque et de sauvetage
Résultat global
La période que nous avons observée s'étend du 18 janvier 2022 au 20 mars 2022. La situation générale est la suivante :
Il est à noter que, en raison de certaines situations complexes (, telles que le retour d'une partie des bénéfices après négociation entre l'attaquant et l'équipe du projet ), ces données ne sont qu'une estimation.
Tendance des frais Flashbots
Les white hats doivent rivaliser avec les attaquants pour envoyer des transactions Flashbots afin de mettre en œuvre le sauvetage, les frais payés reflètent le niveau de concurrence. Nous avons statistiqué la part des frais Flashbots des transactions d'attaque et de sauvetage par bloc de transaction.
Initial Flashbots fees for some attack transactions were 0, indicating that attackers had not yet used Flashbots. Subsequently, the fee ratio rapidly increased, reaching 80% and 91% in certain blocks. This indicates that it has evolved into an arms race for the fees associated with on-chain rights to Flashbots.
Les actions de secours que nous mettons en œuvre et les défis auxquels nous sommes confrontés
La pensée de base de l'opération de secours
Nous avons surveillé un groupe de comptes potentiellement victimes qui ont autorisé des WETH à un contrat problématique. Lorsque des WETH sont transférés vers ces comptes, nous exploitons les vulnérabilités du contrat pour les transférer vers un portefeuille multisignature de white hat. L'essentiel est de satisfaire les trois conditions suivantes :
Les deux premiers points ne constituent pas un obstacle pour nous, car nous avons un système de surveillance du mempool et des outils pour construire automatiquement des transactions de sauvetage. Mais le troisième point reste un défi.
Bien que théoriquement il soit possible de gagner des frontruns avec Flashbots, cela ne se révèle pas facile en pratique. Tout d'abord, les attaquants peuvent également utiliser Flashbots, et le taux de réussite dépend du montant des enchères. Ensuite, la concurrence intense rend Flashbots pas toujours le meilleur choix, nous envoyons également des transactions ordinaires via le mempool. Enfin, nous avons également une concurrence avec d'autres "chapeaux blancs", et certains comportements dits "chapeaux blancs" sont en réalité plutôt suspects.
) Situation concurrentielle
Nous avons tenté de protéger 171 comptes potentiels de victimes indépendants. Parmi eux, 10 ont annulé leur autorisation à temps, et parmi les 161 restants, nous n'avons réussi à en sauver que 14. Les cas d'échec impliquent 3 comptes de sauvetage et 16 comptes attaquants.
![]###https://img-cdn.gateio.im/webp-social/moments-d22626977feebe325b02c899454022c7.webp(
Leçons apprises
) Paramètres des frais Flashbots
Au cours de l'opération de sauvetage, nous avons été battus 12 fois par d'autres concurrents, y compris 2 comptes de sauvetage et 10 comptes d'attaque.
Notre stratégie est plutôt conservatrice, tendant à établir des frais Flashbots relativement bas pour protéger les intérêts des victimes. À moins qu'il n'y ait déjà des transactions d'attaque réussies utilisant Flashbots, nous n'utiliserons pas activement ou n'augmenterons pas les frais. Cependant, cette stratégie n'est pas très efficace, les adversaires étant souvent plus agressifs :
Il semble s'agir d'un jeu à somme nulle, nécessitant de modéliser et d'explorer les comportements des différentes parties. Dans la pratique, il est à la fois nécessaire de réduire les coûts autant que possible et de trouver la stratégie optimale pour gagner la compétition, ce qui constitue une tâche extrêmement difficile.
![]###https://img-cdn.gateio.im/webp-social/moments-3a365a505b5c5ac87a42a6d277af23ff.webp(
) Tri des transactions dans le Mempool
La concurrence féroce fait que Flashbots n'est pas toujours efficace. En envoyant des transactions ordinaires via le mempool, si elles peuvent être positionnées correctement ### juste après les transactions de transfert (, il est également possible d'atteindre l'objectif.
Un attaquant a réussi à tirer profit de cette stratégie en gagnant 312 ETH, sans avoir à payer de frais Flashbots. Par exemple :
Cette stratégie ingénieuse allie praticité et inspiration, elle mérite d'être remarquée.
![])https://img-cdn.gateio.im/webp-social/moments-cb547989448abc96498684cb89da8860.webp(
Autres réflexions
) Définition du chapeau blanc et de l'attaquant
Identifier un white hat n'est pas toujours simple. Par exemple, un compte initialement signalé comme attaquant a ensuite, après des négociations avec l'équipe du projet, accepté de conserver 50 ETH en tant que récompense et de restituer les autres bénéfices, puis a été reclassé en white hat.
Ce phénomène n'est pas nouveau, et l'équité de son mécanisme d'incitation a suscité des controverses au sein de la communauté.
compétition entre chapeaux blancs
Il est nécessaire d'établir un mécanisme de coordination au sein de la communauté pour réduire la concurrence entre les hackers éthiques. Cette concurrence non seulement gaspille des ressources, mais augmente également les coûts de sauvetage. Par exemple, nous avons essayé de protéger simultanément 54 victimes ### impliquant 450 ETH( avec trois autres organisations de hackers éthiques. Sans mécanisme de coordination, il est difficile pour les hackers éthiques d'abandonner ou d'arrêter cette concurrence.
) améliorer les opérations de secours
Les hackers éthiques peuvent agir publiquement au sein de la communauté sans divulguer d'informations sensibles, et cette pratique est efficace.
Les différentes parties de la communauté peuvent collaborer pour améliorer l'efficacité des secours :
Grâce aux efforts conjoints de toutes les parties, nous pouvons mieux relever les défis de sécurité dans l'écosystème Web3 et protéger les intérêts des utilisateurs.
![]###https://img-cdn.gateio.im/webp-social/moments-adbfab235ed4a4c2a3ef7a58915c4deb.webp(