Electrum 4.8.3 corrige une attaque de serveurs malveillants exploitant les hausses de frais Bitcoin
Points clés
- •La version 4.8.3 d'Electrum, taguée le 23 octobre et accompagnée d'un avis public le 24 octobre, corrige une vulnérabilité permettant à des serveurs malveillants d'afficher de fausses transactions sortantes avec des signatures invalides dans l'historique du portefeuille.
- •L'attaque exploitait le replace-byfee : lorsqu'un utilisateur majorait les frais d'une fausse transaction à frais nuls, la nouvelle signature autorisait le paiement modifié vers une adresse contrôlée par l'attaquant.
- •Deux utilisateurs ont signalé des incidents, et l'un d'eux, ayant majoré les frais d'une fausse transaction le 18 octobre, a perdu un montant non divulgué de fonds.
- •Le correctif vérifie les signatures des transactions non confirmées dépensant des pièces depuis les adresses du portefeuille, tandis que les transactions entrantes non confirmées restent non validées, Electrum n'ayant pas de moteur de consensus complet.
- •Les utilisateurs de versions antérieures à la 4.8.3 doivent mettre à jour ou vérifier manuellement les adresses de destination et les montants à l'écran de signature avant d'approuver toute transaction, y compris les majorations de frais.

Une vulnérabilité de gravité élevée du portefeuille Bitcoin Electrum a été corrigée dans la version 4.8.3, après que des attaquants ont trouvé le moyen de transformer le mécanisme replace-by-fee de Bitcoin en une voie de vol de transactions signées. Le développeur d'Electrum SomberNight a révélé le problème dans un avis de sécurité du 24 octobre, indiquant que certains serveurs menaient l'attaque dans la nature. Deux utilisateurs ont signalé des incidents ; l'un a perdu des fonds.
L'attaque nécessite la signature du propriétaire
Un serveur malveillant ne peut pas dépenser les bitcoins d'autrui de sa propre initiative. La fausse transaction qu'il insère comporte des signatures invalides, le réseau la rejetterait donc. Ce dont l'attaquant a besoin, c'est d'une signature valide du propriétaire du portefeuille, et le piège est conçu pour l'obtenir via une augmentation des frais.
Le replace-by-fee (RBF) accélère un paiement Bitcoin en attente en le remplaçant par une nouvelle version qui paie des frais plus élevés. Pour l'utilisateur, cela ressemble à un simple réglage. Pour le réseau, il s'agit d'une toute nouvelle transaction, et sa signature autorise chaque destination et chaque montant qu'elle contient. Si la transaction « majorée » a déjà été modifiée, la nouvelle signaturerouve la version altérée.
L'appât est un paiement qui semble bloqué. Dans le cas où un utilisateur a perdu de l'argent, le serveur a construit sa fausse transaction avec des frais nuls, ce que les développeurs interprètent comme une incitation à majorer les frais. Une transaction sans frais reste non confirmée, et l'augmentation des frais est la réaction standard.
Comment un serveur malveillant a tendu le piège
Electrum est un portefeuille léger : il ne télécharge ni ne vérifie lui-même l'intégralité de la blockchain. Selon sa documentation, le portefeuille se connecte généralement à une dizaine de serveurs mais s'appuie sur un serveur principal pour l'historique des transactions et la diffusion. Les autres fournissent principalement les en-têtes de blocs et les estimations de frais. L'avis souligne que la confiance accordée au serveur principal pour les transactions non confirmées fait partie de la conception documentée d'Electrum. Ce qui est nouveau, c'est une méthode concrète de transformer cette confiance en vol. Ce compromis est le contexte de l'attaque : déléguer la vérification est ce qui rend un portefeuille léger léger, mais cela signifie aussi que l'historique qu'il affiche n'est fiable qu'à hauteur du serveur principal qui le fournit — et avant la 4.8.3, une entrée sortante avec des signatures invalides pouvait apparaître dans cet historique comme si elle était réelle.
Jusqu'à l'étape de signature, rien n'est perdu. Une signature numérique valide peut autoriser le mauvais paiement si la transaction présentée à la signature a été modifiée, et c'est précisément ce que fournit la majoration des frais.
Ce que les deux victimes ont vu
Le premier signalement est venu de l'utilisateur dannydeezy le 11 octobre. Le paiement était envoyé depuis un portefeuille multisignature 2-sur-3 sécurisé par deux appareils matériels Trezor, combinant 31 entrées en une seule sortie. L'utilisateur a vérifié la destination sur les deux Trezors, puis a diffusé la transaction. L'historique d'Electrum a ensuite montré la totalité du montant en route, non confirmée, vers une adresse inconnue, avant que l'entrée ne passe en « Local ». Rien n'a jamais atteint le mempool.
La fausse transaction était soigneusement construite. Elle utilisait les mêmes entrées et copiait les données de signature de la transaction réelle octet par octet, de sorte que les 62 signatures correspondaient au paiement authentique et aucune à la fausse. Elle envoyait presque tout vers une adresse se terminant par « GyQ3 » — les mêmes quatre caractères que la véritable destination — et renvoyait un petit montant vers l'une des adresses du portefeuille lui-même, imitant une sortie de monnaie normale. Les frais étaient proches de zéro. Comme l'utilisateur n'a pas signé à nouveau, la transaction réelle est restée valide et non diffusée, et aucun n'a été perdu.
Les développeurs n'ont identifié la voie de la majoration de frais qu'après qu'un second utilisateur, Raju-K12, a signalé le 18 octobre avoir perdu de l'argent après avoir majoré les frais d'une fausse transaction. Le montant n'a pas été divulgué.
- 11 octobre : premier signalement privé, sans l'angle de la majoration de frais
- 18 octobre : second signalement, après une perte due à une majoration de frais
- 23 octobre : version 4.8.3 taguée avec le correctif
- 24 octobre : publication des binaires et de l'avis
Ce que la 4.8.3 corrige, et ce qu'elle ne corrige pas
Le correctif fait vérifier par Electrum les signatures de toute transaction non confirmée dépensant des pièces depuis les adresses du portefeuille lui-même avant de l'ajouter à l'historique. Un faux paiement sortant avec des signatures invalides est désormais rejeté au lieu d'être affiché, ce qui referme cette voie d'attaque.
La vérification est délibérément étroite. Les transactions entrantes non confirmées ne sont toujours pas validées, et l'avis explique pourquoi : Electrum n'a pas de moteur de consensus complet, et vérifier les entrées d'autrui impliquerait de remonter leurs transactions parentes non confirmées jusqu'à des transactions déjà minées. Les transactions confirmées étaient déjà vérifiées par la vérification de paiement simplifiée, qui les contrôle par rapport aux en-têtes de blocs.
Les utilisateurs qui se connectent uniquement à des serveurs de confiance, comme le leur, n'ont pas été affectés. Cette exemption ne s'étend pas au serveur public que le portefeuille choisit comme connexion principale.
Avant de signer à nouveau
-
Mettre à jour vers la 4.8.3. Téléchargez-la depuis le site officiel d'Electrum et vérifiez la signature du fichier en suivant les instructions du site.
-
Vérifier l'adresse complète. Comparez-la avec la facture ou la demande de paiement d'origine, et non avec l'historique du portefeuille, que l'attaquant contrôle.
-
Confirmer sur l'écran de l'appareil. Vérifiez les montants et les frais à chaque nouvelle signature. Le guide RBF et le guide d'envoi de Trezor demandent tous deux aux utilisateurs de vérifier les détails mis à jour sur l'appareil.
-
Transaction bloquée ou modifiée ? Arrêtez-vous. Consultez l'identifiant de transaction d'origine sur un explorateur de blocs indépendant avant toute majoration. Dans le premier signalement, le paiement réel n'avait jamais atteint le réseau.
Quiconque ne peut pas encore mettre à jour dispose d'une parade dans l'avis : à chaque signature de transaction, avec ou sans majoration de frais, vérifier que les adresses de destination et les montants correspondent exactement à ceux attendus. Les versions antérieures à la 4.8.3 n'effectuent pas la nouvelle vérification des signatures ; pour ceux qui utilisent encore une ancienne version, cette vérification manuelle est la seule protection contre cette voie d'attaque. Le correctif referme cette voie spécifique, mais Electrum dépend toujours de son serveur principal pour les données non confirmées ; l'écran où un paiement est approuvé reste donc le dernier contrôle.
Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou d'investissement.
Source : Coindoo