L'indexeur Kasplex KRC-20 « Signature Bypass » vide deux réserves de jetons

Cinq transactions, aucune clé privée

Une clé privée est censée faire la différence entre posséder des cryptomonnaies et simplement savoir où elles se trouvent. Le 20 septembre, quelqu’un a trouvé un moyen de contourner cette hypothèse pour les jetons KRC-20 sans pour autant compromettre la chaîne de base de Kaspa.

L’attaquant a transféré 186 425 259 ZEAL et 54 397 983 246 NACHO depuis une adresse de dépôt du pont, alors même qu’il ne contrôlait pas sa clé privée. Ces jetons ont ensuite été renvoyés vers la même adresse de conservation sous forme de dépôts de pont ordinaires, frappés sur la couche EVM d’Igra Labs et sur Kasplex L2, puis déversés dans les pools de liquidité de Zealous Swap.

Une fois la situation calmée, les soldes L2 de ZEAL et de NACHO de l’attaquant étaient vides, tandis que les pools affectés avaient perdu entre 94 % et 99,6 % de leur valeur côté KAS. Mais voici le hic : la couche 1 (L1) de Kaspa a fonctionné exactement comme prévu.

Une signature vide qui a tout de même été validée

La propriété des jetons KRC-20 n’est pas directement imposée par le consensus Kaspa. Les instructions relatives aux jetons sont intégrées aux transactions Kaspa, tandis qu’un indexeur Kasplex hors chaîne lit ces instructions et détermine qui possède quoi. Normalement, un transfert KRC-20 contient une clé publique, des instructions relatives aux jetons et une signature valide. L’attaquant a conservé cette structure habituelle, mais a fourni une signature vide et ajouté un OP_NOT après OP_ENDIF.

Une signature vide entraîne le renvoi de « false » par OP_CHECKSIG au lieu de bloquer purement et simplement la transaction. L’OP_NOT supplémentaire a inversé ce résultat en « true », laissant Kaspa avec une transaction valide. Rien ne s’était déréglé au niveau de la couche de consensus. L’indexeur, en revanche, c’était une autre histoire. Il a reconnu l’enveloppe KRC-20, mais n’a pas exigé que le script corresponde exactement au format canonique. Il a donc validé le transfert falsifié comme étant légitime. L’API de Kasplex elle-même a même renvoyé « opAccept : 1 » lors de la première transaction ZEAL falsifiée.

N’importe qui pouvait créer la contrefaçon

Le plus insidieux dans cette affaire, c’est que l’attaquant n’avait pas besoin de découvrir des identifiants cachés. Une adresse Kaspa standard expose la clé publique nécessaire pour construire l’opération KRC-20 falsifiée. Cela signifie que le simple fait de déplacer les jetons vers une autre adresse ne résout pas le problème sous-jacent. Tant que l’indexeur n’aura pas été corrigé et que son historique n’aura pas été réindexé, la même faille pourra théoriquement être exploitée contre des soldes KRC-20 ailleurs.

Cinq transactions ont permis de falsifier les transferts de ZEAL et de NACHO. En revanche, neuf petits retraits d’une unité chacun ont été authentiquement signés par le service de garde et semblent avoir constitué des tests visant à vérifier si la voie de sortie fonctionnait. Il est intéressant de noter que les transactions légitimes étaient les plus modestes. Le portefeuille de garde contenait environ 50 autres jetons KRC-20. L’attaquant en a choisi deux.

Les jetons sont toujours là, mais leur contre-valeur a disparu

Dimanche matin, Igra a déclaré que l’intégralité des avoirs en ZEAL et NACHO du portefeuille de conservation avait été dérobée, laissant 97 651 212 ZEAL et 42 570 879 908 NACHO sur les réseaux de couche 2 sans couverture complète en couche 1. 4,5 milliards de NACHO supplémentaires sont restés entre les mains de l’attaquant sur la couche 1.

Igra a suspendu les retraits d’iKAS vers Kaspa L1 ainsi que les transferts via Hyperlane, tandis que les utilisateurs ont été mis en garde contre le pontage de jetons KRC-20, l’achat de ZEAL ou de NACHO sur des bourses décentralisées (DEX) de couche 2, ou l’apport de liquidités aux pools concernés. Les actifs natifs KAS, le consensus Kaspa et les actifs Igra qui n’étaient pas des jetons KRC-20 pontés ont été décrits comme n’étant pas affectés. La correction du logiciel à elle seule ne suffira pas à remédier au problème. Zealous Swap indique que les opérateurs doivent corriger l’indexeur et réindexer son historique, en rejetant les signatures vides, les balises mal formées et les scripts qui se prolongent au-delà de OP_ENDIF. Nacho the Kat, quant à lui, précise que la communauté a l’intention de s’orienter vers le KCC-20, une norme conçue pour intégrer les règles des jetons dans des scripts appliqués par le réseau lui-même.

Ce problème fait suite à une série d’exploits, de bogues, de piratages et de fuites de données survenus au cours des dernières semaines. Samedi, Blink Wallet, fournisseur d’infrastructures de garde et sans garde pour le Lightning Network, a révélé que « quelques dizaines » de comptes de garde avaient été vidés. La société de cybersécurité DCENT a également constaté cette semaine que des fonds avaient été détournés des portefeuilles de l’application DCENT. Ces événements surviennent alors que les attaques de cybersécurité se sont intensifiées, et certains soupçonnent l’IA de contribuer à cette vague d’exploits.