9 June 2020: XRP account misuse and transaction malleability
The XRP App for Ledger Nano was found to be vulnerable to an account misuse and a transaction malleability vulnerability.
An account in the blockchain named “XRP Ledger” is made of one or more ways to authorize transactions, usually a master key pair which can’t be changed. A secondary key pair, called a regular key pair, can also be authorized to sign transactions while keeping the master key pair offline.
A transaction has, among other fields, an
Account and a
SigningPubKey fields. The
SigningPubKey field is the representation of the public key that corresponds to the private key used to sign a transaction. This key must either be the master key or the regular key associated to the
An attacker might trick a user into signing a transaction with a different account than the one displayed on the client software, because the
Account field wasn’t displayed by the XRP app.
An attacker having compromised a user client software might trick him into confirming a transaction signed with another account than the one expected, leading to funds being transfered from this account instead of the expected one.
On a single Ledger Nano device (or on several devices initialized with the same seed), an attacker can replace the
Account field of a transaction with another one derived from the same seed.
An attacker can also replace the
Account field of a transaction with one to which the account is authorized as regular key.
From the XRP documentation, every transaction has the same set of common fields. The
Flags field can contain various options that affect how a transaction should behave. If set, the global flag
tfFullyCanonicalSig requires a fully canonical signature, otherwise it is theoretically possible for a malicious actor to modify a transaction signature so that the transaction may succeed with a different hash than expected. Transactions signed using the XRP app didn’t require the
tfFullyCanonicalSig flag to be set.
An attacker having compromised the user client can create a transaction without the
tfFullyCanonicalSig flag set. Once the transaction is signed and propagated to the network, it is theoretically possible for an attacker to try to win a race condition and trick the victim into seeing the transaction as failed.
It doesn’t seem to have security consequences in our opinion. Moreover the chances for an attacker to win the race and have an alternate transaction confirmed are low. They can be increased if some number of well-connected servers in the peer-to-peer network are controlled by the attackers, even if those servers are not trusted as validator.
Both vulnerabilities were fixed in the latest version (2.0.1) of the XRP app. A new XRP amendment should also enforce fully canonical signatures on all transactions at a protocol level.
We would like to thank the security researchers Patrik Sletmo and Markus Alvila from Towo Labs, who discovered the vulnerabilities and reported them through our bug bounty program.