9 June 2020: XRP account misuse and transaction malleability
Summary
The XRP App for Ledger Nano was found to be vulnerable to an account misuse and a transaction malleability vulnerability.
Account misuse
Technical Details
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 Account field.
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.
Impact
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.
Transaction malleability
Technical Details
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.
Impact
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.
Remediation
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.
Credits
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.