| There are two attack vectors described in the article. 1) When you "connect a wallet" what you are actually doing is signing a message from the site using your private key. They can verify it using your public key to prove you control that wallet (ie it is just a normal message signing process). This process involves your wallet (often via a browser extension) popping up a message giving you details of what you are signing and buttons to approve or reject. Because lots of sites send a very unhelpful message that is just a big json token for people to sign, and because browser extensions are wonky leading to lots of requests to connect and reconnect and re-reconnect your wallet, people often get in the habit of not checking carefully what they are signing. The fundamental UX problem arises because the flow for authorizing a transaction is exactly the same - you sign a transaction approval using your wallet. Can you see the problem here? It's easy to accidentally approve a transaction which drains your assets when you think you're just approving a message to connect your wallet. 2) Secondly there is a classic phishing attack against the private key. If an attacker can pretend to be a legitimate site they can apparently sometimes persuade people to paste in their recovery phrase which is equivalent to their private key. If the attacker has the private key of course they don't need anyone else to approve the transactions which drain the wallet, they can do it themselves. There's another attack vector I have heard about which I don't think is in the article but is more pernicious. I'm not 100% sure of all the details but it's sort of a variant of #1 with extra tabasco. It starts by sending someone a token with malicious code in some of its methods (say the 'transfer()' method which is used to send the token to another address). This code is set up to drain the wallet of the owner of the token. So say the recipient of the token attempts to transfer the token to another wallet (or 'burn' it, which is just a transfer to a specific black hole address), they will be presented by their wallet with a normal-looking transfer approval method to authorize but unbeknownst to them (because they are approving untrusted code) they are actually authorizing the attacker to drain their wallet. The attacker can make it more likely a person will attempt to burn a token by either promising that burning will turn the token into something else (this is common in this world as a method of transforming things) or by making the content of the token really unpleasant so people want it out of their wallet (I think someone tried this with me - that is I got sent an unsolicited token with a pretty horrible animation that any sane person would want out of their wallet and it can't be burned because it is unverified code so there's no way of knowing whether the transfer method is trustworthy). The same attack can be run using different methods and it will operate should the recipient try to list their new token on an exchange. The remedy for this is that legitimate issuers can "verify" their code by publishing it and since the resulting bytecode checksum is the same as the checksum of the token people can be confident that they are seeing the real code. You would still need to actually check whether the code was doing anything bad to know whether it was safe to interact with such a token. |