ActualitésCryptoTAC affirme qu’un piratage a vidé 28,6 % de l’offre depuis le pool de staking

TAC affirme qu’un piratage a vidé 28,6 % de l’offre depuis le pool de staking

Auteur: Coindoo·

Points clés

  • L’exploit a vidé le compte détenant les TAC délégués aux validateurs et a transféré environ 2,986 milliards de jetons vers BNB Chain en 95 secondes.
  • TAC a indiqué que la surveillance du bridge est restée satisfaite parce que l’attaquant a utilisé de véritables TAC du pool de staking, de sorte que l’offre répliquée est restée entièrement adossée.
  • La faille sous-jacente se trouvait dans un module Cosmos EVM partagé, et non dans le code de bridge propre à TAC, et l’offre totale de jetons n’a pas augmenté.
  • TAC prévoit un edit d’état ciblé pour restaurer le pool bondé et les positions de staking des délégateurs tout en préservant les transactions sans lien avec l’attaque.
  • Les détenteurs sur BNB Chain n’ont toujours pas de plan de traitement final, et TAC a averti les utilisateurs de ne pas trader TAC sur BNB Chain tant que la situation n’est pas résolue.
TAC affirme qu’un piratage a vidé 28,6 % de l’offre depuis le pool de staking

Points clés

L’attaque a déplacé des TAC existants plutôt que de créer une nouvelle offre.

La surveillance du bridge est restée satisfaite parce que chaque jeton répliqué était adossé.

Le plan de reprise de TAC propose de rétablir les soldes de staking par un edit d’état.

Les détenteurs sur BNB Chain ne devraient pas trader tant que leur traitement reste non résolu.

Le bridge était adossé à des TAC volés

Le post-mortem du 2 septembre de TAC indique que ses contrôles de surveillance ont continué à fonctionner tout au long de l’attaque. Ces contrôles avaient été conçus pour détecter l’absence de collatéral du bridge, alors que le vol s’est produit avant que les jetons n’atteignent le bridge. TAC est une blockchain fondée sur Cosmos avec une couche d’exécution compatible Ethereum, conçue pour relier les applications Ethereum à l’écosystème TON et Telegram. Lorsque TAC se déplace vers un autre réseau pris en charge, les jetons natifs restent verrouillés sur TAC et une représentation équivalente est émise sur la chaîne de destination.

Un contrôle automatisé comparait les TAC natifs détenus en conservation à l’offre répliquée sur BNB Chain et Ethereum. L’attaquant a présenté de véritables TAC pris dans le pool de staking, les a verrouillés et a reçu la quantité correcte de jetons répliqués. Les deux côtés du bridge sont restés concordants. Cette précision aide à expliquer pourquoi des vérifications au niveau du bridge peuvent manquer un problème lorsque les registres de soldes sous-jacents sont déjà compromis.

Comme TAC l’a expliqué, « a solvency check cannot detect a theft that preserves solvency. » Le bridge est resté entièrement adossé alors même que les actifs fournissant cet adossement avaient été volés quelques secondes plus tôt.

Le pool de staking a été déplacé en moins de 95 secondes

L’exploit a été exécuté à 19:46:37 UTC le 22 août et a vidé le compte détenant tous les TAC délégués aux validateurs. Le premier transfert de bridge a commencé 32 secondes plus tard, tandis qu’un second a achevé le déplacement d’environ 2,986 milliards de jetons vers BNB Chain en 95 secondes. Les ventes ont commencé quelques minutes plus tard. L’attaquant a échangé 1,208 milliard de TAC sur BNB Chain contre 950,293 USDT et a vendu 49,9 millions de TAC supplémentaires via TON pour 55,481 USDT. Le produit total a atteint environ 1,006 million de dollars.

La production de blocs s’est arrêtée à 23:58:11 UTC, plus de quatre heures après le vidage du pool de staking. Le réseau reste suspendu pendant que les validateurs préparent le logiciel corrigé et le processus de reprise.

Des alertes sur les gros transferts étaient actives, mais le premier mouvement de bridge n’a commencé que 32 secondes après le vidage. Un contrôle nécessitant une revue humaine pourrait aider à retracer les actifs par la suite, mais il ne pouvait pas remplacer un code empêchant la création du solde invalide. La chronologie montre pourquoi le projet met l’accent sur des correctifs de protocole plutôt que sur la seule réponse à l’incident après coup.

L’exploit s’est produit avant le bridge

La vulnérabilité sous-jacente a été trouvée dans le module Cosmos EVM partagé, et non dans le code de bridge propre à TAC. TAC conserve un solde de compte dans sa chaîne basée sur Cosmos et un autre dans sa couche compatible Ethereum, et l’attaque a exploité les différences entre ces enregistrements.

Le logiciel concerné gérait incorrectement la délégation de jetons verrouillés par vesting, les déduisait d’un solde dépensable nul et laissait le résultat se transformer en un nombre extrêmement élevé. Une garde manquante a ensuite laissé le pool de staking contrôlé par le protocole exposé à ce solde invalide.

L’exploit a ramené le pool à zéro et a crédité l’attaquant de ses TAC existants. L’offre totale est restée inchangée, car la transaction a déplacé des jetons entre comptes sans produire de mint durable.

Le bridge n’est intervenu dans la séquence qu’après que le réseau a accepté le solde de l’attaquant comme valide. Il a alors traité les TAC volés de la même manière qu’il traiterait des jetons acquis lors d’une transaction ordinaire.

TAC faisait partie des six réseaux touchés par la vulnérabilité partagée. L’enquête précédente de Coindoo sur la manière dont Cosmos Labs a mal interprété le bug avant le hack sur six chaînes explique pourquoi la faille est restée dangereuse après son signalement initial et comment des avertissements incomplets ont laissé des réseaux indépendants exposés.

Le plan de reprise préserve les transactions sans lien avec l’attaque

TAC prévoit de réparer certains soldes au bloc où le réseau s’est arrêté. Cet edit d’état ciblé préserve le reste de l’historique de la blockchain au lieu de ramener l’ensemble du réseau à un point antérieur.

Un rollback aurait effacé 7,772 transactions légitimes soumises par 218 adresses sans lien avec l’attaque. Il aurait également laissé les TAC répliqués sur d’autres réseaux sans adossement natif correspondant après que des transferts inter-chaînes avaient déjà eu lieu.

L’edit proposé rétablirait le pool bondé à son solde d’avant l’incident et rendrait aux délégateurs leurs positions de staking enregistrées. Il supprimerait aussi les 65,1 millions de TAC gelés dans les adresses liées à l’attaquant lorsque le réseau s’est arrêté. Le déficit de marché restant serait couvert par environ 1,258 milliard de TAC provenant des réserves de trésorerie de la TAC Foundation. Ce montant correspond à la portion vendue via BNB Chain et TON, qui ne peut pas être supprimée onchain sans annuler des soldes détenus par des acheteurs sur le marché.

Aucune de ces étapes n’a été réalisée. Les validateurs doivent d’abord adopter le logiciel corrigé, exécuter l’edit d’état et reprendre la production de blocs, tandis que TAC n’a pas annoncé de date de redémarrage.

Les détenteurs sur BNB Chain n’ont toujours pas de réponse définitive

Un autre 1,662 milliard de TAC demeure dans des adresses associées à l’attaquant sur BNB Chain. Le bridging est désactivé dans les deux sens, ce qui signifie que les TAC basés sur BNB ne peuvent actuellement pas être échangés contre les jetons natifs verrouillés sur TAC. Le solde restant est supérieur au montant déjà vendu et demeure la principale partie non résolue de la reprise. Le rétablissement du pool de staking ne détermine pas la manière dont ces jetons répliqués seront traités lorsque les transferts inter-chaînes reprendront finalement.

TAC travaille avec des plateformes de تداول et des fournisseurs d’infrastructure, mais n’a pas publié le mécanisme, le calendrier ni l’action requise pour les détenteurs sur BNB Chain. Tant que ces conditions ne sont pas fixées, le projet a demandé aux utilisateurs de ne pas trader TAC sur BNB Chain, car cela comporte un risque de perte.

Les stakers n’ont pas besoin de déposer de demande

Les délégateurs n’ont pas à s’enregistrer, fournir des preuves ou connecter un portefeuille. Le plan de reprise utiliserait les enregistrements de staking capturés avant l’incident pour rétablir les soldes au niveau du protocole une fois le réseau relancé.

Les détenteurs sur le réseau TAC suspendu doivent attendre une annonce officielle de redémarrage. TAC indique qu’aucune action n’est requise de la part des utilisateurs détenant son jeton sur TON ou Ethereum, tandis que les actifs autres que TAC sur le réseau natif n’ont pas été affectés par l’attaque. La reprise crée une opportunité pour des escroqueries d’usurpation d’identité. TAC affirme qu’il ne demandera jamais aux utilisateurs de visiter un site externe de réclamation, de connecter un portefeuille ou d’envoyer des fonds pour recevoir des jetons restaurés. Tout message formulant une telle demande doit être considéré comme frauduleux.

Le contrôle manquant se situait avant le bridge

Les contrôles de TAC ont confirmé que les soldes de jetons natifs et répliqués concordaient. L’exploit a réussi parce que ce test a commencé après que le réseau avait déjà accepté des actifs volés comme collatéral valide.

Les contrôles de correspondance des soldes peuvent identifier un adossement manquant, mais ils ne peuvent pas protéger les comptes qui fournissent cet adossement. Le correctif de TAC traite ce point plus en amont en empêchant la création du solde invalide avant qu’il n’atteigne le bridge.

Disclaimer : Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou d’investissement.

L’article Blockchain Hack Drains 28.6% of TAC Supply From Staking Pool est apparu en premier sur Coindoo .