La mise à jour sur l'incident de Cosmos Hub est claire : son propre réseau n'a pas été exploité. Les actifs volés sont arrivés depuis Neutron via le protocole de communication inter-blockchain (IBC) ; les validateurs du Hub ont ensuite suspendu leur chaîne et l'ont remise en ligne avec une modification strictement ciblée affectant un seul compte.

Cosmos Hub est la chaîne hub de l'écosystème Cosmos, et ATOM est son actif natif, mis en jeu auprès des validateurs pour aider à sécuriser le réseau. Neutron est une plateforme de contrats intelligents du même écosystème, et les deux chaînes sont reliées par IBC, le standard d'interopérabilité qui permet à des blockchains autrement indépendantes d'échanger des actifs et des messages. C'est cette connexion qui a mis les fonds volés à la portée des validateurs de Cosmos Hub et préparé le terrain pour la réponse d'urgence.

Trois pouvoirs souvent confondus dans une urgence blockchain

Une blockchain peut arrêter la production de blocs lorsqu'un nombre suffisant de validateurs cesse de signer des transactions, suspendant l'activité normale du réseau. L'épisode de Cosmos Hub a combiné trois capacités que les observateurs confondent fréquemment : l'arrêt de la production de blocs, la modification de l'état lors d'un redémarrage et la détention des actifs récupérés. Chacune comporte ses propres garanties et ses propres risques.

1. L'arrêt de la production de blocs

Les validateurs produisent et confirment de nouveaux blocs. Sur Cosmos Hub, le moteur de consensus CometBFT enregistre les blocs avec l'accord d'au moins deux tiers de la puissance de vote des validateurs, un poids déterminé par la quantité d'ATOM mise en jeu auprès de chaque validateur. Lorsqu'un nombre suffisant d'opérateurs cessent de signer, les transferts ordinaires et autres changements d'état ne peuvent plus être réglés sur la chaîne. Le résultat est un problème de vivacité plutôt qu'une intrusion : le réseau existe toujours, mais il est temporairement dans l'incapacité de progresser.

2. La modification de l'état lors du redémarrage

Un arrêt à lui seul ne déplace aucun fonds. Les validateurs de Cosmos Hub ont redémarré sur Gaia v28.3.0, le logiciel de nœud du Hub, en appliquant une modification d'état unique au bloc 33 086 741, avant que d'autres transactions ne soient traitées. Cette modification a transféré le solde restant d seule adresse liée à l'attaquant vers un multisig de récupération 4-sur-6.

Selon Cosmos Hub, le binaire corrigé n'a touché aucun autre solde, délégation ni fonds d'utilisateurs. L'intervention n'a pas utilisé la clé privée de l'attaquant et n'a pas annulé l'exploit Neutron sous-jacent. Les validateurs ont accepté d'exécuter le code mis à jour, et le réseau redémarré a accepté l'état modifié du Hub. Le Cosmos SDK prend en charge les migrations d'état lors des mises à niveau ; cette capacité ne devient toutefois significative que lorsque les opérateurs de validateurs se coordonnent pour l'exercer.

3. La détention des actifs récupérés

La modification d'état n'a pas envoyé les ATOM vers un portefeuille d'entreprise unique. L'adresse de récupération est contrôlée par Nansen, Keplr, Enigma, Silknodes, Kiln et Polkachu, avec quatre signatures requises pour déplacer les fonds. Cosmos Hub indique que les contributeurs de Neutron et les protocoles concernés élaborent un plan de récupération.

Il s'agit de pouvoirs distincts. Un ensemble de validateurs peut arrêter la production de blocs sans toucher à un compte, et il peut approuver une modification d'état ciblée sans décider de la manière dont les actifs récupérés seront finalement distribués. Réduire ces trois actions à une simple « gel de portefeuille » masque à la fois les garanties et les risques impliqués.

L'arrêt a stoppé Cosmos Hub, mais pas toutes les voies de règlement

La partie la plus instructive de l'incident est aussi celle qui rend la récupération moins nette. Le balayage de 1 227 121 ATOM n'a couvert que le solde présent dans l'adresse liée à l'attaquant au bloc d'arrêt. Les actifs qui ont atteint l'adresse ensuite sont restés hors de son périmètre.

Unchained et CryptoSlate ont rapporté que 168 991 ATOM issus d'un swap THORChain non exécuté sont retournés à l'adresse peu après le redémarrage, arrivant seulement après que la modification d'état unique avait déjà été exécutée.

IBC avait transporté les ATOM volés de Neutron vers Cosmos Hub, tandis que THORChain, un protocole de swap inter-chaînes, constituait une voie de règlement distincte. L'épisode montre pourquoi les équipes de récupération doivent cartographier les swaps en attente, les transferts par pont, les jetons wrappés et les dépôts sur les exchanges, en plus du solde visible sur la chaîne qu'elles contrôlent. Arrêter un réseau n'annule pas l'activité déjà en attente ailleurs.

Quatre vérifications avant de faire confiance à une récupération

• Qui peut arrêter le réseau ? La concentration de la puissance de vote compte plus que le nombre brut de validateurs.
• Qu'a-t-on exactement modifié ? Le réseau devrait divulguer le compte concerné, la version du code, la hauteur de redémarrage et le périmètre du correctif.
• Qui détient les actifs récupérés ? Les signataires, le seuil de signatures et le processus de distribution devraient être identifiables publiquement.
• Que reste-t-il hors de l'intervention ? Les transferts inter-chaînes, les swaps en attente et les destinations hors chaîne devraient êtreinés avant de déclarer une récupération terminée.

Une chaîne dépourvue de réponse exploitable peut laisser les victimes sans aucune voie de récupération. Une chaîne dotée de pouvoirs d'urgence étendus et non divulgués donne aux utilisateurs moins de certitude que les transactions accomplies sont réellement définitives. La norme utile est plus étroite : l'autorité d'urgence devrait comporter un déclencheur public, un périmètre défini et un registre vérifiable.

Ce que Cosmos a montré, et ce qui reste en suspens

Cosmos a divulgué suffisamment d'informations pour examiner le périmètre de son intervention : le compte concerné, la version du code, la hauteur de redémarrage, l'adresse de récupération et les signataires. Le test restant est de savoir si le plan de récupération offre la même clarté aux victimes dont les actifs ne figurent pas dans ce multisig.

Une action d'urgence peut protéger les utilisateurs après un exploit, mais son autorité, son code et ses limites devraient être visibles avant qu'une crise ne force le réseau à les utiliser. C'est la leçon durable de la récupération des ATOM : la finalité a davantage de poids lorsque ses exceptions sont comprises à l'avance.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou d'investissement. Les rapports sur l'incident et les plans de récupération peuvent évoluer à mesure que de nouvelles mises à jour techniques et de gouvernance sont publiées.

Source : Coindoo