Cronos a effectué un rollback de sa chaîne après un piratage de 75 millions de dollars

Les validateurs de Cronos ont effacé 10 000 blocs pour inverser l'exploit de Tectonic, sauvant 69 millions de dollars d'actifs gelés tout en déclenchant un débat féroce sur la question de savoir si une blockchain qui peut être réécrite sur commande mérite d'être appelée ainsi.

Cronos a fait quelque chose le 30 août que la plupart des blockchains prétendent ne pas pouvoir faire et ne feraient jamais. Ses validateurs ont coordonné un arrêt d'urgence, ont accepté de jeter plus de 10 000 blocs d'historique canonique et ont redémarré la chaîne à partir d'un instantané pris avant qu'un protocole de prêt appelé Tectonic ne perde 75 millions de dollars à cause d'une attaque de manipulation de garantie. Les fonds volés, moins environ 6 millions de dollars qui avaient déjà été transférés vers Ethereum, ont simplement cessé d'exister sur la chaîne redémarrée.

La réponse a fonctionné. Elle a contenu les dégâts. Elle a probablement sauvé les déposants de perdre tout ce qu'ils avaient dans Tectonic.

Et elle a soulevé une question que l'industrie a évitée de répondre depuis le fork DAO d'Ethereum en 2016 : si un petit groupe de validateurs peut réécrire l'historique d'une chaîne pour inverser un vol, qu'est-ce qui sépare exactement cette chaîne d'une base de données avec des étapes supplémentaires ? La réponse compte plus maintenant qu'en 2016, car l'industrie a passé la décennie intermédiaire à dire aux institutions, aux régulateurs et aux utilisateurs de détail que les blockchains offrent quelque chose que l'infrastructure financière traditionnelle ne fait pas : des transactions qui ne peuvent pas être inversées par une autorité unique. Cronos a prouvé que cette affirmation ne s'applique pas universellement.

Comment Tectonic a perdu 75 millions de dollars en 20 minutes

L'attaque a suivi un schéma si bien documenté que les chercheurs en sécurité DeFi lui ont donné un nom : un pump-and-borrow de style Mango.

Tectonic, le plus grand protocole de prêt sur Cronos avec environ 121,7 millions de dollars de valeur totale verrouillée et 82,7 millions de dollars de prêts actifs, permettait aux utilisateurs de déposer TONIC, son jeton de gouvernance, comme garantie. TONIC avait un facteur de garantie de 20 %, ce qui signifie que les utilisateurs pouvaient emprunter des actifs d'une valeur allant jusqu'à un cinquième de la valeur déclarée de leur garantie déposée. Ce paramètre supposait que le prix déclaré de TONIC reflétait quelque chose de proche de sa valeur de liquidation réelle. Ce n'était pas le cas.

L'attaquant a dépensé environ 600 000 dollars pour acheter TONIC sur des marchés Cronos peu profonds, poussant le prix du jeton environ 100 fois plus haut en environ 20 minutes. L'attaquant a ensuite fourni 364,6 billions de TONIC à Tectonic à la valorisation gonflée, créant une position de garantie déclarée d'une valeur d'environ 375 millions de dollars. Contre cette garantie fantôme, l'attaquant a emprunté environ 75 millions de dollars en actifs liquides auprès d'autres déposants.

Les chiffres racontent clairement l'histoire. Un investissement de 600 000 dollars s'est transformé en un retrait de 75 millions de dollars. Le retour sur capital était d'environ 12 400 %. La garantie adossée au prêt n'aurait pas pu être vendue pour une fraction de sa valeur déclarée sans faire chuter le prix à son niveau initial. Les marchés de prêt de Tectonic avaient été drainés en utilisant leurs propres hypothèses de prix.

Avant l'exploit, Tectonic détenait près de la moitié de tout le capital déposé sur les applications DeFi de Cronos. Dans les 48 heures, sa TVL est passée de 121,7 millions de dollars à environ 3 millions de dollars. Le protocole qui était censé ancrer l'écosystème DeFi de Cronos était devenu son passif le plus coûteux.

L'arrêt : les validateurs tirent le frein d'urgence

Les validateurs de Cronos ont détecté l'exploit en quelques minutes et ont pris une décision qu'aucun réseau véritablement décentralisé ne pourrait prendre rapidement : ils ont arrêté de produire des blocs.

L'arrêt a tout figé. Non seulement Tectonic. Chaque transfert, chaque interaction de contrat intelligent, chaque transaction de pont sur l'ensemble du réseau Cronos est devenu inopérant. Les utilisateurs qui n'avaient rien à voir avec Tectonic ne pouvaient pas déplacer leurs fonds. Les ponts reliant Cronos à Ethereum et à d'autres chaînes ont cessé de traiter les transactions. Les fournisseurs RPC desservant les applications construites sur Cronos sont devenus sombres.

Le moment était extrêmement important. Au moment où les validateurs ont arrêté la production de blocs, l'attaquant avait réussi à transférer environ 6 millions de dollars vers Ethereum, où les validateurs de Cronos n'ont aucune autorité. Les 69 millions de dollars restants se trouvaient sur des adresses Cronos identifiées, gelés mais techniquement toujours sous le contrôle de l'attaquant sur la chaîne arrêtée.

Kris Marszalek, le PDG de Crypto.com, a publié que l'échange et l'application continuaient de fonctionner normalement et que « tous les fonds sont en sécurité ». Cette déclaration concernait spécifiquement les actifs détenus via les services centralisés de Crypto.com, et non les fonds déposés dans Tectonic. La distinction est importante. Crypto.com et Cronos sont étroitement associés, mais Tectonic fonctionne comme une application décentralisée distincte. Une défaillance dans l'un ne compromet pas nécessairement l'autre, et l'assurance de Marszalek ne couvrait que le côté centralisé.

Le rollback : effacer 10 000 blocs de l'historique de tout le monde

Au lieu de redémarrer à partir de l'état arrêté et d'espérer geler les adresses de l'attaquant par une intervention de gouvernance ou technique, les validateurs de Cronos ont choisi l'option nucléaire. Ils ont restauré la chaîne à un instantané pris avant l'exploit, ont annulé plus de 10 000 blocs et ont repris la production de blocs à partir du bloc 90 896 189.

Les transactions de l'attaque ont cessé d'exister sur la chaîne canonique. Il en va de même pour toutes les autres transactions qui ont eu lieu pendant ces blocs effacés. Les échanges légitimes, les transferts de jetons, les déploiements de contrats et toute autre activité qui se sont produits pendant cette fenêtre d'environ deux heures ont disparu.

Cronos a décrit l'arrêt comme une « action d'urgence de consensus des validateurs » pour protéger les utilisateurs. Le post-mortem de la chaîne, promis mais pas encore publié, devrait expliquer le processus exact par lequel les validateurs se sont mis d'accord sur le point de restauration. Ce que nous savons, c'est que la décision a été prise rapidement, exécutée par un petit ensemble de validateurs, et a inversé l'historique canonique d'une blockchain publique.

Tatum, un fournisseur d'infrastructure desservant les développeurs sur Cronos, a dû rejouer toutes les données de la chaîne à partir du bloc 90 896 188 pour resynchroniser ses systèmes. D'autres fournisseurs RPC, explorateurs et ponts ont nécessité des réinitialisations similaires. Le rollback n'a pas seulement affecté l'attaquant. Il a forcé chaque service connecté à Cronos à réconcilier une nouvelle version de la réalité.

Pourquoi l'oracle n'était pas le problème

L'instinct après un exploit de manipulation des prix est de blâmer l'oracle. Le cofondateur de RedStone, Marcin Kazmierczak, a rejeté cette vision dans une déclaration à crypto.news.

« L'oracle n'a pas eu tort. Il a rapporté avec précision le prix du TONIC sur le pool à partir duquel il lisait à ce moment-là », a déclaré Kazmierczak.

La distinction est importante. Un oracle qui rapporte le prix actuel du marché d'un jeton fait son travail, même si ce prix a été artificiellement gonflé. La défaillance incombe au protocole qui accepte le prix rapporté comme sûr pour le prêt sans vérifier si le jeton pouvait réellement être vendu à cette valorisation.

Kazmierczak a identifié la sauvegarde manquante : des plafonds d'emprunt liés à la liquidité exécutable. Un tel plafond limite l'emprunt en fonction de la quantité de garantie qui pourrait être vendue de manière réaliste sans faire chuter son prix. Même si la valeur rapportée du TONIC avait grimpé de 100 fois, un plafond d'emprunt correctement défini aurait restreint l'emprunt à ce que le marché pouvait absorber.

« Rapporter un prix et valider qu'un prix est sûr pour prêter sont deux tâches différentes, et la conception de Tectonic les a confondues », a-t-il déclaré.

Il a rejeté l'idée qu'une fenêtre de prix moyen pondéré dans le temps plus longue aurait empêché l'attaque. Une augmentation de prix de 100 fois en 20 minutes, a-t-il soutenu, n'est pas un événement de volatilité que le lissage peut corriger. C'est un signal que l'actif n'aurait jamais dû être utilisé comme garantie à une taille significative.

Cette attaque n'est pas nouvelle. C'est là le problème.

Le manuel utilisé par l'attaquant de Tectonic est presque identique à celui qu'Avraham Eisenberg a exécuté contre Mango Markets en octobre 2022, drainant plus de 100 millions de dollars en gonflant le jeton de gouvernance MNGO peu négocié et en empruntant des actifs liquides contre celui-ci. Un jury de Manhattan a reconnu Eisenberg coupable de fraude sur les matières premières, de manipulation des matières premières et de fraude électronique. Un juge fédéral a ensuite annulé les condamnations en raison de problèmes de compétence et de preuves insuffisantes sur le chef de fraude électronique.

L'affaire Eisenberg est pertinente au-delà des parallèles techniques. Sa défense juridique a soutenu que les règles du protocole permettaient ce qu'il a fait, que les contrats intelligents fonctionnaient comme prévu et qu'exploiter un défaut de conception n'équivaut pas à commettre une fraude. Le jury n'était pas d'accord, mais les condamnations annulées ont laissé le statut juridique de ce vecteur d'attaque non résolu. Quiconque réplique ce manuel aujourd'hui opère dans une ambiguïté juridique réelle, ce qui peut expliquer en partie pourquoi les attaques continuent de se produire.

Trois jours avant l'exploit de Tectonic, un attaquant a drainé 8,7 millions de dollars de Moonwell sur Base en utilisant exactement la même technique contre le jeton MAMO illiquide. Moonwell a répondu en réduisant les plafonds d'emprunt à 1 wei sur ses marchés de base, fermant effectivement les nouveaux prêts. Le correctif était disponible avant l'attaque. Le protocole a choisi de ne pas le mettre en œuvre jusqu'à ce que les dégâts soient faits.

Moola Market sur Celo a perdu des fonds via le même schéma en octobre 2022, le même mois que Mango Markets. Quatre ans plus tard, l'attaque fonctionne toujours parce que l'incitation économique à lister les jetons de gouvernance comme garantie dépasse le risque perçu. Les équipes de protocole bénéficient de chiffres TVL plus élevés. Les détenteurs de jetons de gouvernance bénéficient d'une utilité accrue. Le coût de paramètres de garantie faibles reste caché jusqu'à ce que quelqu'un teste si le marché peut absorber une liquidation soudaine des jetons déposés. Il ne le peut pas. Il ne le pourra jamais. La liquidité qui devrait exister pour rendre ces jetons sûrs comme garantie à leurs facteurs de garantie répertoriés n'existe tout simplement pas pour les jetons de gouvernance à faible capitalisation.

Les chaînes Cosmos EVM ont reçu l'ordre de s'arrêter après un incident de sécurité distinct le 25 août. KiiChain a signalé 148,3 millions de KII drainés lors de 18 attaques. MANTRA a arrêté son réseau quelques jours plus tôt tout en enquêtant sur un autre incident. Trois arrêts de chaîne en une semaine. La fréquence seule devrait inquiéter quiconque traite la finalité comme une propriété que sa blockchain possède réellement.

La comparaison avec le fork de la DAO et pourquoi elle ne convient pas tout à fait

Le fork de la DAO d'Ethereum en 2016 est le précédent évident. Un attaquant a exploité une vulnérabilité de réentrance pour drainer environ 60 millions de dollars (à l'époque) de The DAO, et la communauté Ethereum a voté pour un hard fork, créant une nouvelle chaîne qui a annulé le vol et une chaîne originale (Ethereum Classic) qui a préservé l'historique canonique.

La comparaison est instructive mais les différences comptent plus que les similitudes.

Le fork de la DAO a pris des semaines de débat public. Les fils de discussion sur CoinDesk, Reddit et Bitcointalk ont accumulé des milliers de commentaires. Les mineurs ont voté avec leur hashrate. La communauté s'est fracturée, produisant Ethereum Classic comme monument permanent au principe que le code est la loi. Le processus a été assez douloureux pour qu'Ethereum traite l'immuabilité comme quasi sacrée depuis lors. Le pont Ronin a perdu 625 millions de dollars en 2022. Le pont Wormhole a perdu 320 millions la même année. Personne n'a sérieusement proposé de restaurer Ethereum pour l'un ou l'autre.

Cronos a accompli quelque chose de similaire en quelques heures avec une poignée de validateurs. Pas de vote communautaire. Pas de semaines de débat. Pas de scission de chaîne. Pas de fork préservant l'historique original pour ceux qui n'étaient pas d'accord. Les validateurs ont accepté, ont restauré, et ont continué. La vitesse est le problème, car une restauration qui nécessite un large consensus communautaire et des semaines de délibération est un dernier recours, tandis qu'une restauration qu'un petit ensemble de validateurs peut exécuter en quelques heures est un outil administratif. Et les outils administratifs sont utilisés.

La concentration des validateurs explique la rapidité. Parce que la chaîne Cronos est maintenue par un nombre relativement restreint de validateurs, dont beaucoup sont contrôlés par Crypto.com ou étroitement associés à celle-ci, coordonner un arrêt et une restauration nécessite l'accord de beaucoup moins de parties indépendantes que sur Ethereum, Bitcoin ou toute autre chaîne disposant d'un ensemble de validateurs ou de mineurs important et diversifié. Ce n'est pas un bug dans la réponse à l'exploit Tectonic. C'est la condition structurelle qui a rendu cette réponse possible.

Comme l'a formulé un critique : si 75 millions de dollars justifient une restauration, qu'en est-il de 50 millions ? 10 millions ? Et au-delà des attaques de piratage, quels autres types d'événements suffiraient pour que les validateurs appuient sur le bouton de rechargement ? L'absence d'un cadre de gouvernance publié pour déterminer quand les restaurations sont appropriées signifie que la réponse est ce que l'ensemble des validateurs décide à ce moment-là. Ce n'est pas une gouvernance décentralisée. C'est un pouvoir discrétionnaire, et un pouvoir discrétionnaire sans règles n'est que du pouvoir.

Qui a perdu de l'argent dans les blocs effacés

La restauration a contenu l'exploit. Elle a également effacé des activités légitimes.

Chaque utilisateur qui a exécuté une transaction sur Cronos pendant la fenêtre d'environ deux heures entre l'exploit et l'arrêt a vu son activité annulée. Les échanges sur les bourses décentralisées ont été défaits. Les transferts de jetons entre portefeuilles ont été annulés. Les interactions avec des contrats intelligents qui n'avaient rien à voir avec Tectonic ont été effacées de la chaîne canonique en tant que dommages collatéraux de la restauration de l'état.

Cronos n'a pas publié de données sur le nombre de transactions non liées à l'exploit qui ont été perdues. Les plus de 10 000 blocs effacés représentent environ deux heures d'activité réseau au débit normal de Cronos. Pour une chaîne qui avait enregistré plus de 100 millions de transactions depuis son lancement et qui soutenait plus de 500 développeurs, même deux heures représentent un volume significatif d'opérations légitimes.

L'asymétrie est frappante. Les déposants de Tectonic qui ont perdu des fonds à cause de l'exploit ont vu leurs soldes restaurés aux niveaux d'avant l'attaque. Mais quiconque a effectué un échange, un dépôt ou un retrait légitime pendant la fenêtre effacée a vu sa transaction annulée sans compensation ni même reconnaissance.

Cela crée une incitation étrange. Si vous êtes volé sur Cronos, les validateurs pourraient réécrire l'histoire pour vous dédommager. Si votre transaction légitime tombe dans la zone d'explosion du piratage de quelqu'un d'autre, vous la perdez. La restauration optimise pour un type de préjudice et en crée un autre.

Aucun ensemble de validateurs n'a expliqué comment ils pèsent ces intérêts concurrents. Le post-mortem de Cronos devrait aborder ce point. Savoir s'il le fera est une autre question.

Ce que la restauration signifie pour les développeurs sur Cronos

Les développeurs qui créent des applications sur Cronos sont désormais confrontés à une contrainte de conception qui n'existait pas avant le 30 août : tout état créé par leur application peut être effacé rétroactivement par consensus des validateurs.

Pour un simple échange de jetons, les conséquences sont ennuyeuses mais gérables. L'utilisateur peut soumettre à nouveau. Pour les applications qui interagissent avec des systèmes externes, les implications sont plus graves. Un processeur de paiement qui confirme une transaction Cronos et expédie un produit n'a aucun recours si la transaction est ensuite annulée. Un oracle qui pousse des données vers Cronos et déclenche des actions sur d'autres chaînes en fonction de la confirmation ne peut pas annuler ces actions.

Le problème s'aggrave pour les protocoles qui s'étendent sur plusieurs chaînes. Si un utilisateur dépose sur Cronos et que ce dépôt déclenche un mint sur une autre chaîne, une restauration de Cronos supprime le dépôt mais pas le mint. L'état inter-chaînes devient incohérent, et la réconciliation incombe à l'équipe du protocole, pas aux validateurs qui ont ordonné la restauration.

La réponse de Tatum illustre le coût d'infrastructure. L'entreprise a dû rejouer toutes les données de la chaîne à partir du bloc restauré pour remettre ses API en synchronisation. Chaque indexeur, sous-graphe et service de données qui suit Cronos a fait face à la même charge de resynchronisation. Pour les fournisseurs d'infrastructure opérant sur des dizaines de chaînes, soutenir une chaîne qui peut être restaurée à tout moment ajoute un coût opérationnel que les chaînes avec une finalité crédible n'imposent pas.

La coentreprise Trump Media et Crypto.com CRO treasury, qui a été résiliée le 7 août, avait proposé d'utiliser Cronos pour des actifs tokenisés. Si cet accord avait survécu jusqu'à l'exploit Tectonic, la restauration aurait effacé les positions de capitaux propres tokenisées. Ce scénario seul devrait donner à tout projet de tokenisation d'actifs réels une pause avant de choisir une chaîne où les validateurs peuvent réécrire l'histoire.

Les 6 millions de dollars qui prouvent la limite

Les 6 millions de dollars que l'attaquant a transférés vers Ethereum avant l'arrêt ont survécu au rollback. Ils se trouvent sur une chaîne que les validateurs de Cronos ne peuvent pas toucher.

C'est la contrainte physique à laquelle tout rollback est confronté. L'autorité d'une blockchain s'arrête à ses propres frontières. Une fois que la valeur traverse vers une autre chaîne, les règles de consensus de la chaîne réceptrice s'appliquent. Les validateurs d'Ethereum n'ont pas accepté le rollback de Cronos et n'ont aucune obligation de l'honorer. Les soldes Ethereum de l'attaquant sont définitifs d'une manière que ses soldes Cronos se sont avérés ne pas être.

Cet écart est important pour quiconque construit des applications inter-chaînes sur Cronos ou des réseaux similaires. Si une chaîne peut être rollbackée, toute valeur qui n'a pas quitté la chaîne avant l'arrêt risque d'être effacée. Les ponts deviennent la porte de sortie, et la vitesse de pontage devient une propriété de sécurité que les concepteurs de protocoles n'avaient pas prévue.

L'attaquant le savait. La première chose que les fonds volés ont faite a été de se déplacer vers Ethereum. La fenêtre d'environ deux heures entre l'exploit et l'arrêt était une course entre la vitesse de pontage de l'attaquant et la vitesse de coordination des validateurs. Les validateurs ont gagné la majeure partie. Mais 6 millions de dollars, ce n'est pas rien.

Que regarder

• Publication post-mortem de Cronos. L'ensemble des validateurs a promis une comptabilité complète de l'exploit, de la décision d'arrêt, du processus de rollback et du redémarrage. Jusqu'à ce que ce document apparaisse, la communauté ne peut pas évaluer si des garde-fous adéquats existaient ou si le rollback a suivi un processus de gouvernance défini.
• Traitement de la TVL et des déposants de Tectonic. La TVL est passée de 121,7 millions de dollars à 3 millions. Que les déposants reçoivent une compensation, un plan de redressement ou rien indiquera comment Cronos gère les défaillances de protocoles au sein de son écosystème.
• Comportement du prix du CRO après le rollback. Un ensemble de validateurs qui peut réécrire l'histoire devrait se négocier avec une décote de gouvernance par rapport aux chaînes où cela n'est pas possible. Que le CRO reflète cette décote montrera comment le marché évalue le risque d'immutabilité.
• Adoption du manuel de rollback par d'autres chaînes. MANTRA, Ontology et les chaînes Cosmos EVM ont toutes récemment été interrompues. Si l'une d'entre elles utilise Cronos comme précédent pour des rollbacks d'état, la pratique pourrait se normaliser sur les chaînes plus petites.
• Adoption de plafonds d'emprunt dans les protocoles de prêt DeFi. Kazmierczak de RedStone a identifié le correctif. Que les protocoles le mettent en œuvre ou continuent à lister des jetons de gouvernance à faible liquidité sans plafonds d'emprunt déterminera la fréquence à laquelle cette attaque exacte se reproduira.