How to Verify the Impact of the Recent NPM Attack on My Wallets? \ stacker news ~bitcoin

pull down to refresh

How to Verify the Impact of the Recent NPM Attack on My Wallets?

400 sats \ 29 comments \ @spiderman 15h bitcoin

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?

view all related items

205 sats \ 3 replies \ @0xbitcoiner 9h

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

33 sats \ 2 replies \ @ek 7h

If you are a user, make sure you are double checking any transactions you are signing to make sure the addresses are correct.

imo, this is the answer if you don't have an external signer:

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.

25 sats \ 1 reply \ @0xbitcoiner 7h

Keep reading and you’ll see this part:

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.

21 sats \ 0 replies \ @ek 7h

sorry, I edited my comment when I did read that part haha

32 sats \ 16 replies \ @SimpleStacker 15h

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

16 sats \ 15 replies \ @spiderman OP 14h

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.

11 sats \ 3 replies \ @SimpleStacker 13h

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.

40 sats \ 2 replies \ @spiderman OP 13h

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.

13 sats \ 0 replies \ @SimpleStacker 13h

I don't think I can help you further then. You'd have to look into technical details beyond my know-how.

0 sats \ 0 replies \ @adlai 7h

according to the article I linked, the take was a fruit basket¹, fresh worth a few hundred bucks², and who knows what you could make from it if you like cognac³ and painting⁴.

random bunch of sweet cheap stuff ↩
minus fees duh ↩
why buy low if you can phish, ferment, and sell high? ↩
tape, on markets, of small coins deposited after creeping through various swaps to avoid KYCLOB blacklists ↩

11 sats \ 9 replies \ @ek 11h

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.

0 sats \ 8 replies \ @adlai 7h

deleted by author

6 sats \ 1 reply \ @ek 7h

your logic is about a hypothetical attacker who is currently authoring malware

my logic was about backing up my assumption that it swaps before signing because I did not read the malware code

0 sats \ 0 replies \ @adlai 6h

half the bloody problem is that there is too much code. I think it's been this way for longer than NASDAQ, although I'm younger.

0 sats \ 5 replies \ @ek 7h

wdym with "payload might not include exfil"?

if an attacker can sign whatever they want, why wouldn't they drain the wallet?

0 sats \ 4 replies \ @adlai 7h

I have not read any of the theft complaints. I have no idea how anything signed leaves the browser.

5 sats \ 3 replies \ @ek 7h

the malware swaps the address. so when you sign without double-checking the address, you're actually signing a tx to the attacker. you're then broadcasting that tx like you would normally. that's how anything signed leaves the browser or wallet.

0 sats \ 2 replies \ @adlai 7h

deleted by author

view all 2 replies

16 sats \ 0 replies \ @adlai 14h

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.

5 sats \ 0 replies \ @OT 5h

I haven't seen anyone say they lost sats from this attack so far.

0 sats \ 0 replies \ @adlai 6h

Different misinterpretation of your question, reached by deliberately ignoring your list of specific wallets and only responding to the question itself, along with the information that the payload in question lives within client-side javascript:

How to Verify the Impact of the Recent NPM Attack on My Wallets?

Read up on packet sniffing and detect whether your sending flow includes any updates of the vendor's code, as opposed to loading the interface provided when you obtained the wallet; if it does, then load Developer Tools from the relevant browser tab¹, go through the sources, and look for any addresses hardcoded in the client-side javascript. There is only reason for honest wallet code to hardcode any addresses is donations to the developer, and you'll probably be able to recognize these based on things like variable names, or the stage where they are used; and it is quite unlikely that obfuscated payload goes to the trouble of building an attacker's address from found materials. It's possible, however writing the code for this takes even more time, and people who sell malware usually need to sell malware rather than sit around for decades while five bucks of CoiledCoin gets worth anything ever again.

Navigate to the wallet, then use the browser's menu to find Developer Tools. Browsers based on Chrome and Firefox usually have shortcuts to the various tools, although these might vary. ↩

0 sats \ 1 reply \ @Solomonsatoshi 8h

Is Electrum wallet affected?

0 sats \ 0 replies \ @Solomonsatoshi 8h

It sounds like Electrum is unaffected by this hack.

https://www.archyde.com/more-than-20-wallets-of-cryptocurrencies-come-out-unharmed-after-attack-on-javascript-npm/

0 sats \ 0 replies \ @teremok 10h

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

0 sats \ 1 reply \ @d680ecaa8e 11h

Tezor are expensive and also for those having lot of funds not managing 10 $

0 sats \ 0 replies \ @spiderman OP 10h

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.

0 sats \ 0 replies \ @adlai 14h

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.

Remediation

Footnotes

Footnotes