Cet article analyse l'attaque contre Ledger comme un exemple de la façon dont un spear phishing a conduit à une attaque de la chaîne d'approvisionnement logicielle (SSC) sur l'outil de connexion logicielle utilisé par les portefeuilles matériels de l'entreprise, permettant à l'acteur de drainer des sommes d'une valeur d'au moins 600,000 XNUMX $.
Cette attaque intervient à la fin d’une année marquée par des incidents liés à la chaîne d’approvisionnement. Dans cet article, nous analysons l’attaque, son impact, la manière dont elle a été gérée et les leçons qui pourraient en être tirées.
Ledger et ses utilisateurs de portefeuilles matériels sont des cibles évidentes pour les cybercriminels. Les draineurs de portefeuille attaquaient les utilisateurs de Ledger via des tentatives de phishing sur les applications frontales des applications de cryptographie, et les criminels ont besoin de connaître les coordonnées des utilisateurs pour mener les campagnes de phishing. Ledger avait un violation de données d’ici juillet 2023 en plus de faire partie du Vol de données en septembre 2020 sur leur e-commerce Shopify, un incident aux conséquences importantes. La poste "Mise à jour : efforts pour protéger vos données et poursuivre les spammeurs» montre à quel point ces violations ont été profondes.
Ledger doit prendre la sécurité au sérieux (c'est un élément clé de son activité), avec un laboratoire de recherche interne (donjon) manutention certification de sécurité des appareils bounty de bogue programme, bulletins de sécurité et modélisation des menaces. Jusqu'ici, tout va bien …
Comment l'attaque a été menée
Ledger a détecté un exploit à l'aide de Ledger Kit de connexion DApp le jeudi 14 décembre 2023. Cet exploit a injecté du code malveillant dans des applications décentralisées (DApps) basées sur Ethereum qui utilisaient Ledger Connect Kit, incitant les utilisateurs à signer des transactions qui drainent leur portefeuille.
L’exploit a été rapidement repéré et une solution a été mise en œuvre peu de temps après. Entre-temps, un faible nombre d’utilisateurs ont été victimes de l’attaque et ont signé des transactions vidant leur portefeuille.
L'attaque a commencé lorsqu'un ancien employé de Ledger a été victime d'une attaque de phishing qui a permis d'accéder à son compte NPM via le jeton de session. Les attaquants ont publié des versions malveillantes du @ledgerhq/connect-kit (1.1.5, 1.1.6 et 1.1.7, maintenant retirés). Les attaquants pourraient exécuter du code arbitraire avec le même niveau d'autorisations que l'application de portefeuille : les attaquants peuvent immédiatement drainer les fonds des utilisateurs sans interaction, distribuer de nombreux liens de phishing pour tromper les utilisateurs ou exploiter la panique des utilisateurs en les convainquant de transférer leurs actifs vers une nouvelle adresse. , entraînant une perte d'actifs due au téléchargement d'un faux portefeuille.
Les frontaux de portefeuille (dApps) utilisaient généralement le chargeur-kit-de-connexion package de Ledger pour charger le Connect Kit au moment de l’exécution à partir d’un CDN JavaScript (jsDelivr). Malheureusement, l'URL https://cdn.jsdelivr.net/npm/@ledgerhq/connect-kit@1 n'épinglait pas la version exacte (1.1.4 à l'époque), donc lorsque les versions malveillantes étaient téléchargées, elles étaient servies (et mises en cache) par le CDN. Et aucune somme de contrôle n'a été utilisée pour garantir que la ressource téléchargée à partir du CDN était bien celle attendue (qui doit être utilisée lors de la distribution du code à partir d'un CDN). Ce schéma basé sur une somme de contrôle est nommé Intégrité des sous-ressources (ISR).
Le code injecté a probablement manipulé les données de transaction, incitant les utilisateurs à confirmer les paiements manipulés. Par exemple, un utilisateur approuvant un paiement symbolique pour activer les fonctionnalités d'une application peut avoir vu à la place une approbation pour un paiement à l'adresse du pirate informatique. Quelle que soit la sécurité du portefeuille matériel, les fonds ont été épuisés.
Découverte et enquête
Différents utilisateurs ont commencé à publier des messages sur X (alias Twitter) indiquant que le frontal de Zapper « avait été détourné ». Le mérite revient à Mathew Lilley, le CTO du cryptotrader Sushi, qui a été le premier à mettre en garde dans un après Twitter qu'un « connecteur Web3 couramment utilisé » a été compromis. Plus tard, il a souligné LedgerHQ/kit de connexion comme bibliothèque compromise, et a donné une première évaluation, un peu brutalement :
Qu'est-il arrivé?
- Je suis un logiciel 🦇🔊 (@MatthewLilley) 14 décembre 2023
En bref, @Registre commis une série de terribles erreurs.
1. Ils chargent JS depuis un CDN.
2. Ce ne sont pas des JS chargés avec verrouillage de version.
3. Leur CDN a été compromis.
J'éviterais d'utiliser AUCUNE dApp jusqu'à ce que leurs équipes confirment qu'elles ont atténué l'attaque. https://t.co/a3brXNQSx9
L'utilisateur 0xViva a ouvert un ticket dans le dépôt du projet GitHub : [URGENT] Ce référentiel utilise une version malveillante du package npm @ledgerhq/connect-kit, 1.1.7.
Le 15 décembre 2023, le formulaire de sécurité blockchain SlowMost a publié un poste d'analyse donnant tous les détails sur les versions malveillantes.
Le portefeuille matériel Ledger n’a pas été compromis, seul le kit Ledger Connect. Cependant, étant donné que de nombreuses applications utilisent cette bibliothèque, telles que SushiSwap, Zapper, MetalSwap, Harvest Finance, Revoke.cash, etc., l'ampleur de l'impact a été importante. Selon bittrace.io, certaines victimes, paniquées, ont tenté de transférer des actifs vers une nouvelle adresse, mais ont téléchargé une fausse application de portefeuille !
Le même jour, Jameson Lopp précise tweeté sur les failles qui ont permis à l’attaque de réussir :
Il semble que l'incident de sécurité d'aujourd'hui soit le point culminant de 3 échecs distincts chez Ledger :
- Jameson Lopp (@lopp) 14 décembre 2023
1. Chargement aveugle du code sans épingler une version spécifique ni une somme de contrôle.
2. Ne pas appliquer les « règles à 2 hommes » concernant la révision et le déploiement du code.
3. Ne pas révoquer l'accès des anciens employés.
Comment l'incident a été géré
Le PDG de Ledger, Pascal Gauthier, a publié le jour même de l'attaque un lettre de divulgation donner plus de détails sur l'incident, ce qui est vraiment une bonne chose : se cacher la tête dans le sable comme une autruche est la pire façon de gérer tout incident de cybersécurité.
La structure de la lettre est intéressante : elle a rapidement reconnu l'existence de versions malveillantes de la bibliothèque drainant de l'argent, ce qui est une bonne chose (nier la réalité est un non-sens) :
« Aujourd'hui, nous avons rencontré un exploit sur le Ledger Connect Kit, une bibliothèque Javascript qui implémente un bouton permettant aux utilisateurs de connecter leur appareil Ledger à des DApp tiers (sites Web connectés à un portefeuille).
Cet exploit est le résultat d'un ancien employé victime d'une attaque de phishing, qui a permis à un acteur malveillant de télécharger un fichier malveillant sur le NPMJS de Ledger (un gestionnaire de packages pour le code Javascript partagé entre les applications).
Nous avons travaillé rapidement, aux côtés de notre partenaire WalletConnect, pour remédier à l'exploit, en mettant à jour le NPMJS pour supprimer et désactiver le code malveillant dans les 40 minutes suivant sa découverte. Il s’agit d’un bon exemple de la collaboration rapide du secteur pour relever les défis de sécurité.
Quoi? Un ancien employé bénéficiant de droits de publication n'a-t-il pas vu ses informations d'identification sur NPM révoquées ?
Le PDG a ensuite énuméré les contrôles de sécurité en place, mais a laissé entendre que quelque chose n'allait pas avec l'accès au NPM :
« Maintenant, j'aimerais expliquer pourquoi cela s'est produit, comment nous allons améliorer nos pratiques de sécurité pour atténuer ce risque spécifique à l'avenir, et partager nos recommandations à l'industrie, afin que nous puissions être plus forts ensemble.
Le standard Chez Ledger, aucune personne ne peut déployer de code sans une vérification par plusieurs parties. Nous disposons de contrôles d'accès rigoureux, de vérifications internes et de signatures multiples pour la plupart de nos développements. C'est le cas dans 99 % de nos systèmes internes. Tout employé qui quitte l'entreprise se voit retirer son accès à tous les systèmes Ledger.
Il s’agit d’un malheureux incident isolé. Cela nous rappelle que la sécurité n'est pas statique et que Ledger doit continuellement améliorer nos systèmes et processus de sécurité. Dans ce domaine, Ledger mettra en œuvre des contrôles de sécurité plus stricts, reliant notre build pipeline qui implémente des règles strictes software supply chain security au canal de distribution du NPM. »
Eh bien, il semblait que le compte NPM autorisé à publier de nouvelles versions de la bibliothèque avait des contrôles de sécurité moins stricts que les autres parties de leur infrastructure logicielle. Incident isolé dû à la malchance ?
La fin de la lettre est plus standard section d'engagement avec les autorités, « déclaration sous contrôle » et excuses :
« Ledger s'est engagé auprès des autorités et fait tout ce qui est en son pouvoir pour aider à mesure que cette enquête se déroule. Ledger aidera les utilisateurs concernés à retrouver ce mauvais acteur, à le traduire en justice, à suivre les fonds et à travailler avec les forces de l'ordre pour aider à récupérer les actifs volés auprès du pirate informatique. Nous regrettons profondément les événements qui se sont déroulés aujourd’hui pour les personnes concernées.
La situation est désormais sous contrôle et la menace est passée. Nous comprenons la panique que cela a provoquée pour la communauté et l’écosystème dans son ensemble.
La lettre annexe un calendrier, qui permet aux utilisateurs de comprendre comment l'incident a été découvert, quelles mesures spécifiques de confinement et de remédiation ont été prises et comment les dommages causés aux utilisateurs concernés seront récupérés/indemnisés. Il s’agit de la partie la plus spécifique aux pièces :
« Ce matin, CET, un ancien employé de Ledger a été victime d'une attaque de phishing qui a permis d'accéder à son compte NPMJS. L'attaquant a publié une version malveillante du Ledger Connect Kit (affectant les versions 1.1.5, 1.1.6 et 1.1.7). Le code malveillant utilisait un projet WalletConnect malveillant pour rediriger les fonds vers un portefeuille de pirate informatique. Les équipes technologiques et de sécurité de Ledger ont été alertées et un correctif a été déployé dans les 40 minutes suivant la prise de conscience de Ledger. Le fichier malveillant est resté actif pendant environ 5 heures, mais nous pensons que la fenêtre pendant laquelle les fonds ont été drainés était limitée à une période de moins de deux heures.. Ledger s'est coordonné avec WalletConnect qui a rapidement désactivé le projet malveillant. La version 1.1.8 authentique et vérifiée du Ledger Connect Kit se propage désormais et peut être utilisée en toute sécurité.
Pour les constructeurs qui développent et interagissent avec le code du Ledger Connect Kit : l'équipe de développement du kit de connexion sur le projet NPM est désormais en lecture seule et ne peut pas diffuser directement le package NPM pour des raisons de sécurité. Nous avons effectué une rotation en interne des secrets à publier sur le GitHub de Ledger. Développeurs, veuillez vérifier à nouveau que vous utilisez la dernière version, 1.1.8.
Grand livre, avec PortefeuilleConnect et nos partenaires, ont signalé l'adresse du portefeuille du mauvais acteur. L'adresse est désormais visible sur Réduction de la chaîne. Tether a gelé l'USDT du mauvais acteur.
Selon cela, le confinement a été rapide puisque le projet malveillant WalletConnect destiné au réacheminement des fonds a été rapidement désactivé. Mais même avec cela, certains portefeuilles ont été épuisés.
Conséquences : comment l'industrie a réagi
Certains utilisateurs ont exprimé leur colère contre Ledger pour n'avoir pas réussi à empêcher la compromission, tandis que d'autres ont mis en garde contre les dangers de s'appuyer sur des bibliothèques tierces.
L’industrie de la cybersécurité occupe une niche dans le cybercoin. Les campagnes de drainage du portefeuille sont bien connues et utilisent principalement des sites de phishing pour tromper les utilisateurs finaux. L'activité SaaS habituelle (Scam-as-a-Service) compte des acteurs spécialisés dans le drainage du portefeuille, comme le vendeur d'escroquerie. Égouttoir Inferno qui arrêt annoncé des opérations en novembre 2023. Cela semble de toute façon être un faux drapeau, selon l'activité récente observée dans Dune's @arnaquesniffer. Le schéma qu'ils suivent a été expliqué par ce poste du Groupe-IB :
Certains analystes ont donné des indications sur ce qui n’a pas permis de rendre l’attaque possible. Ce commentaire de l'utilisateur brianddk dans le ticket sur le référentiel du projet nous donne un aperçu de la cause première :
A commentaire d'un autre utilisateur, HenryQW, a souligné la deuxième chose qui rendait les versions malveillantes capables de se propager via CDN :
Il est trop tôt pour envisager des initiatives à long terme visant à renforcer la résistance des interfaces des portefeuilles cryptographiques face aux attaques de phishing. Il semblerait que l'obligation de respecter une standard semblable à ce que le PA-DSS ce que fait pour les fournisseurs de logiciels d’applications de paiement pourrait être bien accueilli dans l’industrie de la cryptographie.
Et maintenant, les leçons apprises !
Il est étonnant de voir comment un portefeuille matériel, la quintessence de la sécurité cryptographique, a été violé simplement en limitant l'accès aux informations d'identification du NPM d’un « ancien employé » de Ledger (probablement nom d’utilisateur/mot de passe sans protection 2FA, ni jeton d’accès). Cet incident nous rappelle de manière frappante que lorsque vous êtes sous le feu des critiques, votre infrastructure logicielle doit être protégée avec le même soin que vos produits logiciels ou matériels.
La plupart des attaques visant la chaîne d'approvisionnement logicielle commencent par compromettre un compte interne (souvent celui d'un développeur ou d'un ingénieur DevOps). Les attaquants se déplacent ensuite latéralement pour pénétrer les systèmes internes de l'infrastructure logicielle, comme CI/CD Le système ou les outils de déploiement, ou encore l'ajout d'une logique malveillante aux dépôts de code source, pourraient être détectés si une gestion appropriée des modifications, avec protection des branches et revues de code, était en place. Mais les attaquants n'ont pas besoin d'aller aussi loin lorsque la cible est une bibliothèque populaire publiée dans un registre public, surtout s'ils peuvent accéder aux informations d'identification de publication (écriture). C'est ce qui s'est produit lors de cette attaque.
Authentification 2FA, en utilisant notamment des éléments robustes comme les clés de sécurité, limite les risques liés aux opérations interactives. CI/CD pipelines, jetons d'accès avec accès limité stockés sous forme de CI/CD Le secret est la méthode habituelle (et le jeton d'accès ne doit pas être divulgué). Malheureusement, il semble que l'employé ne disposait pas d'une authentification à deux facteurs robuste. NPM permet organisations pour appliquer 2FA (mais c'est facultatif, pas la valeur par défaut), ce qui est probablement ce que Ledger devrait avoir. Et n'oubliez pas d'ajouter approprié révocation des informations d'identification procédures pour les anciens employés, en particulier avec un accès à des ressources aussi critiques que le périmètre NPM détenu par l'organisation.
Épinglage de version pour les dépendances avec des changements de version révisés est une pratique qui atténue la propagation des dépendances malveillantes. Dans le cadre de l'incident Ledger, les versions de la bibliothèque que le chargeur-kit-de-connexion pris du CDN aurait dû être épinglé, et « ne faites pas confiance à tout ce que le CDN lance ». Avoir un vérification de la somme de contrôle par exemple, via SRI (ou même un système de signature numérique authentifiant également la source) doit être utilisé lors de l'extraction à partir d'un CDN pour le chargement dynamique de code.
Le reste est une histoire.
Pour les campagnes de phishing plus conventionnelles destinées aux utilisateurs de portefeuilles, la question est la suivante : qu'est-ce qui pousse les utilisateurs à tomber dans des pièges tendus par des criminels et à confirmer des transactions qu'ils n'avaient jamais eu l'intention d'effectuer ? Les sites de phishing dans ce domaine sont bien conçus et convaincants, imitant les marques de cryptomonnaies populaires ; et ils offrent également des jetons gratuits, frapper des NFT et d'autres récompenses. Éviter aux utilisateurs de tomber dans de tels pièges est un problème à trouver une solution.
Et pour ne pas oublier le connexe cryptopiratage attaques, une menace plus générale, où les adversaires s'emparent des infrastructures cloud pour exécuter des mineurs de crypto-monnaie, souvent pour des pièces de confidentialité comme Monero XMR et Zcash, avec des historiques de transactions cachés. Le cryptojacking est pertinent car il peut affecter N'IMPORTE QUELLE organisation, et même si le profit pour l'attaquant peut être faible, le coût pour la victime peut être important (Sysdig mentionné dans ce rapport qu'il en coûte 53 $ à l'organisation victime pour chaque dollar extrait pour l'attaquant).
Références
- Billet "[URGENT] Ce référentiel utilise une version malveillante du package npm @ledgerhq/connect-kit, 1.1.7» dans le référentiel Github.
- Lettre du PDG de Ledger sur l'incident, 14 décembre 2023.
- Rapport d'incident de sécurité, par Ledger, 20 décembre 2023.
- L’exploit du grand livre met en danger DeFi ; Sushi dit « N'interagissez avec AUCUNE dApps », poster dans CoinDesk par Olivier Knight, 14 Dec 2023.
- Attaque de la chaîne d'approvisionnement sur le kit Ledger Connect : analyse de l'impact et mesures préventives. Posté par SlowMist sur l’attaque, décembre 2023.
- Concepts de sécurité Web3 : draineurs de portefeuille, par Jammel Weaver, dans Rektify AI, juillet 2023.
Regardez notre démo vidéo
