Ledger a rejeté les affirmations selon lesquelles il aurait été piraté après que l'équipe de sécurité Anzen de OneKey a reproduit une faille de remplacement de transaction contre 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 que 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 des appareils Ledger.
- Ledger n'a trouvé aucune preuve que la vulnérabilité ait été exploitée contre des utilisateurs ou ait causé des pertes de cryptomonnaies où que ce soit.
Le fondateur de OneKey, Yishi Wang, a déclaré le 27 août que les chercheurs avaient réalisé l'attaque contre l'application Ethereum 1.22.1 en laboratoire. Ledger a confirmé la vulnérabilité sous-jacente mais a déclaré avoir déjà corrigé l'application concernée avant que OneKey ne publie sa démonstration.
La faille de Ledger Ethereum a brisé la garantie d'affichage de confiance
La vulnérabilité concernait la communication entre un appareil Ledger et son hôte connecté. Les applications Ledger reçoivent des instructions appelées commandes Application Protocol Data Unit, ou APDU, provenant de logiciels de portefeuille, de pages web ou d'autres interfaces.
Une application affectée pouvait accepter une deuxième commande APDU pendant que l'utilisateur examinait une opération précédente sur l'écran de l'appareil. La nouvelle commande pouvait écraser les paramètres de signature stockés en 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 n'avertirait pas l'utilisateur que les informations sous-jacentes avaient changé.
Ledger a classé le problème comme une condition de concurrence entre le moment de la vérification et le moment de l'utilisation. Son bulletin a déclaré que la faille a vaincu 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 récupération 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 affiché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 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 se situait dans la gestion des entrées et 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 revue 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 si elle était construite avec le SDK affecté.
Ledger conteste que le test constitue un piratage
Wang a décrit le résultat de laboratoire en disant : « nous avons piraté Ledger ». Il a également déclaré que l'entreprise 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 qualifié le travail de OneKey d'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, a été la première mise à jour d'application contenant des contrôles d'état conçus pour arrêter 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 version plus récente contient la protection SDK plus large et corrige un autre défaut d'affichage des transactions. OneKey avait donc raison de dire que 1.22.3 est protégé, mais la première correction au niveau de l'application est apparue dans 1.22.2.
Comme crypto.news l'a précédemment rapporté, Ledger avait déjà déclaré que sa vulnérabilité de signature Ethereum avait été corrigée avant la divulgation publique.
Les utilisateurs doivent mettre à jour les applications via Ledger Live
Ledger a déclaré n'avoir trouvé aucune preuve que des attaquants aient 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 pour 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 revoir 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 a été introduite en août 2025 et a affecté les versions du SDK jusqu'à 26.6.0.
La divulgation fait suite à d'autres correctifs de sécurité pour 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.
