tl;dr: When registering a multisig wallet in a Coldcard, the Coldcard did not verify that it is actually part of the multisig wallet. This allowed a malicious computer wallet to replace the multisig xpubs with xpubs controlled by an attacker, while still passing all user verification. All coins received to this multisig wallet could then be transferred to the attacker’s wallet at any time. Multi-vendor setups where Coldcards are used for a subset of the cosigners can also be affected. Users are advised to upgrade before creating a multisig wallet, and to verify the integrity of their existing multisig wallets.
Hugo of Nunchuk and I (Shift) responsibly disclosed the remote exploit to Coinkite (Coldcard) on November 7th, 2020. Coinkite was informed in advance and accepted that we would publish a public disclosure of the exploit in February. Coinkite released a fix on January 8th, 2021, in firmware version 3.2.1. Their release notes and other public communication did not mention this as being a security issue or otherwise convey the urgency to upgrade.
My request for a bug bounty was ignored. Hugo stated that he was not interested in a bug bounty, and did not request one.
UPDATE Februrary 14th, 2021: after this article has been published, Coinkite added the more explicit post Version 3.2.2 Update Recommended (Multisig Security Update) to their blog on February 9th, 2021.
Multisignature wallets are wallets which require multiple keys to fully authorize a transaction, instead of just one. With hardware wallets, this means that multiple devices have to sign a transaction to authorize it. Using multisig is a popular strategy to avoid a single point of failure, making it more difficult for the wallet to be compromised.
An xpub, short for extended public key, is used to derive all the receive addresses in an account. Depending on context, an “xpub” can also be called a “ypub” or a “zpub”. In the case of multisig, each cosigner owns one xpub. All cosigner xpubs and some additional metadata are combined to generate multisig receive addresses. Each cosigner also owns the corresponding extended private key, which is needed to authorize spends from such an account.
When creating a multisig wallet, it is crucial that you verify the xpub of each cosigner correctly. Otherwise, you could be exposed to remote theft or ransom attacks. I described these issues in detail in this blog post: How nearly all personal hardware wallet multisig setups are insecure.
To use a Coldcard as part of a multisig wallet, you first have to register the multisig configuration on the device. This is done by exporting a multisig description file from the computer wallet to a microSD card and then loading that file in the Coldcard. This file contains, among other information, the cosigner xpubs (
Zpub... in the example below) involved in the multisig setup:
Name: Coldcard multisig Policy: 2 of 2 Format: P2WSH Derivation: m/48'/0'/0'/2' 1BE40472: Zpub75MwJZu4ZXeroKjEWHr5jSVaV6LNQ12i45jstLQmjHHDPUX8CVJZTQXtyd5L8T1jGvFVyUvG4wvc33UvknGzGime9BzNKtkFLQq78HkjKtf CF989E25: Zpub74GaScBjfF8ihMxzAxrAzUYjPQowg7Dng4qDH3sAXk3CCkpUCv9EmM2o37AA1srGQAZZQPWyy9p6ywMKeRazESo2keVubGXAbG39JYXZeiY
The last two lines show the xpubs (
Zpub...), one for each cosigner, for a 2 of 2 multisig setup.
When loading and registering this wallet in the Coldcard, you can verify all this information on the Coldcard screen. The purpose of the registration is that afterwards, you can easily generate receive addresses on the device without having to verify the cosigner xpubs every time. By verifying a receive address on the device screen, you can receive coins on this address safely, knowing that the multisig cosigners can spend them again.
Details of the attack
When the Coldcard loads a multisig description file while setting up the wallet, it is supposed to fully validate the contents of the file. Most importantly, it has to verify that it is part of the multisig, in other words: that it owns one of the listed multisig xpubs. This check was missing from the Coldcard up to and including version 3.1.9. This allows a malicious computer or wallet app to submit xpubs not owned by any Coldcard, but instead owned by the attacker.
After loading the file, the Coldcard proceeds and displays the xpubs on the device screen for user verification. Verification will succeed, as the malicious computer or wallet app merely has to replace the xpub of any Coldcard that is part of the multisig wallet, and display the fake xpubs in the wallet app on the computer as if they were the real ones. If the xpub is loaded from a microSD card instead of via a USB connection, the compromised computer can replace the xpub found on the microSD card before it is used for verification or to create the multisig description file.
Since the Coldcard does not offer a way to display its xpub on the screen on demand, verifying a cosigner xpub by displaying it on the respective Coldcard is also not possible.
Impact and severity
Multisig wallets are often used with the intention to increase security and therefore can be expected to hold large balances, making them an attractive target.
Since the attack presented here can be performed remotely, it counts as a critical issue according to Shift’s security assessment guideline.
The attacker is able to let you use the multisig wallet for an arbitrary amount of time. You would receive and spend coins, as if nothing was wrong, until the balance is big enough for the attacker to strike. This is because the attacker can create and store malicious xpubs (and the corresponding private keys) in the compromised app, enabling them to create, sign and send valid transactions at will, while making it look like you are in control, including successful verification on all hardware wallets.
The attack scales very well without scaling costs: an attacker who has compromised lots of computers, for example via a malicious app download page, can autonomously run the attack in parallel on many victims and wait until enough coins can collectively be stolen.
If the attacker owns all xpubs (or enough such that the number of uncompromised xpubs never reach the required threshold to spend), all coins sent to the multisig wallet are in full control of the attacker. If the attacker owns a subset of all xpubs, then depending on the multisig threshold, the attacker can either hold the coins to ransom, or is still able to authorize a transfer to the attacker’s wallet.
- In a 2-of-3 multisig, if the attacker owns two xpubs, they have sole control.
- If they own one of the two xpubs in a 2-of-2 multisig, you can’t spend the coins without the attacker’s cooperation. This would enable the attacker to demand ransom to release the coins back into your custody.
- In a 2-of-5 multisig, if the attacker owns two xpubs, they can still transfer the coins elsewhere, unless you do so first.
This means that multisig setups can be affected even if some of the keys are managed by wallets other than the Coldcard.
Multisig setups in which you handle only one key can also be vulnerable, even if the other cosigners are not compromised and act independently to receive coins and authorize transactions. For example: 1-of-2 and 2-of-2 multisig wallets. Other configurations can also be vulnerable, e.g. if a cosigner’s key is lost and your key is required to restore access.
Only if all cosigners are Coldcards, you created the multisig wallet by passing the microSD card from Coldcard to Coldcard without involving a computer, and did the setup by yourself, this vulnerability does not apply, as malicious computers or third parties are excluded from the setup process.
How we discovered the attack
I recently wrote a blog post about how nearly all personal hardware wallet multisig setups are insecure, discussing some pitfalls related to the verification of xpubs in multisig, and how different hardware wallets fare in this regard. Initially, I mistakenly claimed that the Coldcard didn’t provide a way to show its own xpub on demand on the device screen for verification. Michael Flaxman pointed out that it was possible by first getting the device fingerprint, and then use that to identify the device’s xpub in a registered multisig wallet (note that this only works if the wallet was set up safely):
Hugo followed up, stating the the child xpub used in the multisig needs to be verified, instead of the master xpub:
Following this public conversation, Hugo sent me a private message to clarify how this all works. I explained:
Then inSettings -> Multisig Wallets -> <wallet> -> View Details, you can find the Coldcard's xpub below the device fingerprint.
To which Hugo replied:
that's not good enough I think
why not? [...] assuming coldcard verifies its own xpub of course. should probably double check that
Hugo was thinking the same thing. Our messages crossed, as he wrote:
or maybe when Coldcard does the import, it does check one of the XPUBs belong to it. hmm.
We then decided to verify this. Hugo tried and succeeded to load a multisig description file with malicious xpubs, while I went to check firmware code. Afterwards, I corroborated Hugo’s finding and elaborated it by making a proof of concept to display a malicious receive address on the Coldcard.
What should I do to stay safe?
If you have a multisig wallet on a Coldcard, you were potentially exposed to the attack outlined above. To ensure your funds are safe, you can do one of the following:
- Export the multisig xpubs from your hardware wallets to a computer you know to be secure, and recreate the multisig wallet using e.g. Electrum.
- Upgrade your firmware and recreate the multisig wallet on your Coldcard following best practices. Be sure to only do this after verifying that your backups are valid.
If the addresses and balance match your expectations, you should be safe.