153 sats \ 4 replies \ @joko 20 Nov 2023 \ on: How would you attack self-custody? bitcoin
Thanks for reading and linking our thread and my blog post!
Me and my colleagues were of course expecting something like this to happen sooner or later, but seeing it in the wild is a scary thing! Luckily our users seem to have read our warnings and so far we are unaware of anyone actually falling for this malware.
Browser malware:
I think that address replacement attacks are probably the most serious issue in bitcoin security and not exploited enough for people to be mindful of them yet. In hindsight, if the mentioned malware used this kind of attack, it would have probably be more successful than by just asking for the seed.
How many people really verify the address they are sending to via a second channel?
That's why I proposed to automate this process with signatures, where you could be sure that you have an address the exchange/person controls or that the exchange/person has an address you sent them. Silent payments with payment code registration on the hardware wallet is also something that would be perfectly suited for this.
Software wallet replacement:
What's really important is that the user has a chance of catching the issue. If he uses his hardware wallet correctly, he's safe. Education and UX help wonders here.
Replacing the change address doesn't work like that, since (at least with the BitBox02), the hardware wallet verifies that its change output is part of its own wallet.
How would I attack self custody?
I expect that at some point small software wallet developers as well as browser extention developers might get targeted. If an attacker is able to upload a compromised update of a software wallet, he could rug all users at once (which has happened in the past). With a compromised browser extension, he could do a wide scale address swapping attack.
Those, in my opinion, are the biggest risks to self custodial wallets right now.
I love the thoughtful blogposts and proposals @joko, keep them coming! I hope the SW & HW vendors can and work on these things more together. There are too many standards already, and all the different practices that are being used for self-custody aren't helping the end-user either.
Thanks for highlighting how the change address actually works. As I understand it the signature is only valid for the change address that is verified by the hardware wallet. So to attack the change address, you would need to attack the HW, which is more complicated than software.
Any idea/suggestions on protecting against address replacement when sending bitcoin as a user to anyone? Would that follow the same approach as in your blogpost if all wallets implement that? I guess so.
Right now, I'm considering doing a second verification over phone/chat/e-mail before sending bitcoin. Unfortunately, that cannot always be done since there will be many instances where the receiver also doesn't exactly know how their receive address is generated.
reply
Currently, address verification through a second channel is probably the only viable option.
As I mentioned, silent payments (or any other payment code scheme) could be very helpful for this. You verify the receivers payment code on your hardware wallet and through a second channel once, then register it with a name on your hardware wallet. Next time you want to send a payment to that person, you just use the payment code that's registered on your hardware wallet. It's a big UX improvement too, because you don't have to ask for a new address every time you make a payment to that person.
The downside as of right now is that those payment schemes have limited liteclient support, so the receiver needs to have a copy of the UTXO set.
reply
Coming back to the browser malware idea. I'm not a programmer, but with help of ChatGPT it took me 30 minutes to modify a Chrome extension to swap the BTC address shown on a HodlHodl contract with my own BTC address using Javascript.
I took this open-source wallet to try this out: https://github.com/iamadamdev/bypass-paywalls-chrome
Only a matter of time before someone deploys this attack vector.
reply
wallet = extension
reply