Ledger rejette les allégations de piratage après qu'OneKey a recréé un bug

Ledger a rejeté les allégations selon lesquelles il aurait été piraté après que l'équipe de sécurité Anzen d'OneKey a reproduit un défaut de remplacement de transaction sur une version obsolète de l'application Ethereum de Ledger.

Résumé

• OneKey a reproduit une attaque de substitution de transaction contre la version 1.22.1 de l'application Ethereum de Ledger lors de tests en laboratoire.
• Ledger affirme que l'application Ethereum 1.22.2 a ajouté des protections avant qu'OneKey ne décrive publiquement sa tentative de reproduction en ligne.
• Un attaquant devait contrôler les communications entre l'appareil et l'hôte via des logiciels malveillants, des pages web hostiles ou des logiciels de portefeuille compromis.
• La version 26.6.1 du SDK sécurisé a bloqué les commandes entrelacées avant qu'elles n'atteignent directement les applications individuelles de l'appareil Ledger.
• Ledger n'a trouvé aucune preuve que la vulnérabilité ait été exploitée contre des utilisateurs ou ait causé des pertes de cryptomonnaie.

Le fondateur d'OneKey, Yishi Wang, a déclaré le 27 août que les chercheurs avaient terminé l'attaque contre l'application Ethereum 1.22.1 en laboratoire. Ledger a confirmé la vulnérabilité sous-jacente mais a déclaré qu'il avait déjà corrigé l'application affectée avant qu'OneKey ne publie sa démonstration.

Le défaut Ethereum de Ledger a rompu la garantie d'affichage de confiance

La vulnérabilité impliquait la communication entre un appareil Ledger et son hôte connecté. Les applications Ledger reçoivent des instructions appelées commandes d'Unité de Données de Protocole d'Application, ou APDUs, provenant de logiciels de portefeuille, de pages web ou d'autres interfaces.

Une application affectée pouvait accepter une seconde commande APDU pendant que l'utilisateur examinait une opération antérieure sur l'écran de l'appareil. La nouvelle commande pouvait écraser les paramètres de signature stockés dans la mémoire partagée sans mettre à jour les informations affichées.

Dans ce scénario, l'utilisateur pouvait examiner la transaction A et l'approuver pendant que l'application générait une signature couvrant la transaction B. L'appareil ne préviendrait pas l'utilisateur que les informations sous-jacentes avaient changé.

Ledger a classé le problème comme une condition de course de temps de vérification à temps d'utilisation. Son bulletin a déclaré que le défaut contournait la protection d'affichage de confiance que les portefeuilles matériels utilisent pour permettre aux clients de vérifier les montants, les adresses et les actions de contrat avant de signer.

Le problème n'a pas révélé de phrases de graine ni extrait de clés privées de l'élément sécurisé. Au lieu de cela, il pouvait amener la clé protégée à signer des paramètres différents de ceux montrés à l'utilisateur.

L'exploitation nécessitait une connexion compromise

Un attaquant devait contrôler les communications entre l'application Ledger et son hôte. Ledger a listé les logiciels malveillants, une application de portefeuille compromise ou une page web hostile avec un accès WebHID ou WebUSB comme voies possibles.

L'attaque ne pouvait pas être effectuée à distance contre un appareil débranché. Un utilisateur devait également approuver la transaction pendant que le logiciel malveillant manipulait son contexte de signature en attente.

Ledger a déclaré que le défaut était situé dans la gestion des entrées et des sorties de son SDK sécurisé, et non dans le système d'exploitation ou le firmware de l'appareil. Les applications compilées avec les versions affectées du SDK dépendaient de leurs propres vérifications d'état pour rejeter les commandes arrivant pendant une révision active.

Cela signifie que l'exposition était spécifique à l'application. Une application restait protégée si chaque point d'entrée de commande asynchrone vérifiait correctement son état, même lorsqu'elle était construite en utilisant le SDK affecté.

Ledger conteste si le test compte comme un piratage

Wang a décrit le résultat du laboratoire en disant : "nous avons piraté Ledger." Il a également déclaré que la société avait corrigé le problème dans l'application Ethereum 1.22.3.

Le directeur technique de Ledger, Charles Guillemet, a contesté cette description. Il a déclaré que "reproduire un bug déjà corrigé n'est pas 'pirater Ledger'" et a caractérisé le travail d'OneKey comme un exercice de laboratoire contre une application plus ancienne.

L'historique des versions soutient une chronologie plus précise. L'application Ethereum 1.22.2, publiée le 13 août, était la première mise à jour de l'application contenant des vérifications d'état conçues pour stopper le chemin de substitution de transaction documenté.

Ledger a ensuite publié le SDK sécurisé 26.6.1 le 21 août. Cette mise à jour bloque les commandes entrelacées avant que le code de l'application ne les reçoive. Les applications ont ensuite été reconstruites en utilisant le SDK corrigé.

Ledger recommande désormais l'application Ethereum 1.22.3 ou ultérieure car la nouvelle version contient la protection SDK plus large et traite un autre défaut d'affichage de transaction. OneKey avait donc raison de dire que 1.22.3 est protégé, mais le premier correctif au niveau de l'application est apparu dans 1.22.2.

Comme l'a précédemment rapporté crypto.news, Ledger avait déjà déclaré que sa vulnérabilité de signature Ethereum était corrigée avant la divulgation publique.

Les utilisateurs doivent mettre à jour les applications via Ledger Live

Ledger a déclaré qu'il n'avait trouvé aucune preuve que des attaquants avaient exploité LSB 023 contre des clients. Aucune perte de cryptomonnaie n'a été publiquement liée à ce problème spécifique.

Les utilisateurs doivent ouvrir Ledger Live, installer les dernières applications de l'appareil et vérifier la version de l'application Ethereum sur le portefeuille matériel. La mise à jour du firmware seule ne remplace pas les applications construites avec un SDK affecté.

Les développeurs tiers doivent également examiner leur gestion d'état et reconstruire les applications avec le SDK sécurisé 26.6.1 ou ultérieur. Ledger a déclaré que la faiblesse avait été introduite en août 2025 et affectait les versions du SDK jusqu'à 26.6.0.

La divulgation fait suite à d'autres corrections de sécurité des portefeuilles matériels. Dans une couverture connexe, BitBox a corrigé deux défauts affectant l'installation du firmware et la gestion des adresses Bitcoin, également sans signaler d'exploitation confirmée.