A ransom attack on Trezor's and KeepKey's passphrase handling

[witcher_sense]

Vulnerability

"As a hardware wallet user, you should assume your computer and mobile phone are compromised, including any wallet software installed. That is the reason to use a hardware wallet in the first place.

Hence, it is important that the hardware wallet validates any input it receives from the computer. In this case, the passphrase should be confirmed with the user on the device before using it to derive the seed. The Trezor and KeepKey did not do this in the case of the passphrase entered on the computer.

As a consequence, a malicious wallet or a man-in-the-middle modifying data transferred via USB could send an arbitrary fake passphrase to the Trezor / KeepKey, and hold any coins received in this wallet hostage. The passphrase entered by the user could simply be ignored, and the actual passphrase used would be only known to the attacker.

If that happens, the Trezor and the computer wallet load normally, and the user has no way of noticing that an attack is ongoing, even if they use the hardware wallet flawlessly, verifying all receive addresses according to best practices. Receive addresses in the computer wallet match the address shown on the device as usual, but the addresses do not belong to the user: the attacker can lock access to them by withholding the passphrase needed to spend from them.

With some sophistication, the user wouldn’t notice that anything is off at all until the attacker blocks access to the coins, demanding a ransom for releasing the coins back to the victim.

Practically, the attacker could run a server from which the malicious wallet would fetch a fake passphrase every time the user unlocks the wallet, and stop serving the passphrase once there are enough coins in the wallet to be held to ransom. Without the passphrase, the user has no way of regaining control of the coins without the attacker’s cooperation."

Source: https://benma.github.io/2020/09/02/trezor-keepkey-passphrase.html

Personally, I would never try entering sensitive information, especially a passphrase, with a keyboard. I can't even imagine why Trezor still allows creating passphases through that way. According to firmware update log, they have no plans to remove it. In my opinion, a passphase should be created only on hardware device, otherwise it can be intercepted easily. The most severe vulnerability of Trezor is that it gives you an option to manually type information on a compromised computer.

[1714500668]

1714500668

[1714500668]

1714500668

[1714500668]

1714500668

[Rath_]

The most severe vulnerability of Trezor is that it gives you an option to manually type information on a compromised computer.

This has been mitigated in the latest software update. Trezor will display the passphrase on the device and ask for a confirmation.

In my opinion, a passphase should be created only on hardware device, otherwise it can be intercepted easily. The most severe vulnerability of Trezor is that it gives you an option to manually type information on a compromised computer.

I am surprised that they didn't make passphrase entry on Trezor One look like their advanced recovery. Trezor T users are able to enter the passphrase either on the device or the computer. I have no idea why the latter one is still a thing. I wouldn't say it's for compatibility reasons since they have already broken passphrase support for old software in April.

[NeuroticFish]

I've read that the vulnerability was "responsibly disclosed", so the fix should be available indeed.
Also I wonder, if the attack targets passphrase... can't the user simply reset the device and restore from the seed with new/own passphrase?!

[Rath_]

Also I wonder, if the attack targets passphrase... can't the user simply reset the device and restore from the seed with new/own passphrase?!

No, every time you plug in a Trezor device, it asks for a passphrase because it is not stored on the device. If the passphrase was stored on the device then this attack would not be possible, but at the same time it would not be possible to mitigate the seed extraction attack.

[HCP]

Also I wonder, if the attack targets passphrase... can't the user simply reset the device and restore from the seed with new/own passphrase?!

No... the private keys are derived using the passphrase... so, if the device was already "attacked", any private keys/addresses that had already generated/used, would have been generated using the "unknown" passphrase generated by the malware...

So, resetting the device, restoring from seed and setting up a new/own passphrase means that you would be generating completely different addresses.

It's basically abusing the "plausible deniability" functionality, whereby any passphrase is "valid", but generates a different set of private keys/addresses.

[Coin-Keeper]

This is mitigated using Trezor's new firmware updated to both the T and the original.  It would have taken operator error to fall victim before but NOW this is handled automatically by displaying the passphrase directly on the Trezor device and you look through it to confirm its correct.  Nice job Trezor




Edit --- I apologize this was mentioned above already.  My bad.

[witcher_sense]

This is mitigated using Trezor's new firmware updated to both the T and the original.  

In order to update your Trezor device and download firmware, you first have to visit wallet.trezor.io website, then you have to enter your pin code and your passphrase. What is interesting is that people may still fall victims to that vulnerability during firmware installation, because they still have an option to enter a passphrase with keyboard without confirmation on hardware device! I didn't see any warnings regarding that from Trezor developers and consider it severe incompetence. I am very disappointed. Is there any way to update Trezor without having to connect hardware device via USB? As far I know, Coldcard allows to update via SD-cards, what about Trezor?

[HCP]

In order to update your Trezor device and download firmware, you first have to visit wallet.trezor.io website, then you have to enter your pin code and your passphrase. What is interesting is that people may still fall victims to that vulnerability during firmware installation, because they still have an option to enter a passphrase with keyboard without confirmation on hardware device!

It's not really an issue... you can simply not enter a passphrase (ie. just leave the box blank and click enter) and then go ahead with the firmware update... besides, the passphrase vulnerability has no affect if you're not sending/receiving funds... as it doesn't matter what wallet you are "logged in" to when you're updating the firmware.

Also, it should be fairly obvious to anyone that has already been using their device if something "funny" happens when they attempt to log in, as they won't see any of their history/funds etc if a different passphrase is used to display their wallet... unless of course their system has already been compromised by this "theoretical" attack and they have already been affected by this fake passphrase vulnerability

[witcher_sense]

It's not really an issue... you can simply not enter a passphrase (ie. just leave the box blank and click enter) and then go ahead with the firmware update... besides, the passphrase vulnerability has no affect if you're not sending/receiving funds... as it doesn't matter what wallet you are "logged in" to when you're updating the firmware.

Also, it should be fairly obvious to anyone that has already been using their device if something "funny" happens when they attempt to log in, as they won't see any of their history/funds etc if a different passphrase is used to display their wallet... unless of course their system has already been compromised by this "theoretical" attack and they have already been affected by this fake passphrase vulnerability

This bold part is literally one of the most confusing fields in the bitcoin ecosystem newcommers are yet to understand or, at least, to take for granted. You either accept the fact that passphrase is not the same thing as common password meaning it can't be "wrong" or you dive deeper to learn formulas and how exactly addresses are generated in order to understand why it is so. Most newbies would be entering their own passphrases on a compromised computer. Their data still might be intercepted by attackers, naive users might make some transactions before updating the firmware. Trezor shouldn't have allowed to type sensitive information on a compromised computer. Never.

[HCP]

Yes... and Electrum should never have simply displayed "error" messages received from servers verbatim... hindsight is always 20/20... but at least they (both Satoshi Labs and Electrum) are actively working to patch these issues and make their products better.

[bob123]

Trezor shouldn't have allowed to type sensitive information on a compromised computer. Never.

Exactly.
The whole point of a hardware wallet is to be usable with compromised hardware and software without the risk of losing coins.
Requesting sensitive information via an insecure device (which should not put coins at risk even if it is compromised), basically has to go wrong.

Yes... and Electrum should never have simply displayed "error" messages received from servers verbatim...

Are you comparing electrums low-severity vulnerability a.k.a. just showing a message to compromising sensitive information of a hardware wallet by requesting input over an insecure device??
IMO that's absolutely not comparable. Not even close.

[HCP]

Sure, one is a theoretical attack that was discovered, responsibly disclosed and patched... and the other started as an "in the wild" attack that, sadly, has caused (and continues to cause) millions of dollars worth of loss... In both scenarios, the devs took action to patch the problem once it was discovered.

And arguably, both should never have been a possibility... but it's just the nature of systems development, there will always be flaws.

[bob123]

Sure, one is a theoretical attack that was discovered, responsibly disclosed and patched... and the other started as an "in the wild" attack that, sadly, has caused (and continues to cause) millions of dollars worth of loss... In both scenarios, the devs took action to patch the problem once it was discovered.

And arguably, both should never have been a possibility... but it's just the nature of systems development, there will always be flaws.

If you calculate the CVSS score of the electrum vulnerability, you'll end up with a score below 4 which basically means the severity is low.
This can not be said about the vulnerability from trezor.

While CVSS has its flaws, it still can be used to estimate the severity of vulnerability. And simply showing a message is by far not as severe as having influence on a passphrase.

[Rath_]

Is there any way to update Trezor without having to connect hardware device via USB? As far I know, Coldcard allows to update via SD-cards, what about Trezor?

No, you need to connect your Trezor either to a computer or an Android phone via USB. Currently, the SD card reader has only one functionality which helps to mitigate the unfixable seed extraction exploit.

[DaveF]

Makes you wonder if there is a way to set up some way that instead of using "off the shelf" software that they use a custom signed version. And then the hardware wallet checks the signature with a list of known good ones. And then the hw wallet sends a signature back that also has to be verified.

Sounds good in my head. Except for the fact that I just added a ton of more programming.  And you are more limited to wallet options.

-Dave

[bob123]

Makes you wonder if there is a way to set up some way that instead of using "off the shelf" software that they use a custom signed version. And then the hardware wallet checks the signature with a list of known good ones. And then the hw wallet sends a signature back that also has to be verified.

Sounds good in my head. Except for the fact that I just added a ton of more programming.  And you are more limited to wallet options.

What kind of software are you talking about? The firmware on the HW device or the software running on the PC?
I doubt they would allow other software to be patched onto the trezor.

And regarding the software on the PC, i doubt this would be feasible too. You'd need to evaluate what exactly is a "good" software. And you'd need to update the signatures quite frequently (i.e. after each update).
And for that, you'd need the user to actually start up the original trezor software again which would then transmit the new list (integrity-protected) to the HW device.
Sending a signature back from the HW device to the software isn't really necessary, since the computer can be compromised and a malicious version would not care about the signature and/or it could be spoofed.

[DaveF]

Makes you wonder if there is a way to set up some way that instead of using "off the shelf" software that they use a custom signed version. And then the hardware wallet checks the signature with a list of known good ones. And then the hw wallet sends a signature back that also has to be verified.

Sounds good in my head. Except for the fact that I just added a ton of more programming.  And you are more limited to wallet options.

What kind of software are you talking about? The firmware on the HW device or the software running on the PC?
I doubt they would allow other software to be patched onto the trezor.

And regarding the software on the PC, i doubt this would be feasible too. You'd need to evaluate what exactly is a "good" software. And you'd need to update the signatures quite frequently (i.e. after each update).
And for that, you'd need the user to actually start up the original trezor software again which would then transmit the new list (integrity-protected) to the HW device.
Sending a signature back from the HW device to the software isn't really necessary, since the computer can be compromised and a malicious version would not care about the signature and/or it could be spoofed.

I was thinking about about doing it both ways. The hardware wallets would have to update their firmware to run an app on itself that talks to the software to verify its authenticity.

The only reason I thought about it is that I have a client who has a time-clock that works list that. You have to use one of their USB sticks to take the punch in / punch out times from the time-clock and copy it to the PC if there is no way to hard wire / network the clock to the PC.

There is a bit of firmware on the stick that verifies the app on the desktop before it allows the pulling of the hours. You push a button on the stick with the SW open and it ether shows green or red on the LED.

The PC will see the stick as a normal USB drive until you run the app and then click the 'check transfer stick' button. It then verifies that it's the real stick and you can pull punch in / out data.

No idea how the back end works on either side, but you can't run non authentic software or pull the data from the clock with any old USB stick. They just will not talk to each other.

Something similar for HW wallets might be more secure. But, as I said, I have no idea how to implement it. Way way way above my ability.

-Dave