Les utilisateurs de Matcha Meta touchés par le piratage de swapnet exploitant les approbations de jetons permanentes pour voler 16,8 millions de dollars

Les utilisateurs interagissant via Matcha Meta ont été victimes du hack SwapNet, qui a exploité des autorisations de tokens risquées pour voler des fonds à partir de portefeuilles exposés.\n\nAttaque drainant 16,8 millions de dollars via des autorisations exposées\n\nLa société de sécurité blockchain PeckShieldAlert a d’abord signalé un incident de sécurité majeur impliquant SwapNet, affectant les utilisateurs de Matcha Meta. Les attaquants ont abusé des permissions de tokens existantes et ont finalement vidé 16,8 millions de dollars en crypto à partir des portefeuilles concernés. Cependant, le problème principal provenait de la configuration des autorisations, et non d’une faille directe dans le code de Matcha Meta.\n\nSelon PeckShieldAlert, la violation ciblait les utilisateurs qui avaient modifié leurs paramètres de sécurité par défaut de Matcha Meta. Au lieu de s’appuyer sur des permissions temporaires plus sûres, ces utilisateurs avaient accordé un accès plus large et plus persistant aux contrats du protocole, laissant ainsi leurs actifs vulnérables une fois qu’un attaquant avait découvert l’exposition.\n\nComment l’exploit SwapNet a été exécuté\n\nMatcha Meta propose un système d’Autorisation Unique qui limite l’accès aux tokens à une seule transaction. Cette conception aide à contenir le risque en garantissant qu’après exécution, les smart contracts n’ont plus d’autorité continue sur les tokens de l’utilisateur. De plus, elle impose une nouvelle autorisation avant toute nouvelle dépense.\n\nCependant, certains utilisateurs ont désactivé la protection d’autorisation unique et ont plutôt accordé des autorisations directes et à long terme à des contrats d’agrégateurs individuels. Ces autorisations persistantes étaient liées à SwapNet, donnant efficacement à ses contrats un accès continu aux fonds des utilisateurs sur plusieurs transactions sans confirmations supplémentaires.\n\nLes attaquants ont ensuite ciblé ces autorisations de tokens permanentes. Une fois qu’un portefeuille avait approuvé les contrats liés à SwapNet, le hacker pouvait déplacer les tokens à sa guise, sans nécessiter de nouvelles signatures de la victime. Cela a permis de vider silencieusement l’intégralité du solde, car aucune nouvelle demande d’autorisation sur la chaîne n’était requise de la part des utilisateurs.\n\nEn termes pratiques, le hack SwapNet a transformé ces larges autorisations en une voie d’attaque directe. Les autorisations destinées à faciliter le trading sont devenues un outil pour des transferts de fonds non autorisés après que les contrats ont été compromis ou mal utilisés.\n\nTraces sur la chaîne sur Base et Ethereum\n\nLes données on-chain révèlent que l’attaquant s’est concentré principalement sur le réseau Base. Selon des analyses préliminaires, environ 10,5 millions de dollars en USDC ont été échangés contre environ 3 655 ETH. De plus, le timing et le pattern des échanges suggèrent une tentative coordonnée de convertir rapidement et de redistribuer les stablecoins volés.\n\nPeu après les premiers échanges, l’attaquant a commencé à faire du pont entre Base et Ethereum, déplaçant des fonds de Base vers Ethereum. Le pontage est une technique courante utilisée par les voleurs on-chain pour compliquer le suivi et mélanger l’historique des transactions sur plusieurs chaînes, rendant les efforts des forces de l’ordre et des analystes plus difficiles.\n\nDes enregistrements de transactions supplémentaires montrent de grands transferts USDC dépassant 13 millions de dollars et des interactions directes avec des pools de liquidité Uniswap V3. De plus, le rapport de violation de PeckShieldAlert estime que l’impact cumulé a atteint environ 16,8 millions de dollars en actifs volés après agrégation des activités sur les adresses impliquées.\n\nRéaction de Matcha Meta et SwapNet\n\nMatcha Meta a reconnu publiquement l’incident et a déclaré qu’il collaborait étroitement avec l’équipe SwapNet. En tant que mesure immédiate de containment, SwapNet a temporairement désactivé ses contrats pour arrêter toute exploitation supplémentaire et réduire le risque de drain supplémentaire de portefeuilles.\n\nDe plus, Matcha Meta a supprimé l’option permettant aux utilisateurs de définir des autorisations directes pour les agrégateurs, ce qui avait créé la porte d’entrée pour l’attaque. La modification vise à garantir que les activités de trading futures reposent sur des modèles d’autorisation plus restrictifs, réduisant ainsi la portée en cas d’incident similaire.\n\nLa plateforme a également exhorté les utilisateurs à révoquer les autorisations de tokens qui dépassent celles de ses propres contrats d’Autorisation Unique. En particulier, Matcha Meta a mis en évidence les autorisations liées au contrat de routeur de SwapNet, qui ont maintenant été identifiées comme un facteur de risque clé dans la violation.\n\nEnquête en cours et protection des utilisateurs\n\nLes investigations sur les portefeuilles compromis et les contrats associés sont toujours en cours. Both Matcha Meta et SwapNet ont promis de fournir des mises à jour continues en suivant le mouvement des fonds volés et en collaborant avec des chercheurs en sécurité. Cependant, la récupération des actifs dans de tels incidents on-chain s’avère souvent difficile une fois que les fonds ont été blanchis à travers plusieurs protocoles.\n\nPour l’instant, les équipes se concentrent sur la limitation de l’exposition supplémentaire et sur l’accompagnement des utilisateurs dans les bonnes pratiques de sécurité. Cela dit, cet épisode souligne à quel point les autorisations de tokens peuvent devenir une responsabilité lorsqu’elles sont mal utilisées ou laissées sans surveillance, surtout lorsqu’un scénario de routeur SwapNet compromis émerge.\n\nEn résumé, la violation montre que les choix de configuration autour des autorisations sont aussi cruciaux que le code des smart contracts. Les utilisateurs qui privilégient des permissions restrictives et d’une seule fois, tout en auditant régulièrement leurs autorisations, sont mieux préparés à résister à des exploits similaires ciblant les agrégateurs DeFi.