pull down to refresh

So, the recent NPM attack on several Bitcoin wallets (by address poisoning) is well-known by now. I have not done any on-chain transfer since then, and trying to stay updated about the developments.
I am using the Trezor one for cold storage, and Blockstream Green for some spending and transfer. So far, I have seen tweets on X from both Trezor and Blockstream claiming their toolchains are totally unaffected so far.
But, keeping up with the ethos of Bitcoin, instead of trusting, is it possible to verify? In particular, four distinct components here for which I wish for some kind of reasonably ironclad guarantees
  • Trezor One hardware
  • Trezor Suite
  • Blockstream Green Android version
  • Blockstream Desktop (AppImage version)
How to verify that they are not affected, if possible?

Remediation

If you are a package maintainer, there are a few ways you can check if you have been impacted, including:
  • Checking your local node_modules to see if it contains the malware: grep -R 'checkethereumw'
  • Checking your npm cache with this script by phxgg
  • Checking your project with this script by AndrewMohawk
If you are a user, make sure you are double checking any transactions you are signing to make sure the addresses are correct. For more information, you can refer to the SEAL Framework on signing and verifying transactions.
👀 #1213891
reply
It is an address swapping attack, so check that the send address showing on your device is the same as the send address showing on your screen. Send a small amount and see if the address got swapped
reply
Of course, but the question is also for desktop/mobile wallets where the application itself is the signer...and I am specifically asking how to verify the claim that their applications are unaffected.
reply
Again, you can try sending a small amount to test, then use an external application like mempool.space to see if it got sent to the address you actually sent it to.
reply
I doubt if it is a valid test in this instance. If the problem does not surface in one transaction how can I guarantee it will not surface in another transaction?
I am not the one who developed the malware, obviously. But if I were, and the malware had access to the transaction information (public key, amount etc.) then I would trigger it only for transaction worth beyond a threshold, like a few million Sats. The goal would be to delay the detection of its presence, and capture a few big fishes instead of a bunch of small fishes. If every transaction is poisoned, the exploit would come to the surface pretty fast, and people would stop falling for it, as is the case once it got widely publicised.
For all intent and purpose, I suspect the attacker had his day, and unlikely to gain any more, although likely made enough to retire. The window of opportunity is is just too small if the attack happens deterministically at every transaction.
reply
I don't think I can help you further then. You'd have to look into technical details beyond my know-how.
reply
11 sats \ 0 replies \ @ek 3h
If it swaps the address, you know which one you entered. Compare that one with the one it tells you you entered. No external signer needed.
I assume the swap happens before signing. But if it happens after signing, this means the attacker can also sign, in which case they would just drain your wallet immediately.
reply
11 sats \ 0 replies \ @adlai 6h
I think the payload will only affect wallets that actually load rebuilt code into some browser.... for sanely engineered apps that don't compulsively update to whichever haemorraging-edge code fell off the Internet anytime you looked away from the screen, it should not be a problem.
reply
Is Electrum wallet affected?
0 sats \ 0 replies \ @teremok 2h
As long as Javascript is not used (or its frameworks, say React, React Native, Electron) then it's not affected.
Not sure what those wallets use
reply
Tezor are expensive and also for those having lot of funds not managing 10 $
reply
A million odd sats, plus minus a few is not a lot, but when I was researching my choices, Trezor seemed to be the right one for me based on safet/security concerns and price.
Many recommend cold card, but seem they are more expensive. I hope a trezor one, even if not as feature rich, can at least be as secure.
reply
0 sats \ 0 replies \ @adlai 6h
well-known doesn't equal universally known; some folks just don't do much work with nodejs and aren't cybersecurity generalists who read CVEs for breakfast, so maybe consider linking to one of the writeups.
I gather it's impossible to edit the mean post, so here's one relatively recent article that seems to be from the second wave of coverage.
reply