Le Cosmos Hub n'a pas été piraté

L'incident n'a pas compromis le Cosmos Hub, ni l'ensemble des blockchains de l'écosystème Cosmos au sens large. La faille se trouvait dans cosmos/evm, un logiciel partagé qui permet à des réseaux indépendants basés sur Cosmos d'exécuter des applications compatibles Ethereum.

Selon le post-mortem de Cosmos Labs, six réseaux utilisant ce logiciel ont été exploités entre le 20 et le 25 août. MANTRA, TAC et KiiChain ont été nommés dans la chronologie détaillée ; le document n'a pas identifié publiquement les trois autres.

Cette distinction est importante : elle empêche qu'une défaillance d'un logiciel partagé ne devienne un titre trompeur de « piratage de Cosmos ». La même règle de périmètre s'appliquait à l'exploit du bridge de The Sandbox — une intégration compromise ne signifiait pas que l'ensemble du protocole sous-jacent avait été piraté.

Les attaquants ont converti 5,72 millions de dollars par deux voies

Cosmos Labs a estimé que les attaquants avaient échangé environ 2,87 millions de dollars via des plateformes décentralisées, sur la base des prix du 19 août. L'organisation a décrit ce chiffre comme une estimation qui n'avait pas fait l'objet d'un audit indépendant. 2,85 millions de dollars supplémentaires auraient été vendus via des plateformes d'échange centralisées, portant le total converti ou vendu à environ 5,72 millions de dollars.

Cosmos Labs a indiqué que les chaînes touchées avaient signalé que les comptes sur les plateformes centralisées avaient été gelés pendant que les enquêtes policières se poursuivaient. Le total de 5,72 millions de dollars convertis ne changera pas, mais la récupération des soldes gelés sur les plateformes d'échange pourrait réduire la perte nette finale.

La réponse a également limité les dégâts. Cosmos Labs a travaillé avec 13 autres réseaux potentiellement exposés pour les corriger, les arrêter ou les protéger autrement, sans autres incidents signalés, et a coordonné ses actions avec 40 chaînes au total.

Comment une incohérence comptable exposait des soldes valides

La vulnérabilité provenait de deux parties du logiciel calculant les soldes différemment. Le StateDB de Cosmos EVM ne suivait que le montant qu'un compte pouvait dépenser immédiatement. Or, un compte de vesting Cosmos pouvait détenir à la fois des jetons disponibles et verrouillés, et le système de staking permettait de déléguer des jetons verrouillés.

Lorsque le logiciel soustrayait le montant total délégué du solde disponible, plus petit, un dépassement arithmétique inférieur (underflow) non vérifié pouvait ramener le résultat à un nombre proche de 2^256. Un attaquant pouvait alors combiner cet underflow avec un dépassement supérieur (overflow) lors d'un transfert. Ce type de bug — underflow et overflow d'entiers dans l'arithmétique non signée — est une catégorie bien documentée de vulnérabilité de contrats intelligents et de blockchain, et c'est l'une des raisons pour lesquelles les langages modernes de contrats intelligents incluent l'arithmétique vérifiée par défaut.

La séquence ne créait pas d'augmentation durable de l'offre. Elle pouvait en revanche réduire à zéro le compte d'une victime au solde élevé et laisser à l'attaquant le solde précédemment détenu par ce compte. Cela faisait de la faille un risque direct de vol de fonds, et non un simple affichage inexact ou une bizarrerie comptable.

L'avertissement est arrivé près de quatre mois avant les attaques

Le vol a été le point final d'une séquence plus longue. L'erreur décisive a eu lieu lors de l'évaluation initiale, des mois avant que quiconque n'exploite le code.

Cosmos Labs a traité une menace de production comme une maintenance de routine

La preuve de concept initiale utilisait une chaîne configurée avec six décimales. Cosmos Labs a testé des configurations à 18 décimales, n'a pas pu reproduire le résultat et a conclu que les réseaux de production connus étaient en sécurité. Cette conclusion était erronée : l'incohérence de soldes sous-jacente pouvait affecter chaque chaîne Cosmos EVM, quelle que soit sa configuration décimale.

Une fois que des rapports ultérieurs ont établi l'ampleur réelle, Cosmos Labs savait que des fonds de production étaient exposés. Elle a choisi un processus de correction silencieuse destiné à mettre le code corrigé entre les mains des opérateurs sans publier de détails pouvant aider les attaquants.

Les versions corrigées étaient disponibles environ 20 heures avant la première attaque connue, mais leurs notes ne mentionnaient pas la gravité et n'indiquaient pas aux opérateurs que retarder la mise à niveau pouvait exposer les fonds des utilisateurs. Les opérateurs pouvaient voir que les nouvelles versions contenaient des correctifs de sécurité, mais les notes n'expliquaient pas que les chaînes non corrigées risquaient une perte de fonds.

La divulgation est devenue publique le lendemain matin. Une pull request dans un fork en aval décrivait le chemin d'exploitation et identifiait les versions concernées environ 12 heures avant la première attaque. Cette pull request publique a donné aux attaquants un chemin plus clair, et Cosmos Labs avait déjà laissé les opérateurs sans avertissement expliquant l'urgence.

Le dilemme auquel Cosmos Labs a été confrontée est bien connu en sécurité open source : divulguer pleinement une vulnérabilité peut armer les attaquants avant que chaque opérateur ait corrigé, tandis que rester silencieux peut empêcher les opérateurs de juger de l'urgence. Les pratiques de divulgation coordonnée de l'industrie logicielle cherchent précisément à équilibrer ce compromis, et cet incident montre ce qui se passe lorsque l'équilibre penche du mauvais côté dans les deux sens.

Cosmos ne connaissait pas toutes les chaînes à avertir

Même un processus d'avertissement privé ne fonctionne que si les mainteneurs savent qui contacter. Cosmos Labs a indiqué que l'écosystème compte plus de 115 chaînes publiques connues mais ne dispose pas d'un registre complet. Pendant la réponse, elle a découvert 11 déploiements Cosmos EVM qui n'étaient pas enregistrés dans ses canaux de sécurité.

Cosmos Labs maintenait le code partagé sans connaître tous les réseaux qui l'avaient déployé. Cette lacune a rendu difficile la remise d'un avertissement confidentiel avant la publication d'informations suffisantes pour que les équipes des chaînes reconnaissent elles-mêmes la menace.

La chronologie de la réponse montre aussi pourquoi le message devait être explicite. Après que MANTRA a signalé la première attaque, Cosmos Labs a envoyé son premier e-mail critique sécurisé environ deux heures plus tard. TAC a été attaquée environ 45 heures après MANTRA malgré les communications antérieures, et les recommandations ont ensuite été renforcées jusqu'à conseiller à toutes les chaînes Cosmos EVM de s'arrêter.

Pour les chaînes Cosmos EVM indépendantes, publier le code était insuffisant. Leurs équipes devaient encore apprendre que la mise à niveau était urgente et coordonner une version avec rupture d'état.

Les chaînes vulnérables doivent se mettre à niveau ou s'arrêter

L'avis de sécurité critique indique comme concernées les versions antérieures à 0.6.2 et les versions de 0.7.0 jusqu'à 0.7.2 exclue. Les opérateurs doivent passer à Cosmos EVM 0.6.2, 0.7.2 ou une version ultérieure.

Il n'existe aucune solution de contournement par simple configuration. La désactivation du précompile de staking supprime le déclencheur principal décrit dans l'avis, mais Cosmos Labs ne considère pas cette mesure comme un substitut à la mise à niveau. Une chaîne incapable d'installer immédiatement une version corrigée doit s'arrêter.

BTCPay a récemment publié des instructions similaires, spécifiques aux versions après avoir confirmé un vol de fonds : mettre à jour les installations concernées ou les mettre hors ligne. Dans les deux cas, les conseils utiles sont concrets car le risque dépend de la version du logiciel utilisée.

La prochaine correction concerne le processus de divulgation

Cosmos Labs a déclaré qu'elle élargirait le triage des vulnérabilités au-delà de la preuve de concept du rapporteur, développerait son réseau de contacts de sécurité et vérifierait que ces contacts restent joignables. Elle prévoit également des normes plus claires pour les correctifs privés et silencieux, notamment quand les mainteneurs devraient recommander un arrêt plutôt qu'une mise à niveau coordonnée. Un audit externe de ses pratiques de sécurité opérationnelle est également prévu.

Ces changements traitent la partie de l'incident qu'un autre correctif de code ne peut pas résoudre : comment un groupe décentralisé de chaînes indépendantes reçoit, comprend et agit sur un avertissement sensible au facteur temps. La première évaluation a cerné le bug trop rapidement. Le processus de publication ultérieur a dissimulé l'urgence à certaines des personnes censées installer le correctif. Le code était disponible avant la première attaque. Ce qui manquait à plusieurs opérateurs, c'était un avertissement indiquant qu'attendre pourrait coûter les fonds des utilisateurs.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement ou de sécurité. Les opérateurs de réseaux doivent consulter l'avis officiel de Cosmos EVM et vérifier la version qu'ils ont déployée.

Source : Coindoo