Hack Ledger Connect Kit — Explication et Analyse

L’incident de sécurité qui a frappé Ledger le 14 décembre 2023 met en évidence la complexité de la gestion des bibliothèques tierces dans les environnements open source. Ledger, une entreprise réputée pour ses portefeuilles hardware de cryptomonnaies, a été victime d’une cyberattaque impliquant son Wallet Kit. Ce cas d’étude révèle comment une simple mise à jour NPM peut conduire à la propagation d’un logiciel malveillant à grande échelle.

Contexte

Ledger, connu pour ses wallets hardware, offre une bibliothèque NPM : “Connect Kit”, utilisée par des protocoles de finance décentralisée telle que Lido, Metamask, Coinbase ou Sushi, cette bibliothèque facilite la connexion entre les DApps et les produits Ledger. Les pirates, après avoir hacké le compte NPM d’un ancien employé, ont publié une nouvelle version du logiciel sur la plateforme open source NPMJS. Cette nouvelle version permettait de rediriger les fonds des utilisateurs vers le wallet des pirates.

L’attaque

Les cybercriminels ont implanté un malware, baptisé “Angel Drainer”, dans la bibliothèque Connect Kit de Ledger en le publiant sur NPMJS. Ce malware visait à vider les portefeuilles électroniques en induisant les utilisateurs à autoriser des transactions malicieuses. Les versions 1.1.5 et 1.1.6 de cette bibliothèque ont été modifiées pour y inclure un package npm additionnel, fonctionnant comme un outil de “siphonnage”. Ce fichier malveillant a été actif pendant environ 5 heures, avec une fenêtre d’exploitation effective de 2 heures pour le vol de fonds, totalisant une perte estimée à environ 600 000 dollars. Ledger a déployé une version sécurisée et vérifiée du Ledger Connect Kit, numérotée 1.1.8.

Réaction de Ledger

Pour renforcer la sécurité, Ledger a pris plusieurs mesures. Premièrement, ils ont passé l’équipe du projet Connect Kit en mode “lecture seule” sur NPMJS (cela signifie que les développeurs ne peuvent plus modifier directement le code source). De plus, les secrets de publication, qui sont essentiels pour mettre à jour le logiciel, ont été renouvelés sur le dépôt GitHub de Ledger.

Parallèlement, Ledger a émis un rappel à ses utilisateurs, leur conseillant de vérifier les détails d’une transaction avant validation. Cette précaution est particulièrement importante pour les transactions dites “aveugles”, où les détails ne sont pas pleinement visibles. Pour ces transactions, Ledger suggère d’utiliser un deuxième portefeuille ou de procéder à une analyse manuelle de la transaction.

Les vulnérabilités associées aux bibliothèques tierces dans l’écosystème open source

Pour traiter les vulnérabilités associées à l’utilisation de bibliothèques tierces dans les environnements open source, il est crucial de considérer plusieurs aspects techniques. D’abord, la dépendance transitive : dans les projets open source, l’utilisation de bibliothèques tierces entraîne souvent une chaîne complexe de dépendances, où chaque bibliothèque peut à son tour dépendre d’autres packages. Cela complique la vérification de la sécurité à chaque niveau, car une faille dans un seul maillon peut compromettre l’ensemble du projet.

Beaucoup de bibliothèques open source ne sont pas signées cryptographiquement, rendant difficile la vérification de l’intégrité et de l’authenticité des bibliothèques téléchargées.

La gestion des bibliothèques tierces est également un aspect critique. L’utilisation de versions obsolètes peut exposer le projet à des vulnérabilités connues, tandis que des mises à jour trop fréquentes peuvent introduire de nouvelles failles. Il est donc essentiel de trouver un équilibre dans la gestion des versions pour maintenir la sécurité et l’efficacité du projet.

Axes d’Amélioration :

1. Utilisation de Scanners de Vulnérabilités : Intégrer des outils comme Snyk, OWASP Dependency-Check, ou Black Duck pour scanner automatiquement les bibliothèques tierces à la recherche de vulnérabilités connues.
2. Intégration Continue de la Sécurité (CI/CD) : Mettre en place des pipelines d’intégration et de déploiement continus qui incluent des étapes de sécurité, comme l’analyse statique et dynamique du code.
3. Gestion Fine des Permissions : Utiliser des outils comme npm audit ou yarn audit pour identifier les packages avec des permissions excessives ou suspectes.
4. Signature Cryptographique des Packages : Encourager les projets open source à signer cryptographiquement leurs packages pour assurer l’authenticité et l’intégrité.
5. Gestion Rigoureuse des Mises à Jour : Mettre en place des politiques strictes pour la mise à jour des bibliothèques, en incluant des tests de régression pour s’assurer que les mises à jour ne brisent pas les fonctionnalités existantes ni n’introduisent de nouvelles vulnérabilités.
6. Audit du Code Source : Réaliser des audits de code source réguliers, en particulier pour les bibliothèques critiques, afin de détecter d’éventuels problèmes de sécurité.
7. Révision de Code Communautaire : Favoriser une culture de revue de code au sein de la communauté, où les mises à jour des bibliothèques sont examinées par plusieurs pairs avant d’être intégrées.