Le XRP Ledger corrige un bug vieux de dix ans qui aurait pu créer des milliards de dollars en XRP à partir de rien
Points clés
- •La vulnérabilité, qui daterait de 2015, a été découverte par le chercheur Cayden Liao et Veria AI et signalée en interne le 22 septembre.
- •RippleX a reproduit l'attaque sur un serveur autonome et confirmé que le XRP créé pouvait être dépensé, mais n'a trouvé aucune preuve d'exploitation sur un réseau public.
- •Un correctif a été livré dans xrpld 3.4.1 le 25 septembre sans divulgation publique initiale, et comme le correctif réside dans le logiciel serveur, la couverture du réseau dépend de l'adoption de la mise à jour par les opérateurs.
- •L'exploit exploitait une erreur de comptage dans la bourse intégrée du registre, où des centaines de comptes publiant de petites offres pouvaient être payés intégralement à partir d'un seul paiement tandis que l'acheteur n'était débité de presque rien, laissant l'attaquant avec du XRP nouvellement frappé.
- •Les dispositifs de protection existants, notamment une vérification de l'offre après chaque transaction et une limite de réception par compte, n'auraient pas détecté l'attaque, qui ne nécessitait que quelques centaines de XRP et des frais standards pour être mise en place.
Une vulnérabilité dans le système de paiement du XRP Ledger aurait pu permettre à un attaquant de créer de grandes quantités de nouveaux XRP sans les payer, enfreignant la règle d'offre fixe du token, selon un rapport de sécurité publié vendredi.
Le bug, qui daterait de 2015, a été découvert par le chercheur Cayden Liao et Veria AI et signalé en interne le 22 septembre. Les ingénieurs de RippleX, la branche de développement de Ripple, ont reproduit l'attaque sur un serveur autonome — un environnement de test isolé — et confirmé que le XRP nouvellement créé pouvait être dépensé lors d'une transaction ultérieure.
RippleX a déclaré n'avoir trouvé aucune preuve que la faille ait été exploitée sur un réseau public. L'entreprise a livré un correctif dans xrpld 3.4.1, le logiciel serveur du registre, le 25 septembre, sans divulguer publiquement ce que corrigeait cette version — une séquence courante dans la divulgation coordonnée de vulnérabilités, qui laisse aux opérateurs le temps de se mettre à jour avant que les détails techniques susceptibles de permettre des attaques ne deviennent publics. Les détails ont ensuite été présentés dans le rapport de divulgation de vulnérabilité officiel de l'équipe. Comme le correctif réside dans le logiciel serveur lui-même, sa couverture sur le réseau dépend de l'adoption de la version mise à jour par les opérateurs.
Les chercheurs ont démontré comment un seul paiement pouvait créer du XRP dépensable sans que l'expéditeur le finance, ce qui a conduit à la publication logicielle d'urgence. Si la faille n'avait pas été corrigée, elle aurait pu violer l'offre fixe de 100 milliards de tokens de la cryptomonnaie.
Une menace directe pour le plafond d'offre
Les 100 milliards de XRP ont tous été créés au lancement du registre en 2012, et son logiciel est conçu pour qu'il soit impossible d'en ajouter davantage. Cette rareté étant garantie entièrement par le code plutôt que par une entité émettrice, un bug capable de frapper des tokens aurait porté atteinte à la garantie la plus fondamentale du registre. La vulnérabilité de sécurité aurait toutefois pu permettre à un attaquant de créer du XRP à partir de rien et de le vendre sur les plateformes d'échange, sapant le plafond d'offre strict sur lequel comptent les institutions qui construisent sur le réseau.
Comment l'attaque fonctionnait
'exploit ciblait la bourse intégrée du registre, où les comptes publient des offres d'échange d'un token contre un autre.
En théorie, un attaquant pouvait ouvrir des centaines de comptes, faire en sorte que chacun offre une infime quantité d'un token en échange d'une quantité inhabituellement importante de XRP, puis envoyer un seul paiement achetant toutes les offres à la fois. Le total de XRP dû sur ces offres combinées serait trop important pour que le logiciel le compte correctement. Résultat : les comptes vendeurs de l'attaquant seraient payés intégralement tandis que le compte acheteur ne serait débité de presque rien — laissant l'attaquant avec du XRP qui n'avait jamais existé auparavant.
En réalité, la vulnérabilité était une erreur de comptage dans la bourse intégrée, qui aurait pu permettre à des centaines de comptes de recevoir de grandes quantités de XRP tandis que l'acheteur ne payait presque rien.
Pourquoi les dispositifs de protection existants ne l'ont pas détecté
Le XRP Ledger effectue une vérification après chaque transaction pour s'assurer qu'aucun nouveau XRP n'est apparu, mais cette vérification se serait appuyée sur le total mal compté et n'aurait pas détecté l'écart. Une limite distincte concernant la quantité de XRP qu'un seul compte peut recevoir ne se serait pas déclenchée non plus, car l'attaque répartissait les tokens nouvellement créés sur des centaines de comptes.
La méthode des chercheurs ne nécessitait que quelques centaines de XRP pour ouvrir ces comptes — dont la plupart ont ensuite été récupérés — plus les frais de transaction standards.
Une faille s'inscrivant dans un schéma plus large
L'incident s'ajoute à une série de failles de sécurité crypto longtemps cachées et mises au jour avec l'aide de l'IA depuis juillet, incluant le bug du portefeuille Coldcard à l'origine du vol d'au moins 1 367 BTC et les vulnérabilités qui ont forcé Core Lightning à demander aux opérateurs de nœuds bitcoin de se déconnecter.
