pull down to refresh

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
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
0 sats \ 0 replies \ @adlai 3h
according to the article I linked, the take was a fruit basket1, fresh worth a few hundred bucks2, and who knows what you could make from it if you like cognac3 and painting4.

Footnotes

  1. random bunch of sweet cheap stuff ↩
  2. minus fees duh ↩
  3. why buy low if you can phish, ferment, and sell high? ↩
  4. tape, on markets, of small coins deposited after creeping through various swaps to avoid KYCLOB blacklists ↩
reply
11 sats \ 9 replies \ @ek 8h
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
0 sats \ 8 replies \ @adlai 3h
deleted by author
reply
6 sats \ 1 reply \ @ek 3h
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
reply
0 sats \ 0 replies \ @adlai 3h
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.
reply
0 sats \ 5 replies \ @ek 3h
wdym with "payload might not include exfil"?
if an attacker can sign whatever they want, why wouldn't they drain the wallet?
reply
0 sats \ 4 replies \ @adlai 3h
I have not read any of the theft complaints. I have no idea how anything signed leaves the browser.
reply
5 sats \ 3 replies \ @ek 3h
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.
reply
0 sats \ 2 replies \ @adlai 3h
deleted by author
reply
0 sats \ 1 reply \ @ek 3h
yes, which is what I said because the malware has to swap the address before you sign
11 sats \ 0 replies \ @adlai 10h
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