Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Case study: fake hardware cryptowallet

kaspersky.com

Post reply on HN
Print view View original

81–90 of 160 posts

Re: Case study: fake hardware cryptowallet

#81

Post by whimsicalism »

BobTheDestroyer wrote: post #34

Trezor has additional checks that aren't covered here. I'd really like to know how those were defeated. Especially: > All Trezor devices are distributed without firmware installed - you will need to install it during setup. This setup process will check if firmware is already installed on the device. If firmware is detected then the device should not be used. >The bootloader verifies the firmware signature each time…

They replaced the whole microcontroller. Doubt that these checks could resolve this if they were sophisticated enough.

Re: Case study: fake hardware cryptowallet

#82

Post by sneak »

Gigachad wrote: post #26
TacticalCoder wrote: post #23

Another nasty supply chain attack exists, way simpler (unlikely to work on knowledgeable users though)... A legit hardware wallet is shipped, but with fake documentation accompanying it. Some evil people working for delivery companies would swap legit hardware wallet for the exact same model, but with documentation using the official company's logo and font and saying, basically: "Here's your hardware wallet, initial…

There have also been cases of software using malicious seed generators which have semi predictable outputs. People assume it’s safe because they see what looks like random seeds, combined with no network activity. But the attacker can then just scan over the whole possible key space and check for funds.

A classic from 2008. Probably not malicious, but no way to prove a negative.

https://en.m.wikinews.org/wiki/Predictable_random_number_gen...

Re: Case study: fake hardware cryptowallet

#83

Post by rippercushions »

quickthrower2 wrote: post #75
lxgr wrote: post #36

For physically hardened devices, this attack vector can be mitigated quite efficiently by including an attestation key with each device and validating that after taking possession (or ideally before any interaction). At least one competitor does that. To my knowledge, current Trezor devices are unfortunately not (sufficiently) key extraction proof, though; in that scenario, attackers might be able to extract the priv…

How secure is the attestation key against the wallet CEO's kids being held hostage?

Obligatory $5 wrench xkcd: https://xkcd.com/538/

Still, physically threatening/kidnapping somebody is an entirely different threat model, although it's very common in the Bitcoin world: https://github.com/jlopp/physical-bitcoin-attacks

Re: Case study: fake hardware cryptowallet

#84

Post by saganus »

lisper wrote: post #78
saganus wrote: post #66

Earlier quoted context omitted.

I remember when this came out, and was interested in getting one! Unfortunately I was aiming to use it to generate TOTP codes (and replace my authenticator app), but IIRC it needed a RT clock and thus a battery, which was not part of the design. Great project though.

You could feed it time info through the USB interface.

That was actually my first line of thought as well, but I could never find a way to do that.

My low-level development expertise is pretty low, so perhaps there is a way, but after looking through the USB specification and other USB-development related docs, I just could not figure it out unfortunately.

The closest thing I found was to do someting like this (https://stackoverflow.com/questions/13335402/unable-to-sync-...) but I never did.

Do you think that would have worked?

Re: Case study: fake hardware cryptowallet

#85

Post by web3-is-a-scam »

BobTheDestroyer wrote: post #34

Trezor has additional checks that aren't covered here. I'd really like to know how those were defeated. Especially: > All Trezor devices are distributed without firmware installed - you will need to install it during setup. This setup process will check if firmware is already installed on the device. If firmware is detected then the device should not be used. >The bootloader verifies the firmware signature each time…

Ah yes, flashing my own firmware. The future of finance.

Re: Case study: fake hardware cryptowallet

#86

Post by stevage »

Would someone be able to spell out how this attack works after initialisation? I don't really understand hardware wallets. How does the information about the user and their key make its way back to the people who created the device?

Re: Case study: fake hardware cryptowallet

#87

Post by valleyer »

stevage wrote: post #86

Would someone be able to spell out how this attack works after initialisation? I don't really understand hardware wallets. How does the information about the user and their key make its way back to the people who created the device?

The attackers know the key to begin with, before the user even gets their hands on the device. The compromised device pretends to generate a random key but instead generate one of twenty keys provided by the attackers.

Re: Case study: fake hardware cryptowallet

#88

Post by latchkey »

1ark wrote: post #12
themagician wrote: post #5

Incredible. This is so sophisticated and takes so much effort it makes you wonder just how many other wallets are compromised from before you even use them. There are so many other low effort attacks you can run that the fact that people are doing THIS really makes me wonder just how many wallets out there are 100% compromised. It would be trivial for any iOS-based software wallet to compromise your seed before your…

There was a recent drainage of many wallets, even old untouched ones on Ethereum. I don't think it was resolved. Your scenario is likely imo, and the fictional quote was what I saw.

It isn't resolved, but there is a clue... a lot of the users had keys stored in LastPass.

Re: Case study: fake hardware cryptowallet

#89

Post by drexlspivey »

What would have prevented this attack is the following:

Use a little bit of python (there are libraries for this or you can do it yourself) to make sure that the addresses generated in the HW wallet by the 12 word mnemonic are indeed the correct addresses. For example the first segwit address using your private key and the derivation path 49h/0h/0h/0/0 should be deterministic. This way you know your 12 words are the ones used and the wallet is using known standards and not some homebrew crypto.

In fact you should always do that anyway in case the HW stops working and/or the company goes under. This way you can be sure that you can recreate your private keys from your mnemonic and access your funds no matter what.

Re: Case study: fake hardware cryptowallet

#90

Post by BobTheDestroyer »

web3-is-a-scam wrote: post #85
BobTheDestroyer wrote: post #34

Trezor has additional checks that aren't covered here. I'd really like to know how those were defeated. Especially: > All Trezor devices are distributed without firmware installed - you will need to install it during setup. This setup process will check if firmware is already installed on the device. If firmware is detected then the device should not be used. >The bootloader verifies the firmware signature each time…

Ah yes, flashing my own firmware. The future of finance.

It's an automatic update. All you have to do is watch the progress bar fill up. Even you could manage it.
Post reply on HN