Ledger n’a pas été « piraté », mais trois failles Ethereum ont nécessité des correctifs

Le test de l’équipe de sécurité Anzen de OneKey a bien reproduit une vulnérabilité réelle dans l’ancienne application Ethereum de Ledger, mais dans un environnement de laboratoire contrôlé. La démonstration portait sur la version 1.22.1. Ledger affirme que la faille avait déjà été corrigée dans la version 1.22.2, publiée avant la présentation publique de OneKey, et n’avoir trouvé aucune preuve d’attaque visant ses utilisateurs. 31731

L’affaire rappelle toutefois une règle essentielle des portefeuilles matériels : isoler les clés privées ne suffit pas. L’appareil doit aussi afficher fidèlement la transaction que l’utilisateur s’apprête à signer.

Ce que OneKey a reproduit

La vulnérabilité, référencée par Ledger sous le nom LSB-023, concernait l’intercalage de commandes pendant la vérification d’une transaction à l’écran. Un ordinateur connecté pouvait envoyer une nouvelle commande APDU alors qu’une précédente attendait encore la réponse de l’utilisateur. Comme les paramètres de signature restaient stockés dans un état partagé pendant cette étape, ils pouvaient potentiellement être modifiés après leur affichage sur l’appareil, mais avant la création de la signature. 3

En pratique, le portefeuille pouvait afficher la transaction A tandis qu’il signait la transaction B. L’équipe Anzen de OneKey a reproduit ce comportement avec l’application Ethereum obsolète 1.22.1, dans un laboratoire. Cela prouve que l’ancien logiciel pouvait être exploité dans les conditions nécessaires ; cela ne prouve pas que les systèmes de production de Ledger ou ses utilisateurs ont été compromis. 172332

Ledger indique avoir identifié la faille dans le cadre de son propre processus de sécurité et avoir ajouté des protections dans l’application Ethereum 1.22.2. Les informations publiées indiquent également que le problème sous-jacent a été corrigé dans le Secure SDK 26.6.1. 172124

Des utilisateurs ont-ils été piratés ?

La position de Ledger est sans ambiguïté : « Aucun utilisateur Ledger n’a été piraté. » Les informations disponibles ne font état d’aucune perte liée à la reproduction de OneKey et d’aucune exploitation connue dans la nature. Cette déclaration doit toutefois être comprise comme un bilan des attaques observées, et non comme la preuve qu’une exploitation aurait été impossible sur une version vulnérable. 172031

La distinction est importante : une reproduction en laboratoire confirme qu’un chemin de code vulnérable fonctionne dans certaines conditions, mais elle ne démontre pas que des cybercriminels l’ont utilisé contre des utilisateurs réels.

Les deux failles supplémentaires corrigées dans la version 1.22.3

La version 1.22.3 a corrigé deux autres vulnérabilités de l’application Ethereum qui restaient présentes après la mise à jour 1.22.2. L’index des bulletins de sécurité de Ledger les identifie comme LSB-024 et LSB-025. 46

LSB-024 : un lot de signature transparente pouvait masquer des opérations

LSB-024 concernait la gestion d’un nombre entier ou du compteur d’opérations lors de la signature transparente (« clear signing »). Un lot spécialement conçu contenant 257 opérations pouvait amener l’appareil à n’afficher que la dernière opération, tout en signant l’ensemble du lot.

Il s’agit d’un défaut d’intégrité de la vérification de transaction. L’utilisateur devait toujours confirmer l’opération sur l’appareil, mais les informations visibles ne décrivaient pas fidèlement l’intégralité des données signées. Ledger décrit cette faille comme un « contournement de la signature transparente par troncature du nombre d’éléments ». 46

LSB-025 : un paiement de swap pouvait devenir une autorisation de jeton

LSB-025 affectait le déroulement d’un swap, c’est-à-dire l’échange d’un actif contre un autre. Un prestataire de swap compromis pouvait remplacer le paiement attendu par une autorisation de jeton sans déclencher une nouvelle demande de confirmation sur l’appareil. Ledger décrit le problème comme l’acceptation d’une autorisation de jeton à la place d’un paiement dans le flux de swap. 46

Les limites de cette faille sont importantes. Elle ne permettait pas, d’après les informations disponibles, de créer une autorisation illimitée ni d’approuver une adresse choisie arbitrairement par l’attaquant. Elle pouvait néanmoins conduire l’utilisateur à signer une autorisation qu’il n’avait pas l’intention d’accorder, ce qui est très différent du paiement attendu lors d’un swap. 46

Pourquoi LSB-024 et LSB-025 n’étaient-elles pas déjà dans la version 1.22.2 ?

Les informations publiques utilisées pour ce dossier indiquent que les modifications liées à ces deux failles auraient été préparées ou fusionnées plusieurs mois avant la sortie de la version 1.22.2. Pourtant, les correctifs n’ont été intégrés qu’à la version 1.22.3. 37

Aucune documentation publique suffisamment faisant autorité ne permet d’établir s’il s’agissait d’une priorité de publication, d’un problème d’intégration, d’un défaut de test ou d’une autre décision interne. La conclusion la plus solide est donc la suivante : les correctifs n’étaient pas inclus dans la version 1.22.2, et la raison précise reste publiquement inexpliquée. Aller plus loin dépasserait les éléments disponibles.

Ce que cette affaire dit du modèle de sécurité « évolutif » de Ledger

Ledger met en avant un avantage de son architecture : les applications installées sur l’appareil et les logiciels qui les prennent en charge peuvent être mis à jour. Lorsqu’une vulnérabilité est découverte, le processus consiste à l’identifier, développer un correctif, le distribuer, puis publier des détails techniques. Ledger présente LSB-023 comme un exemple de ce mécanisme : la faille aurait été détectée en interne, corrigée, puis documentée dans un bulletin de sécurité. 3

L’avantage est concret : une vulnérabilité logicielle identifiée ne reste pas nécessairement présente de façon permanente. Mais ce modèle impose aussi une discipline aux utilisateurs. Un correctif ne protège l’appareil qu’une fois l’application effectivement mise à jour. De plus, une publication incomplète ou tardive peut laisser d’autres problèmes non résolus, comme l’illustre l’écart entre les versions 1.22.2 et 1.22.3. 37

Ce que les utilisateurs de Ledger doivent faire

1. Mettre à jour l’application Ethereum vers la version 1.22.3 ou une version ultérieure. La version 1.22.2 contient le correctif applicatif de LSB-023, tandis que la version 1.22.3 corrige LSB-024 et LSB-025. 1737
2. Utiliser le gestionnaire d’appareil de Ledger Live et les canaux officiels de Ledger pour installer les mises à jour. Les instructions de Ledger recommandent d’installer l’application Ethereum depuis Ledger Live. 7
3. Lire attentivement chaque demande affichée sur l’appareil, notamment lors d’un swap. Si l’appareil demande une autorisation alors que vous vous attendiez à confirmer un paiement, interrompez l’opération et refusez-la.
4. Éviter les lots inhabituellement volumineux ou difficiles à interpréter. Dans la mesure du possible, ne signez pas à l’aveugle lorsque le contenu complet ne peut pas être vérifié sur l’appareil.
5. Considérer l’ordinateur, le navigateur et les services connectés comme des éléments de votre modèle de menace. Un portefeuille matériel réduit certains risques, mais il ne neutralise pas les dangers liés aux logiciels malveillants, aux sites hostiles, aux applications décentralisées compromises ou aux prestataires de swap. 328
6. Vérifier les autorisations de jetons après avoir utilisé une version concernée. Si vous avez effectué des swaps ou signé des autorisations avec une application vulnérable, recherchez les autorisations inutiles et révoquez-les via une interface de confiance.

À retenir

OneKey a bien démontré une faille réelle dans une ancienne version de l’application Ethereum de Ledger, mais les éléments disponibles ne montrent pas un piratage généralisé ni une attaque en cours contre les utilisateurs. L’épisode doit néanmoins être pris au sérieux : les failles LSB-024 et LSB-025 montrent que passer à la première version corrective ne constituait pas forcément la fin de l’histoire. La recommandation immédiate est simple : utiliser au minimum l’application Ethereum 1.22.3, vérifier chaque demande sur l’écran du portefeuille et rester méfiant face aux services connectés.