Data from Etherscan shows that some crypto scammers are targeting users with a new trick that allows them to confirm a transaction from the victim’s wallet, but without having the victim’s private key. The attack can only be performed for transactions of 0 value. However, it may cause some users to accidentally send tokens to the attacker as a result of cutting and pasting from a hijacked transaction history.
Blockchain security firm SlowMist discovered the new technique in December and revealed it in a blog post. Since then, both SafePal and Etherscan have adopted mitigation techniques to limit its effect on users, but some users may still be unaware of its existence.
Recently we have received reports from the community of a new type of scam: Zero Transfer Scam. Be careful if you see suspicious 0 transfer in your wallet record:
— Veronica (@V_SafePal) December 14, 2022
According to the post from SlowMist, the scam works by sending a transaction of zero tokens from the victim’s wallet to an address that looks similar to one that the victim had previously sent tokens to.
For example, if the victim sent 100 coins to an exchange deposit address, the attacker may send zero coins from the victim’s wallet to an address that looks similar but that is, in fact, under the control of the attacker. The victim may see this transaction in their transaction history and conclude that the address shown is the correct deposit address. As a result, they may send their coins directly to the attacker.
Sending a transaction without owner permission
Under normal circumstances, an attacker needs the victim’s private key to send a transaction from the victim’s wallet. But Etherscan’s “contract tab” feature reveals that there is a loophole in some token contracts that can allow an attacker to send a transaction from any wallet whatsoever.
For example, the code for USD Coin (USDC) on Etherscan shows that the “TransferFrom” function allows any person to move coins from another person’s wallet as long as the amount of coins they are sending is less than or equal to the amount allowed by the owner of the address.
This usually means that an attacker can’t make a transaction from another person’s address unless the owner approves an allowance for them.
However, there is a loophole in this restriction. The allowed amount is defined as a number (called the “uint256 type”), which means it is interpreted as zero unless it is specifically set to some other number. This can be seen in the “allowance” function.
As a result, as long as the value of the attacker’s transaction is less than or equal to zero, they can send a transaction from absolutely any wallet they want, without needing the private key or prior approval from the owner.
USDC isn’t the only token that allows this to be done. Similar code can be found in most token contracts. It can even be found in the example contracts linked from the Ethereum Foundation’s official website.
Examples of the zero value transfer scam
Etherscan shows that some wallet addresses are sending thousands of zero-value transactions per day from various victims’ wallets without their consent.
For example, an account labeled Fake_Phishing7974 used an unverified smart contract to perform more than 80 bundles of transactions on Jan. 12, with each bundle containing 50 zero-value transactions for a total of 4,000 unauthorized transactions in one day.
Looking at each transaction more closely reveals a motive for this spam: The attacker is sending zero-value transactions to addresses that look very similar to ones the victims previously sent funds to.
For example, Etherscan shows that one of the user addresses targeted by the attacker is the following:
On Jan. 29, this account authorized 5,000 Tether (USDT) to be sent to this receiving address:
Immediately afterwards, Fake_Phishing7974 sent a zero-value transaction from the victim’s wallet to this address:
The first five characters and the last six characters of these two receiving addresses are exactly the same, but the characters in the middle are all completely different. The attacker may have intended for the user to send USDT to this second (fake) address instead of the real one, giving their coins to the attacker.
In this particular case, it appears that the scam did not work, as Etherscan does not show any transactions from this address to one of the fake addresses created by the scammer. But given the volume of zero-value transactions done by this account, the plan may have worked in other cases.
Wallets and block explorers may vary significantly as to how or whether they show misleading transactions.
Some wallets may not show the spam transactions at all. For example, MetaMask shows no transaction history if it is reinstalled, even if the account itself has hundreds of transactions on the blockchain. This implies that it stores its own transaction history rather than pulling the data from the blockchain. This should prevent the spam transactions from showing up in the wallet’s transaction history.
On the other hand, if the wallet pulls data directly from the blockchain, the spam transactions may show up in the wallet’s display. In a Dec. 13 announcement on Twitter, SafePal CEO Veronica Wong warned SafePal users that its wallet may display the transactions. In order to mitigate against this risk, she said that SafePal was altering the way addresses are displayed in newer versions of its wallet so as to make it easier for users to inspect addresses.
(6/10) Upon this, we have taken actions:1) In the latest V3.7.3 update, we adjusted the length of the wallet address displayed in the transaction history. The first and last 10 digits of the wallet address will be displayed in default, for the sake of address examination
— Veronica (@V_SafePal) December 14, 2022
In December, one user also reported that their Trezor wallet was displaying misleading transactions.
Cointelegraph reached out through email to Trezor developer SatoshiLabs for comment. In response, a representative stated that the wallet does pull its transaction history directly from the blockchain “every time users plug in their Trezor wallet.”
However, the team is taking steps to protect users from the scam. In an upcoming Trezor Suite update, the software will “flag the suspicious zero-value transactions so that users are alerted that such transactions are potentially fraudulent.” The company also stated that the wallet always displays the full address of every transaction and that they “strongly recommend that users always check the full address, not just the first and last characters.”
Aside from wallets, block explorers are another type of software that can be used to view transaction history. Some explorers may display these transactions in such a way as to inadvertently mislead users, just as some wallets do.
To mitigate against this threat, Etherscan has begun graying out zero-value token transactions that aren’t initiated by the user. It also flags these transactions with an alert that says, “This is a zero-value token transfer initiated by another address,” as evidenced by the image below.
Other block explorers may have taken the same steps as Etherscan to warn users about these transactions, but some may not have implemented these steps yet.
Tips for avoiding the ‘zero-value TransferFrom’ trick
Cointelegraph reached out to SlowMist for advice on how to avoid falling prey to the “zero-value TransferFrom” trick.
A representative from the company gave Cointelegraph a list of tips for avoiding becoming a victim of the attack:
“Exercise caution and verify the address before executing any transactions.””Utilize the whitelist feature in your wallet to prevent sending funds to the wrong addresses.””Stay vigilant and informed. If you encounter any suspicious transfers, take the time to investigate the matter calmly to avoid falling victim to scammers.””Maintain a healthy level of skepticism, always stay cautious and vigilant.”
Judging from this advice, the most important thing for crypto users to remember is to always check the address before sending crypto to it. Even if the transaction record seems to imply that you’ve sent crypto to the address before, this appearance may be deceiving.
Be the first to comment