Rédigé par : imToken
Un portefeuille matériel avec des puces d'origine intactes, un firmware authentique et même la capacité de réussir le contrôle officiel Genuine Check — les actifs qu'il contient pourraient-ils encore être volés par des pirates ?
Le récent incident de sécurité de Ledger a précisément exposé ce risque apparemment impossible.
Selon les résultats de l'enquête subsequently divulgués par l'équipe de sécurité de Ledger, l'attaquant a implanté un circuit malveillant supplémentaire à l'intérieur de l'appareil affecté, capable d'intercepter la phrase mnémonique affichée à l'écran et de l'envoyer à l'attaquant via les réseaux de communication mobile.
En d'autres termes, la puce de sécurité d'origine n'a pas été compromise, mais la phrase mnémonique a peut-être déjà été entre les mains du pirate dès sa première apparition à l'écran.
De plus, ce n'est pas le seul incident de sécurité récent digne d'attention.
Depuis septembre, de Bitget confronté à l'exploitation d'une vulnérabilité d'un produit de sécurité tiers, à Trezor dont le fournisseur de services de messagerie Brevo a été compromis, en passant par des problèmes de sécurité apparus dans certaines infrastructures de MetaMask, une série d'incidents nous rappelle que à mesure que les produits Crypto deviennent de plus en plus complexes, la sécurité ne se limite plus à protéger les clés privées et à éviter les vulnérabilités des contrats intelligents.
Les risques cachés dans la circulation des appareils, les services tiers, les permissions internes et les communications avec les utilisateurs peuvent également devenir des points d'entrée que les attaquants recherchent.
I. La nouvelle alerte à la « sécurité de la chaîne d'approvisionnement » lancée par Ledger
Décomposons d'abord ce qui est arrivé à Ledger cette fois-ci.
Lors de l'achat d'un portefeuille matériel, les gens se méfient généralement de deux choses : acheter un faux, ou recevoir un appareil pré-initialisé par quelqu'un d'autre.
L'astuce la plus courante ces dernières années consistait pour des intermédiaires malveillants à générer d'abord une phrase mnémonique, à l'imprimer sur une carte à gratter, puis à la remettre dans l'emballage, en pariant que les utilisateurs novices ne comprendraient pas les règles et déposeraient directement des fonds.
Bien que cette arnaque soit dangereuse, la logique de défense est très claire — utiliser des canaux légitimes, vérifier l'état de l'appareil, veiller à ce que l'appareil génère lui-même une nouvelle phrase mnémonique, et ne jamais utiliser une phrase mnémonique toute prête provenant de la boîte.
Mais cette attaque contre Ledger a clairement fait monter les méthodes d'un cran. Le pirate a inséré un module électronique supplémentaire doté d'un microcontrôleur, d'une eSIM et de capacités de communication cellulaire à l'intérieur du boîtier. Lorsque les utilisateurs initialisent le portefeuille pour la première fois, ils doivent finalement lire la phrase mnémonique à l'écran et la noter.
En d'autres termes, le circuit malveillant implanté n'interfère pas du tout avec le processus de génération de la phrase mnémonique ; il se contente de surveiller la phrase mnémonique et de la transmettre directement. C'est aussi pourquoi « la clé privée n'a pas été directement extraite de la puce de sécurité » ne signifie pas que les informations de récupération du portefeuille de l'utilisateur sont encore sûres.
Ce qui est plus problématique, c'est que même si l'appareil passe le contrôle officiel Genuine Check, il peut ne pas être capable d'identifier ce matériel supplémentaire, car la vérification d'authenticité confirme principalement l'identité de la puce de sécurité et la fiabilité du firmware.
Cet incident a donc bien exposé un grave « risque de chaîne d'approvisionnement » facilement négligé dans la vie quotidienne : la sécurité d'un portefeuille matériel ne dépend pas seulement de la puce et du firmware, mais aussi de l'ensemble du processus de livraison depuis l'usine d'origine jusqu'aux mains de l'utilisateur.
Après tout, un appareil peut devoir passer par plusieurs maillons tels que des distributeurs régionaux, des entrepôts tiers, la logistique et des détaillants. Tout participant ayant l'occasion d'accéder physiquement à l'appareil peut devenir un point de risque nécessitant une évaluation supplémentaire.
II. De Trezor à Bitget : comment les attaquants contournent-ils les défenses de sécurité essentielles ?
Après avoir compris le problème de Ledger, si nous examinons ensuite les incidents de sécurité que Bitget et Trezor ont rencontrés successivement récemment, nous constaterons que la logique sous-jacente est étonnamment similaire : les attaquants ont également évité la ligne de défense frontale la plus solide et ont plutôt pénétré par les « services tiers » périphériques.
Tout d'abord, regardons Trezor.
Début septembre, certains utilisateurs de Trezor ont reçu un e-mail dont l'objet était « Alerte de sécurité critique : vulnérabilité d'entropie STM32 », affirmant que le portefeuille matériel présentait une grave vulnérabilité de sécurité et qu'une action immédiate était nécessaire.
De tels e-mails rendent facilement les utilisateurs nerveux. Après tout, lorsqu'il s'agit de portefeuilles matériels et de vulnérabilités de sécurité, personne ne souhaite que ses actifs subissent des pertes à cause de cela.
C'est exactement ce qui s'est produit : l'attaquant a exploité Brevo, la plateforme de marketing par e-mail tierce utilisée par Trezor, pour permettre au contenu malveillant d'atteindre les boîtes de réception des utilisateurs via l'infrastructure normale d'envoi d'e-mails.
Selon le rapport d'incident ultérieur de Brevo, l'attaquant a exploité des failles de délimitation des permissions dans son système d'authentification unique pour obtenir un accès non autorisé à d'autres comptes clients, impliquant finalement 138 comptes clients, dont certains ont été utilisés pour envoyer des e-mails d'hameçonnage ou exporter des données de contact.
Trezor a ensuite confirmé que 347 149 adresses de contact de marketing par e-mail avaient été exportées lors de l'incident, et que les e-mails d'attaque tentaient d'inciter les utilisateurs à télécharger des applications malveillantes et à saisir les informations de sauvegarde du portefeuille.
Il convient de noter que rien dans cet incident ne prouve que les portefeuilles matériels de Trezor ou les systèmes de protection des clés privées aient été compromis. Ce que l'attaquant a d'abord obtenu, ce sont les informations des utilisateurs et la capacité d'abuser des canaux de communication officiels.
Mais pour les utilisateurs ordinaires qui ont reçu les e-mails, identifier le risque est devenu encore plus difficile, car les e-mails pouvaient provenir d'un domaine officiel familier et pouvaient également passer les contrôles normaux d'authentification des e-mails, tandis que le contenu avait déjà été remplacé par l'attaquant par des informations d'hameçonnage.
Si les utilisateurs saisissent volontairement leur phrase mnémonique à cause de cela, ce qui n'était à l'origine qu'un problème de service d'e-mail tiers pourrait évoluer vers de véritables pertes d'actifs.
Regardons maintenant Bitget.
Le 24 septembre, des transferts d'actifs non autorisés se sont produits dans certains portefeuilles chauds et portefeuilles tièdes de Bitget, impliquant finalement, après vérification, environ 388 millions de dollars américains.
Selon les résultats de l'enquête annoncés officiellement par Bitget, l'attaquant a exploité une vulnérabilité dans un produit de sécurité tiers pour obtenir des identifiants à hauts privilèges à l'intérieur de la plateforme d'échange, puis s'est introduit dans les systèmes backend liés aux portefeuilles, a falsifié des instructions de retrait, contourné les contrôles de risque d'origine et fait entrer des transferts anormaux dans le processus d'exécution normal.
Bitget a déclaré qu'aucune fuite de clé privée n'avait été constatée dans cet incident et que les portefeuilles froids n'avaient pas été affectés. Cela semble quelque peu contradictoire : puisque les clés privées n'ont pas été volées, pourquoi l'argent a-t-il pu être transféré ?
En réalité, ce n'est pas difficile à comprendre.
Pour les plateformes de garde comme les plateformes d'échange, après qu'un utilisateur initie un retrait, il n'est pas question qu'une personne signe manuellement chaque transaction avec une clé privée à chaque fois. Il faut plutôt passer par tout un ensemble de processus internes tels que la vérification du compte, l'examen du contrôle des risques, la génération de la transaction et la signature du portefeuille.
C'est comme le coffre-fort d'une banque. Même si la clé du coffre-fort est conservée très strictement, si quelqu'un peut usurper une identité interne à hauts privilèges et falsifier une instruction de transfert qui passe l'approbation, les fonds du coffre-fort peuvent encore être transférés par erreur.
Ce que Bitget a exposé cette fois, c'est précisément la manière dont le risque se propage davantage vers le système d'exécution des actifs après la défaillance des permissions en amont et de la vérification des instructions. Par conséquent, « la clé privée n'a pas fuité » et « les fonds ne seront pas transférés illégalement » sont en réalité deux choses différentes.
Quant à l'incident de sécurité de l'infrastructure divulgué par MetaMask à la fin du mois de septembre, il a présenté une autre dimension du risque opérationnel.
À cette époque, MetaMask a pris des mesures préventives et a quitté de manière proactive certains validateurs de staking affectés. Selon la mise à jour de l'enquête officielle du 1er octobre, aucun signe n'a été trouvé indiquant que les portefeuilles MetaMask ou les fonds des clients aient été affectés, et l'activité de staking concernée ne gère pas les clés de retrait au nom des clients.
Cependant, cela ne signifie pas que les problèmes d'infrastructure n'auront pas d'autres impacts. Les solutions non dépositaires traitent principalement la question du contrôle des actifs, mais elles ne peuvent pas éliminer automatiquement les risques opérationnels des infrastructures externes.
En mettant ces événements bout à bout, le fil conducteur est en réalité très clair :
- Ce que Ledger a exposé, c'est le risque de modification physique dans le processus de circulation du matériel, qui peut finalement conduire au vol de phrases mnémoniques ;
- Ce que Trezor / Brevo ont exposé, c'est le risque de fuite d'informations des utilisateurs et d'utilisation abusive des canaux de communication officiels, ce qui ne signifie pas que le portefeuille lui-même a été compromis ;
- Ce que Bitget a exposé, c'est le risque que des vulnérabilités dans des produits tiers soient transmises à des systèmes internes à hauts privilèges, ce qui peut directement affecter l'exécution des fonds ;
- MetaMask, quant à lui, nous rappelle que le contrôle des actifs et le risque opérationnel du service ne sont pas la même notion.
Dans l'ensemble, les produits Crypto d'aujourd'hui ne sont plus des îlots isolés.
Les portefeuilles dépendent de nœuds RPC externes pour lire les données on-chain et d'interfaces d'agrégation pour récupérer les cotations du marché ; les exchanges ne peuvent se passer de surveillance de sécurité externe, de vérification KYC et de composants de contrôle des risques ; en élargissant davantage vers l'extérieur, il y a aussi les opérateurs de nœuds, les fournisseurs de cloud, les tickets de service client et les systèmes de messagerie comme Brevo.
Ces services externes rendent les produits plus efficaces et améliorent également l'expérience utilisateur, mais en même temps, chaque fois qu'une nouvelle dépendance externe est introduite, le produit gagne une couche supplémentaire de relations de confiance à gérer :
À quoi les tiers peuvent-ils accéder, de quelle autorité disposent-ils, et s'ils sont compromis, le risque continuera-t-il à se transmettre à d'autres systèmes critiques ?
III. Comment les produits et les utilisateurs doivent-ils se défendre ?
Face à des risques de dépendance à des tiers de plus en plus complexes et à des relations de dépendance imbriquées, s'attendre à ce que les équipes produit reviennent à l'état primitif de « ne dépendre d'aucun service externe » est manifestement irréaliste et ne conforme pas aux règles du marché.
Ce qui teste vraiment la compétence d'une architecture de sécurité, c'est de minimiser chaque exposition possible au risque.
Par exemple, pourquoi un fournisseur SaaS qui ne gère que des e-mails marketing devrait-il conserver à long terme les données de contact de tous les utilisateurs ? Pourquoi des outils de surveillance de sécurité tiers peuvent-ils atteindre l'environnement de production critique sans multi-autorisation indépendante ? En particulier pour les actions sensibles impliquant des transferts de fonds, les systèmes internes ne doivent jamais adopter la « confiance par défaut » et doivent mettre en œuvre une isolation stricte des permissions et une vérification croisée indépendante.
C'est aussi ce que l'on appelle souvent dans l'architecture de sécurité le « moindre privilège » et la « séparation des tâches » : une plateforme d'envoi d'e-mails ne devrait disposer que des permissions nécessaires pour envoyer des e-mails, les outils de surveillance de sécurité ne devraient pas pouvoir exécuter des transferts de fonds à volonté, et un retrait important ne devrait pas être approuvé directement sur la seule base d'une instruction transmise par un système interne quelconque.
L'incident Ledger rappelle en outre aux fabricants de portefeuilles matériels que la gestion de la sécurité doit même s'étendre au processus de circulation physique du produit.
De l'expédition en usine, à l'entreposage, à la logistique, jusqu'à la livraison par le revendeur, comment établir un processus de gestion traçable, comment détecter un démontage ou un remplacement anormal d'appareil, et comment localiser les lots et les utilisateurs affectés après qu'un problème survient, ne devraient pas être considérés comme un simple travail de gestion des canaux.
Car pour un appareil matériel qui protège des clés privées, le processus de livraison fait lui-même partie du système de sécurité.
Bien sûr, pour les utilisateurs ordinaires, nous ne pouvons ni auditer la chaîne d'approvisionnement logicielle d'un portefeuille ni enquêter un par un sur chaque maillon d'entreposage et de logistique d'un portefeuille matériel.
Mais cela ne signifie pas que nous ne pouvons que subir passivement le risque. Au moins plusieurs choses méritent de devenir des habitudes dans l'usage quotidien.
Premièrement, minimisez les intermédiaires inutiles dans le processus d'achat d'un portefeuille matériel.
Si les conditions le permettent, privilégiez la commande sur le site officiel de la marque et faites-vous livrer directement depuis l'usine d'origine ou l'entrepôt officiel, ce qui réduit généralement le risque que l'appareil soit contacté, démonté ou échangé par des tiers après avoir quitté le contrôle de l'usine d'origine.
Du point de vue de la gestion des risques, plus les parties indépendantes qui entrent en contact avec l'appareil sont nombreuses, plus les maillons nécessitant une confiance supplémentaire sont nombreux ; en outre, après avoir reçu l'appareil, vous devez tout de même vérifier l'absence d'anomalies d'emballage et d'apparence, utiliser le logiciel officiel pour effectuer la vérification, et suivre strictement le processus d'initialisation.
Deuxièmement, il est nécessaire de reconsidérer si les « messages officiels » sont dignes de confiance.
L'incident Trezor a déjà montré que même si un e-mail est effectivement envoyé via la plateforme de service officiellement utilisée, cela ne signifie pas que les liens et les exigences opérationnelles qu'il contient sont nécessairement sûrs.
En particulier lorsqu'il s'agit d'opérations sensibles telles que les mises à niveau de portefeuille, le gel de compte, la migration d'actifs et les correctifs de vulnérabilité, il est préférable de ne pas cliquer directement sur les liens du message, mais de vérifier proactivement via l'adresse du site officiel que vous avez enregistrée ou l'application officielle que vous avez déjà installée.
Pour les portefeuilles non dépositaires tels qu'imToken, les utilisateurs doivent également identifier les canaux officiels, utiliser token.im comme base pour le téléchargement et l'installation, et lorsqu'ils rencontrent des informations anormales, vérifier en priorité via les entrées officielles telles que « Aide & Commentaires » dans l'application.
Que l'autre partie prétende être le service client officiel, une équipe de sécurité, ou fournisse une explication de vulnérabilité apparemment très professionnelle, vous ne devez jamais leur divulguer votre phrase mnémonique ou votre clé privée.
Enfin, il est nécessaire de distinguer l'impact réel des différents incidents de sécurité sur vous-même.
Une fuite d'adresse e-mail signifie principalement que vous pourriez faire face à davantage d'hameçonnage ciblé à l'avenir ; cliquer sur un lien suspect nécessite de confirmer davantage si des programmes malveillants ont été téléchargés ou exécutés ; si une phrase mnémonique a déjà été saisie, elle doit être traitée immédiatement comme une fuite du contrôle du portefeuille.
Si des transactions ou des autorisations suspectes ont été signées, il est également nécessaire de combiner les opérations on-chain spécifiques pour déterminer s'il existe un risque continu d'autorisation de contrat.
Quant aux défaillances de services tiers ou aux anomalies d'infrastructure, il est davantage nécessaire de se référer à la portée d'impact divulguée officiellement pour déterminer si cela concerne vos actifs, la disponibilité du service ou les rendements.
Vous ne pouvez pas conclure par défaut que la clé privée a été compromise simplement parce que vous avez entendu parler d'un « incident de sécurité de portefeuille », et vous ne devez certainement pas transférer imprudemment des actifs vers des adresses inconnues en raison de soi-disant notifications de sécurité urgentes.
Après tout, dans de nombreux cas, ce que les attaquants espèrent vraiment n'est pas de franchir la ligne de défense technique la plus solide, mais d'amener les utilisateurs à accomplir volontairement la dernière étape dans la panique (Lecture complémentaire : « L'IA « défie » la cryptographie ? Le Web3 doit se préparer aux jours de pluie, mais ne doit jamais se précipiter pour migrer »).
Réflexions finales
Par le passé, la phrase la plus souvent soulignée dans l'industrie Crypto était « Not your keys, not your coins ».
Cette phrase reste importante, car le contrôle de la clé privée détermine si les utilisateurs peuvent réellement contrôler leurs actifs de manière indépendante.
Mais à mesure que les portefeuilles, les échanges et les produits financiers on-chain arrivent progressivement à maturité, nous devons aussi réaliser que la protection de la clé privée n'est qu'une partie de l'ensemble du système de sécurité.
Un véritable portefeuille matériel peut encore être physiquement altéré pendant la livraison ; une notification réellement envoyée depuis un système de messagerie officiel peut aussi être exploitée par des attaquants ; et un ensemble d'outils tiers initialement destinés à renforcer la sécurité peut même devenir une porte d'entrée vers le système de fonds principal.
Ces cas ne signifient pas que nous devrions perdre confiance en tous les portefeuilles et services externes. Au contraire, ils rappellent à toute l'industrie que la sécurité doit être étendue de l'intérieur d'un seul produit à l'ensemble du processus de la chaîne d'approvisionnement, de la gestion des autorisations, de la communication avec les utilisateurs et de la réponse aux urgences.
Après tout, un système de sécurité Crypto véritablement mature doit non seulement garantir que les clés privées ne soient pas facilement divulguées, mais aussi garantir autant que possible que, même si un certain maillon externe fait défaut, l'ensemble du mécanisme puisse encore arrêter fermement le risque en cours de route et l'empêcher de franchir la dernière ligne rouge protégeant les actifs des utilisateurs.
