Le package Injective SDK malveillant cible les clés privées et les seed phrases

Une version malveillante d’un outil logiciel utilisé par les développeurs Injective a été conçue pour collecter les clés privées de portefeuille et les phrases de récupération, suscitant des inquiétudes pour les applications qui traitaient des informations sensibles de portefeuille via la version concernée. Des pirates ont compromis un package logiciel utilisé par les développeurs créant des portefeuilles et des applications pour la blockchain Injective, en ajoutant du code capable de collecter secrètement les identifiants des portefeuilles crypto.

L’entreprise de sécurité Socket a découvert le code malveillant dans la version 1.20.21 de @injectivelabs/sdk-ts, un package qui aide les applications à se connecter à Injective et à gérer les fonctions liées au portefeuille. Le package reçoit normalement environ 50 000 téléchargements par semaine, bien que ce chiffre inclue toutes les versions et ne représente pas le nombre de personnes affectées par l’incident.

Socket a indiqué que la version compromise avait été téléchargée environ 310 fois. Cependant, un téléchargement ne signifie pas automatiquement qu’une clé de portefeuille a été exposée. Le code dangereux aurait dû s’exécuter pendant qu’une application manipulait une clé privée ou une phrase de récupération. Aucun chiffre confirmé concernant le nombre de portefeuilles affectés n’a été publié, et il n’existe aucune preuve publique que des fonds ont été volés.

L’incident n’impliquait pas une violation de la blockchain Injective elle-même. Au lieu de cela, les attaquants ont ciblé un composant logiciel de confiance utilisé par les développeurs, une méthode communément décrite comme une attaque sur la chaîne d’approvisionnement logicielle.

Le code malveillant était caché dans un outil de confiance

Les développeurs s’appuient souvent sur des packages logiciels prêts à l’emploi plutôt que d’écrire chaque partie d’une application à partir de zéro. Ces packages peuvent gérer des tâches telles que la connexion à une blockchain, la création de portefeuilles et la signature de transactions. Dans ce cas, le code malveillant a été placé dans un package officiel Injective et était conçu pour s’activer lorsqu’une application traitait des informations sensibles de portefeuille. Socket a déclaré qu’il pouvait capturer une clé privée ou une phrase de récupération mnémonique et tenter d’envoyer les données ailleurs tout en dissimulant l’activité sous forme de rapports techniques ordinaires.

Une clé privée donne à son détenteur le contrôle du portefeuille crypto associé. Une phrase de récupération peut être utilisée pour restaurer le même portefeuille sur un autre appareil. Contrairement à un mot de passe de compte normal, ces identifiants ne peuvent pas simplement être réinitialisés après leur exposition.

Les compromissions de clés privées sont devenues l’une des formes d’attaques crypto les plus dommageables, car les criminels peuvent prendre le contrôle direct des portefeuilles sans avoir besoin de briser la blockchain sous-jacente. Une récente revue de la sécurité a révélé que les incidents liés aux clés privées représentaient environ 40 % des pertes enregistrées dans l’ensemble de données examiné. L’incident Injective montre également pourquoi les attaquants ciblent de plus en plus les logiciels et plateformes auxquels les utilisateurs font déjà confiance. Un nom de package familier, un compte de développeur établi ou une application reconnue peuvent faire paraître l’activité malveillante légitime et réduire les chances que les utilisateurs la remettent en question.

Socket a indiqué que les modifications non autorisées avaient été soumises via le compte GitHub d’un développeur ayant un historique établi de contributions au projet Injective. Le véritable propriétaire du compte a ensuite détecté l’activité et annulé les modifications. Le rapport disponible n’identifie pas l’attaquant ni n’explique comment le compte a été accédé.

Dix-sept packages connexes ont augmenté l’exposition possible

Le code voleur de portefeuille se trouvait dans la version 1.20.21 du package principal Injective SDK. Cependant, 17 autres packages au sein de la collection npm Injective ont été publiés avec des liens vers la même version affectée. Cela signifiait que certains développeurs auraient pu recevoir le logiciel compromis indirectement. Une application peut avoir installé un package Injective, tandis que ce package importait automatiquement le SDK affecté en arrière-plan.

L’incident ne doit donc pas être décrit comme 18 packages séparément infectés. Les preuves disponibles montrent que le SDK principal contenait la fonctionnalité malveillante, tandis que 17 packages connexes dépendaient directement ou indirectement de cette version. Socket a indiqué que la version affectée a été marquée comme obsolète après la découverte de la compromission et qu’une version propre a été publiée. Au moment du rapport de Socket, cependant, la version compromise n’avait pas été complètement supprimée de npm, et le matériel de publication connexe restait disponible via GitHub.

Les rapports diffèrent également quant à la date exacte de l’incident. La chronologie publiée par Socket fait référence au 8 juin, tandis que certains rapports secondaires situent l’activité en juillet. Comme le mois n’a pas été déterminé de manière indépendante, la date exacte doit être attribuée à la source plutôt qu’énoncée comme un fait incontesté.

Les développeurs et les utilisateurs de portefeuilles affectés doivent remplacer les identifiants exposés

Il a été conseillé aux développeurs qui ont utilisé la version 1.20.21, soit directement, soit via un autre package Injective, de supposer que les identifiants de portefeuille traités par le logiciel affecté ont pu être exposés.

Les actions recommandées incluent :

• Vérifier les fichiers de projet et les enregistrements d’installation pour la version 1.20.21.
• Mettre à jour les packages Injective affectés vers une version propre vérifiée.
• Effacer les copies de packages stockées et reconstruire les applications.
• Créer de nouvelles clés privées et phrases de récupération.
• Déplacer les actifs loin des portefeuilles qui utilisaient des identifiants gérés par le logiciel affecté.
• Examiner l’activité du portefeuille pour détecter les transactions non autorisées.
• Révoquer les permissions précédemment accordées par les portefeuilles potentiellement exposés.

La mise à jour du package seul peut ne pas protéger un portefeuille si ses identifiants ont déjà été copiés. Dès qu’une tierce partie obtient une clé privée ou une phrase de récupération, l’ancien portefeuille ne doit plus être considéré comme sécurisé. Les utilisateurs de portefeuilles doivent également examiner les permissions qu’ils approuvent. Dans un cas distinct, un attaquant a volé environ 92 000 $ en Tether Gold après qu’une victime ait signé une demande de permission malveillante, montrant que les criminels n’ont pas toujours besoin d’obtenir directement une seed phrase pour s’emparer des actifs.

Bien que ce cas ait utilisé une technique différente, il met en lumière le même problème plus large : la sécurité crypto dépend non seulement de la blockchain, mais aussi des logiciels, des approbations et des services entourant un portefeuille. Il n’y a actuellement aucune preuve que la blockchain Injective ait été piratée, que chaque portefeuille Injective ait été mis en danger ou qu’un montant confirmé de cryptomonnaie ait été volé. Le danger connu est limité aux applications qui ont installé le package compromis et traité les identifiants de portefeuille through celui-ci.