How would you attack self-custody?
11.4k sats \ 38 comments \ @TSW 20 Nov 2023 bitcoin
Following these two recent events, how would you attack self-custody? https://nitter.net/BitBoxSwiss/status/1725491128521068958#m https://nitter.net/zachxbt/status/1720961400313373127#m
It would be interesting to learn what attack vectors we can come up with and how to protect against those. With the increasing purchasing power of bitcoin there will be more and more victims I expect, unfortunately.
The two attacks above are not sophisticated and even then people fall for them (at least the Ledger one). Users should have protected themselves by:
  • Ledger: Always verifying the software they use
  • BitBox: Never enter a recovery phrase in software that is meant for a physical signing device
If I were an attacker, I would try to develop the attack methods below.
Browser malware Attack: Replace receive addresses shown in the web browser with an address owned by the attacker. I would attack large exchanges receive addresses (Binance, Coinbase, etc.)
Methods:
  • URL hijacking/domain spoofing/clickjacking: Show different websites to the user
  • Cross-Site Scripting (XSS) attacks
  • Browser extension malware / man-in-the-middle (MitM)
Protection: Manually verify the address with the recipient support organization over the phone. Assume anything digital might be altered. Reverse of this proposal: https://bitbox.swiss/blog/securely-withdrawing-from-an-exchange/
FOSS wallet software replacement: Attack: I would host a malicious build of FOSS wallet software. Many users don't verify their software, so if you can get malicious software on their system, you can take control of their bitcoin. I would then build two methods that come into play when the user sends bitcoin:
  1. User sends most of their balance --> Replace receive address and hope the user doesn't verify the address on a physical signing device. I expect this success rate to be relatively low for users that use a signing device.
  2. User sends a small portion of their balance --> Replace the change address as users typically do not verify that. Update the user's balance in the GUI to show the expected balance. This is a more complicated attack but can go unnoticed until the user runs out of funds or performs manual UTXO control.
Protection: Not sure. Also, I am unsure how successful this attack could be as I don't understand change addresses deeply enough. Relevant: https://blog.coinkite.com/troublesome-change/
How would you attack self-custody?
write
preview
related posts
153 sats \ 4 replies \ @joko 20 Nov 2023
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.
reply
14 sats \ 3 replies \ @TSW OP 21 Nov 2023
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
100 sats \ 2 replies \ @joko 21 Nov 2023
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
10 sats \ 1 reply \ @TSW OP 21 Nov 2023
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
0 sats \ 0 replies \ @TSW OP 21 Nov 2023
wallet = extension
reply
54 sats \ 1 reply \ @0xbitcoiner 20 Nov 2023
I was robbing the victim's house and looking for papers/etc with random words written on them 😂
reply
0 sats \ 0 replies \ @TSW OP 20 Nov 2023
Sounds easier! ;)
reply
20 sats \ 1 reply \ @OT 20 Nov 2023
I think the main one is verifying the software.
Got to admit that I can be lazy with that stuff. Important wallets I do but I should probably make a habit of verifying EVERY app just in case.
reply
0 sats \ 0 replies \ @TSW OP 21 Nov 2023
Yes, that is a good start. Still doesn't protect you from anything else that happens on your phone/computer though. I personally believe that browsers are one of the greatest weaknesses with all the extensions and code that websites run on them. So address swapping in a browser is more likely than in a native app. That's why I use Nunchuk as wallet software.
reply
33 sats \ 16 replies \ @Zepasta 20 Nov 2023
deleted by author
reply
228 sats \ 14 replies \ @davidw 20 Nov 2023
NVK says hi... https://twitter.com/nvk/status/1726392947543867640
reply
11 sats \ 13 replies \ @Zepasta 20 Nov 2023
deleted by author
reply
10 sats \ 12 replies \ @davidw 20 Nov 2023
His point is that even Raspberry Pi hardware cannot be trusted these days. I should have made that clearer.
reply
0 sats \ 11 replies \ @Zepasta 20 Nov 2023
deleted by author
reply
10 sats \ 10 replies \ @0330830bf9 21 Nov 2023
No hardware can be. Shouldn't trust coldcard especially.
This is why 2:2 is necessary to mitigate any single compromised supply chain.
reply
0 sats \ 2 replies \ @Zepasta 21 Nov 2023
With a DIY solution like SeedSigner you are not trusting the hardware, the data is stored temporarly on RAM and wiped when you plug the cable off. Its completely different from an hardware wallet that stores data inside permanently.
reply
3 sats \ 1 reply \ @0330830bf9 21 Nov 2023
Maybe if you bring your own entropy, I haven't gone through the seedsigner docs but I do like that it's commodity hardware.
I'm convinced most hww are Intel agency honeypots and would never use one in a 1:1
view replies
0 sats \ 6 replies \ @TSW OP 21 Nov 2023
Curious to learn why you would use a 2:2 and not a 2:3 or another setup where you protect yourself from a single point of failure?
reply
10 sats \ 5 replies \ @0330830bf9 21 Nov 2023
This has been written about by others who make good points about the 3rd being superfluous. A 3rd key adds the complexity of where you store it, practicing recovery etc. I'm sure there are cases for it but I don't think added failure proofing is one of them.
With 2:2 the average pleb can simply have a clean laptop and 1 hww safely. One key given to family for inheritance, the other with a secret dead man switch.
That covers most usecases without added user fuckup risk.
view replies
0 sats \ 0 replies \ @TSW OP 21 Nov 2023
If you really believe that is the only attack vector then you haven't read my entire post I guess...
reply
100 sats \ 2 replies \ @BlueSlime 21 Nov 2023
Nonce tampering would be my bet.
  • BIP340 recommends adding random auxiliary data to the nonce formula, which eliminates deterministic generation.
  • If you can't replay how the nonce was generated, you can't verify if the nonce has been tampered with.
  • There are a number of ways to compromise the nonce value so that a signature from your device leaks your private key.
  • You can even execute this attack on a firmware or hardware level, so that no software changes are required.
ECDSA standard currently specifies a deterministic k value, but for other reasons. I think nonce verification is a pretty good reason though, as the current nonce formula is just 1 operation away from leaking your private key.
I have noticed that wallets are now taking to adding randomness to their k values. Which is probably fine because wallet providers are mainly good actors who do take measures to secure their software and infrastructure.
However if nonce generation were to be compromised, you wouldn't be able to replay the signature on a different device in order to prove it. It would be impossible to know!
Kind of scary to think about to be honest.
reply
0 sats \ 1 reply \ @TSW OP 21 Nov 2023
Ah yes, I just learned about that in this episode: https://fountain.fm/episode/XlD5eSY0ekb1pjDXAwmU
I haven't listened to that episode again, but it would require a certain amount of transactions to leak the private key right? Still, if that is already on the firmware level then that is bound to happen at some point if the number of transactions required is not too large.
reply
10 sats \ 0 replies \ @BlueSlime 21 Nov 2023
you can perform this attack with a single transaction
reply
42 sats \ 1 reply \ @Coinosphere 20 Nov 2023
The way we are going to see it most attacked, both by opponents of bitcoin and by bitcoiners who prefer custodians of some kind, is simply by gaslighting everyone to make them believe that they are not smart enough to self-custody.
I've already seen it happening by new bitcoiners quite often... Daily some days. They call you crazy for self-custodying because they "know" that no human is capable of properly securing their own wealth. Such a low opinion they have of both people and bitcoin.
reply
0 sats \ 0 replies \ @TSW OP 21 Nov 2023
Yes. I use a custodian that hosts one key from my 2-of-4, but I always control the majority. I will never use those new services where you spread your keys over multiple custodians. They can basically ransom your bitcoin as a group!
reply
10 sats \ 2 replies \ @designsats 21 Nov 2023
  • write a law criminalizing self-custody
  • wait until 90% of cucks decide not to be criminals
  • done
Easy as that.
reply
0 sats \ 1 reply \ @TSW OP 21 Nov 2023
Very true, I expect that will happen as well in certain countries.
reply
0 sats \ 0 replies \ @designsats 21 Nov 2023
certain US and EU
reply
10 sats \ 0 replies \ @anon 21 Nov 2023
it would be a physical attack and it would be really nasty. i think you would have to cross some lines to be successful.
reply
0 sats \ 1 reply \ @brave 21 Nov 2023
This is far beyond my scope but would Brute force attack take too long
reply
0 sats \ 0 replies \ @TSW OP 21 Nov 2023
In the future this will of course become a problem when processing power has increased drastically. But that is a risk for Bitcoin as a whole and needs to be resolved at that time.
reply
0 sats \ 0 replies \ @02df4abd70 22 Nov 2023 freebie
The highlighted vulnerabilities in self-custody solutions are concerning. The potential for attacks, especially through browser malware or malicious software, underscores the need for rigorous verification processes and heightened user awareness. Vigilance in confirming addresses and ensuring software integrity remains paramount to safeguarding against such threats in self-custody practices.