Les articles précédents de cette série ont examiné les catégories d’attaques visant le secure element lui-même : injection de fautes, analyse invasive de puces et techniques par canaux auxiliaires. Ce sont des menaces réelles, mais elles relèvent d’un niveau d’attaque nécessitant d’importantes ressources, des équipements spécialisés et un ciblage individuel. La plupart des utilisateurs n’y seront jamais confrontés.
Les attaques sur la supply chain sont différentes. Elles ne nécessitent ni laboratoire, ni accès physique à un appareil. Elles n’ont pas besoin de compromettre le secure element, car elles opèrent dans les couches logicielles situées au-dessus de la puce. Une seule attaque réussie sur la supply chain peut toucher des milliers voire des millions d’utilisateurs en même temps. L’aspect économique les rend bien plus attractives pour un éventail plus large d’attaquants que toute technique au niveau matériel.
Cet article analyse le risque supply chain dans le contexte logiciel, à travers deux incidents documentés impliquant l’un des fabricants de hardware wallets les plus utilisés au monde.
Ce que signifie réellement une attaque sur la supply chain
Au lieu de cibler directement l’utilisateur final, les attaquants exploitent une relation de confiance comme vecteur d’attaque supply chain. Cela implique de compromettre un élément sur lequel l’utilisateur s’appuie, comme une bibliothèque logicielle, un mécanisme de mise à jour du firmware ou un canal de distribution.
Dans les hardware wallets, les vecteurs supply chain les plus pertinents sont :
Firmware de l’appareil livré à distance : mises à jour que le fabricant déploie sur tous les appareils, automatiquement ou avec l’accord de l’utilisateur.
Bibliothèques des applications compagnons : code inclus dans le logiciel desktop ou mobile du wallet.
Bibliothèques JavaScript tierces : code dont dépendent les services connectés du fabricant, provenant de registres publics comme NPM.
Distribution et logistique : interception physique des appareils avant qu’ils n’atteignent l’utilisateur final.
Ce qui rend ces vecteurs dangereux, c’est leur ampleur. L’attaquant investit une seule fois et touche tous ceux qui utilisent le composant compromis avant qu’il ne soit détecté et corrigé.
Le secure element n’offre aucune protection contre ces vecteurs, car ces attaques ne nécessitent jamais de compromettre la puce. Elles interviennent en amont. La clé reste protégée dans le secure element tandis que tout ce qui l’entoure est manipulé.
Le 14 décembre 2023, une attaque supply chain a visé le Connect Kit de Ledger, une bibliothèque JavaScript utilisée par les applications décentralisées pour interagir avec les hardware wallets Ledger, entraînant le vol de 484 000 $ à 600 000 $. L’attaque a duré environ cinq heures, avec une phase active de drainage des fonds sur environ deux heures. Des dizaines de protocoles DeFi majeurs ont été touchés simultanément.
Le déroulement de cette attaque révèle beaucoup sur les véritables failles de sécurité des hardware wallets en pratique.
Comment l’attaque a été menée
Le Connect Kit de Ledger est une bibliothèque JavaScript open source publiée sur NPM, le registre Node Package Manager, le canal de distribution standard du code JavaScript. Des centaines d’applications décentralisées l’ont intégrée pour permettre à leurs utilisateurs de connecter leurs hardware wallets Ledger.
Fait crucial, Ledger distribuait la bibliothèque non seulement via le mécanisme standard de versionnage de NPM, mais aussi via un chargeur CDN (Content Delivery Network), ce qui amenait les applications dépendantes à récupérer automatiquement la dernière version de la bibliothèque à l’exécution, plutôt qu’une version fixe et vérifiée.
Cela signifiait qu’au moment où une nouvelle version apparaissait sur NPM, toute application utilisant le chargeur CDN l’exécutait immédiatement, sans revue, sans mise à jour manuelle, sans filet de sécurité.
L’attaquant a obtenu les identifiants de publication NPM d’un ancien employé de Ledger via une attaque de phishing. L’accès de cet ancien employé aux systèmes internes de Ledger avait bien été révoqué lors de son départ, mais sa clé API NPM n’avait pas été désactivée.
Les clés API contournent l’exigence de double authentification de NPM, ce qui signifie que l’attaquant n’avait besoin que de la clé, sans authentification secondaire.
Une fois l’accès à la publication obtenu, l’attaquant a mis en ligne trois versions malveillantes du Connect Kit (1.1.5, 1.1.6 et 1.1.7) contenant le malware Angel Drainer, un code malveillant qui fabriquait des demandes d’approbation de transaction frauduleuses, lesquelles, une fois signées par l’utilisateur, transféraient les actifs vers le wallet de l’attaquant.
Lorsque le chargeur CDN récupérait automatiquement la dernière version, les dApps concernées servaient le code malveillant à leurs utilisateurs en quelques minutes, sans qu’aucun développeur d’application n’ait à intervenir.
Ledger a réagi rapidement, en déployant une version corrigée 40 minutes après l’alerte interne et en coordonnant avec Tether pour geler les fonds volés. Le but de cette analyse est de montrer que le vecteur d’attaque existait et a été exploité.
Le firmware évolutif, un risque supply chain
La controverse Ledger Recover (mai 2023) a mis en lumière un risque supply chain inhérent à tout hardware wallet doté d’un firmware évolutif. Le service de sauvegarde de seed phrase proposé par Ledger, qui chiffrait et transmettait des fragments de phrase de récupération à trois dépositaires via le firmware, n’était pas une attaque, mais a prouvé qu’une capacité préoccupante existait.
Une mise à jour du firmware, signée et poussée par le fabricant, pourrait ordonner au secure element de manipuler et transmettre la seed phrase. Comme nous l’avons détaillé dans notre analyse de Ledger Recover, le secure boot ne protège que contre les firmwares tiers : il ne limite pas ce que le fabricant peut déployer. Ce canal de mise à jour est donc un vecteur supply chain.
Si l’infrastructure de signature du fabricant était compromise, ou si des backdoors imposées par l’État via une mise à jour forçaient un changement de capacité discret, les utilisateurs n’auraient aucun moyen de le détecter à l’avance.
Que se passe-t-il avec un firmware évolutif ?
Lorsque vous utilisez un hardware wallet avec des mises à jour de firmware contrôlées par le fabricant, vous faites confiance :
Aux intentions du fabricant : que l’entreprise ne poussera pas volontairement un firmware compromettant la sécurité des utilisateurs, aujourd’hui ou à l’avenir, quelles que soient les pressions commerciales, réglementaires ou les changements de direction.
À l’infrastructure de signature du fabricant : que les clés privées servant à signer le firmware sont correctement sécurisées et n’ont jamais été compromises. Une clé de signature volée permettrait à un attaquant de déployer un firmware authentifié par le fabricant sur tous les appareils.
À l’ensemble de la chaîne de distribution des mises à jour : chaque canal impliqué dans le transfert du firmware du développement à l’appareil.
Aux processus internes du fabricant : contrôle des accès des employés, procédures de départ, exigences de revue de code et systèmes de build sécurisés.
À l’environnement réglementaire : les fabricants sont soumis aux lois de leur juridiction. Un gouvernement ayant autorité sur un fabricant peut, en principe, imposer la diffusion d’un firmware servant ses intérêts.
Cela ne signifie pas que le firmware évolutif est indéfendable en tant qu’architecture. Cela signifie que la défense s’étend sur une surface de confiance plus large et plus complexe que ce que la plupart des utilisateurs imaginent.
L’alternative : le firmware immuable
Certains hardware wallets, comme Tangem, utilisent un firmware gravé dans l’appareil lors de la fabrication, qui ne peut plus être mis à jour après la sortie d’usine. Cette approche implique un compromis de sécurité fondamentalement différent.
Les avantages sont clairs : la surface d’attaque supply chain du firmware est éliminée. Il n’y a aucun mécanisme de mise à jour à compromettre, aucune clé de signature à voler, aucun pipeline à empoisonner. Le firmware installé à la fabrication est celui qui fonctionnera pendant toute la durée de vie de l’appareil.
Le fabricant n’a plus aucun contrôle sur le comportement de l’appareil après sa livraison, ce qui signifie qu’il n’a plus aucun canal pour modifier, de son propre chef ou sous contrainte, le fonctionnement du dispositif.
Un audit indépendant du firmware par des sociétés comme Kudelski Security, Riscure ou SlowMist peut confirmer que le firmware est fiable et réellement immuable. Les utilisateurs de dispositifs immuables doivent s’appuyer sur la qualité de l’audit initial et peuvent devoir remplacer leur matériel en cas de changements majeurs de protocole.
À retenir
Une attaque supply chain ne nécessite ni équipement de laboratoire, ni analyse par canaux auxiliaires, ni accès physique à un appareil.
Elles peuvent se propager naturellement et efficacement à chaque utilisateur de chaque produit concerné. Les attaquants opèrent dans des couches que la plupart des utilisateurs n’examinent jamais, via des mécanismes souvent invisibles ou considérés comme fiables par défaut.
Vérifiez toujours l’authenticité de votre wallet lors de la première configuration, achetez directement auprès du fabricant ou de revendeurs certifiés, et soyez vigilant vis-à-vis de toute application qui vous demande d’approuver une opération que vous ne reconnaissez pas.
Demandez à l’IA si Tangem correspond à vos besoins
Recherchez le portefeuille Tangem avec l’IA pour savoir si notre sécurité et notre facilité d’utilisation correspondent à vos cas d’utilisation uniques
Demandez à l’IA si Tangem correspond à vos besoins
Recherchez le portefeuille Tangem avec l’IA pour savoir si notre sécurité et notre facilité d’utilisation correspondent à vos cas d’utilisation uniques
Or open it in
Still deciding?
Explore the basics, compare your options, or save when you’re ready to get Tangem.
