I remember a friend in the group shared a sentence before: If you don’t know who is providing the income, then you are the one providing the income. I think this sentence makes sense. The same is true for the security of using encrypted wallets. If you are not sure what the operation you are doing means, then every on-chain interaction or signature you make may lose the assets in your wallet.
Some time ago, Scam Sniffer released a 2024 mid-year phishing report: In the first half of this year, 260,000 victims were phished on the EVM chain (i.e., the Ethereum chain), with a cumulative loss of $314 million. Compared with the $295 million stolen by phishing attacks last year (2023), it took only 6 months this year to reach this number. As shown in the figure below.
According to the report, most ERC20 token thefts currently come from signing phishing signatures, such as Permit (offline authorization signature method), Increase Allowance (increase authorization amount method) and Uniswap Permit2. Phishing attacks are undoubtedly still the hardest hit area of on-chain security issues.
A few days ago, a friend reported a problem. Two months ago (June 14), this friend transferred 3 transfers from Coinbase Wallet to Binance (transfers based on the Ethereum chain). The first transfer was successful, but the subsequent two transfers have not been received. Two months have passed. I don’t know what went wrong?
So, I checked the token transaction records on the chain through Etherscan, but I only saw one corresponding transfer (Transfer), and did not see the records of the other two. As shown in the figure below.
I further looked at all the on-chain transaction records on June 14 and found that there were indeed 3 transfer records, but the last two records showed that the transactions failed. As shown in the figure below.
Then, I clicked on one of the failed (Failure) transaction records and saw the error message "An error occurred during contract execution". In theory, this type of error will not cause the loss of assets in the wallet, because according to the official Etherscan documentation, the assets (tokens) sent by the sender under this type of error will not leave the sender's wallet address, and only the Gas fee will be deducted. As shown in the figure below.
Therefore, to solve such a problem, we need to confirm:
- Determine whether the funds in the wallet were actually transferred out or lost on the same day (i.e. not returned to the wallet after a failed transaction)
- If it is confirmed that the assets have been transferred out or lost, you may need to contact the customer service staff of the corresponding website for support (in this case, you mainly need to contact the sender or the withdrawal platform, that is, the source of the transfer, for further confirmation. The platform of the recipient or the address cannot handle it)
Based on this problem, my general suggestion is: in the daily transaction process, it is best to make a transaction record sheet, such as using Excel and other tools to keep daily transaction (buy/sell) records, money expenditure (in/out) records, etc. Then if you encounter some problems, this sheet can also be used for comparison and inspection with the transaction records on the chain. In fact, I also have such a sheet. Every time I make a transaction, I will make a detailed record (some records will also be followed by some transaction experience or something).
At this point, the above problem seems to be basically solved. But in the process of querying the transaction records on the chain, I found that this partner’s wallet has a more serious problem: it has been targeted by hackers!
What's going on? Let's look at it further (as shown in the following figure):
First look at the red box in the picture above (real transaction):
The wallet holder has just performed a swap operation of $10,000 and transferred the exchanged USDT to the wallet starting with 0x8F (ending with f103).
Look at the green box in the picture above (phishing transaction)
Then, the hacker created several fake transactions. It should be noted that the address wallet created by the hacker also starts with 0x8F (ends with f103).
Let’s further compare these wallet addresses:
Below are the real addresses of wallet holders:
0x8F773C2E1bF81cbA8ee71CBb8d33249Be6e5f103
Below is the hacker’s wallet address:
0x8F7cCF79d497feDa14eD09F55d2c511001E5f103
0x8F776d5623F778Ea061efcA240912f9643fdf103
You should be able to see the problem now. The first 4 digits and the last 4 digits of these wallets are the same. If you don’t look carefully, you may not notice it. If you copy the wallet address directly through the transaction record to transfer money, it basically means that the money will be transferred directly to the hacker.
Therefore, it is certain that the wallet of this partner was indeed targeted by hackers, who hoped to defraud the partner's assets by phishing. Moreover, through the data on the transaction hash page, we can also find that the corresponding Transaction Action is also marked as Fake_Phishing, which is 100% a hacker address. As shown in the figure below.
Additional knowledge: Why can't I see invalid transactions or zero transfer records when using Etherscan? How to set the Ethereum browser to Simplified Chinese interface?
This is because the official Ethereum browser hides invalid transactions and zero transfer records by default. If you need to view such data, you can turn on the advanced features in the settings page of Etherscan. Similarly, if you like to use the simplified Chinese interface, you can also choose it in the settings page. As shown in the figure below. Alternatively, you can also consider using a third-party multi-chain browser such as Oklink (which also supports simplified Chinese display).
The issue of wallet security is indeed something that needs special attention, especially for wallets with large amounts of assets (more than $1 million). It is recommended to allocate assets to different wallets according to usage to improve security. For example, my own wallet is divided into the following levels:
Level 1 is a cold wallet made with an Apple phone, which is used to store coins. It is disconnected from the Internet and will not perform any transactions or transfers. I will not consider moving this part of assets for at least 10 years. Of course, if you want to trade through a cold wallet, you can consider purchasing well-known hardware wallets (such as Trezor, Ledger, etc.) through formal channels.
The second level is a hot wallet for larger amounts of funds. I use Trust Wallet and do not authorize any dApps. I only transfer funds with other wallets of my own, including withdrawals or transfers with Binance.
The third level is dozens of small wallets, some are for testing (such as participating in the interaction of various new projects to experience the product or take advantage of the airdrop), some are used to buy fake or on-chain meme coins (but I rarely do this kind of transaction in recent years), and each wallet is a small amount of funds, ranging from a few hundred to a few thousand US dollars. I am more casual about the daily authorization/signature of this kind of wallet, even if it is stolen, it doesn’t matter. Although these wallets seem to be a bit troublesome to use and manage, it is mainly for safety~
In short, different people may have different preferences in the use of wallets, which depends on their personal circumstances. Old investors may prefer to store their assets on the chain, but for most newcomers to this field, it is actually safer to directly use large exchanges such as Binance and OKX to store assets (no more than 100,000 US dollars).
Next, we will continue to sort out several common fishing methods:
1. Permit Phishing Attack
First of all, we need to do some basic knowledge: when we transfer tokens on Ethereum, we usually call the Transfer function or Transfer From function of the token smart contract to execute. Among them, Transfer means that the asset owner himself authorizes the operation and transfers the token to another address, while Transfer From means that a third party directly transfers the token in the address to another address.
The attack process of Permit phishing attack is as follows:
First, the attacker forges phishing links or phishing websites to trick users into signing through their wallets (without going on the chain).
Next, the attacker calls the Permit function to complete the authorization.
Then, the attacker transfers the victim's assets by calling the Transfer From function, completing the phishing attack.
This phishing method has a characteristic, that is, after the attacker obtains the signature authorization, he executes the Permit and Transfer From operations. By default, the authorization record cannot be seen in the on-chain transaction record of the victim's address, but it can be seen in the attacker's address.
Generally speaking, this type of signature authorization attack is a one-time attack and will not cause repeated or continuous phishing risks. In plain language, signature phishing cannot steal your wallet's seed phrase(or private key). A signature phishing attack can only be used once and only for the corresponding currency of the chain corresponding to the account (for example, if you authorize USDT, then the hacker can only steal your USDT). In simple terms, if you are phished once, the signature can only be used once by the hacker, unless you continue to sign by mistake and be exploited by the hacker.
(The above picture comes from bocaibocai@wzxznl)
2. Uniswap Permit2 Phishing Attack
This phishing method is similar to the Permit mentioned above, both of which belong to off-chain signature phishing. The so-called Uniswap Permit2 is a smart contract launched by Uniswap in 2022. According to the official statement, this is a token approval contract that allows token authorization to be shared and managed in different applications, creating a more unified, cost-effective and secure user experience. Currently, many projects have integrated with Permit2.
I also read a few articles written by bocaibocai (X@wzxznl) recently, and learned more about the phishing attack method of Uniswap Permit2. Here I will give you a brief summary:
When we want to perform a Swap operation on a DEX, the traditional way of interaction is that we need to first Approve to authorize the DEX, and then perform the Swap transaction. This usually costs us two Gas fees, which is too high a friction cost for users. Permit2 can save this step, which can effectively reduce the user's interaction cost and bring a better user experience.
In other words, Permit2 acts as a middleman between users and dApps. Users only need to authorize the Token permissions to the Permit2 contract, and all DApps that integrate the Permit2 contract can share this authorization amount. For users, it reduces interaction costs and improves user experience. For dApps, the improved user experience brings more users and funds.
This is a win-win situation, but it can also be a double-edged sword. In the traditional interaction mode, whether it is authorization or fund transfer, it is an on-chain interaction for the operating user. Permit2 changes the user's operation into an off-chain signature, and all on-chain operations are completed by intermediary roles (such as Permit2 contracts and project parties that have integrated Permit2, etc.). The benefit of this solution is that the role of on-chain interaction is transferred from the user to the intermediary role, but for users, off-chain signatures are the easiest link to let down their guard. For example, when we use a wallet to log in to certain dApps, we need to sign to connect, and most people do not carefully check the content of the signature and do not understand the content of the signature (for ordinary users, the signature interface looks like a bunch of code), and this is the most terrible part.
Another scary thing is that no matter how much you want to swap, Uniswap's Permit2 contract will default to authorizing the entire balance of the token. Although wallets such as MetaMask allow you to enter a custom amount, most people will probably just click the maximum or default value, and the default value of Permit2 is an unlimited amount. As shown in the figure below.
This means that as long as you have interacted with Uniswap and authorized the Permit2 contract, you will be exposed to the risk of this phishing scam.
For example, when Xiao Li used Uniswap before, he authorized Uniswap Permit2 for unlimited USDT quota. However, when Xiao Li was performing daily wallet operations, he accidentally fell into the Permit2 signature phishing trap designed by hackers. After obtaining Xiao Li's signature, the hacker could use Xiao Li's signature to perform Permit and Transfer From operations in the Permit2 contract to transfer Xiao Li's assets.
The specific steps of this phishing attack are roughly as follows:
First, the user’s wallet had used Uniswap before being phished and authorized the token quota to the Uniswap Permit2 contract (as mentioned above, the default value of Permit2 is unlimited quota authorization).
Secondly, the attacker forges a phishing link or phishing website page to trick the user into signing their wallet through the phishing link or website, and then the attacker can obtain the required signature information (this step is similar to Permit phishing).
Then, the attacker calls the Permit function of the Permit2 contract to complete the authorization.
Finally, the attacker calls the Transfer From function of the Permit2 contract to transfer the victim’s assets and complete the phishing attack.
Generally speaking, there are many addresses that receive assets in this attack method, some of which are specially used for phishing (even forged addresses ending with the same address as the victim's wallet address), and some are black market addresses that specialize in providing phishing services (such as some DaaS supplier addresses, and phishing for crypto wallets seems to have formed a complete black industry chain). As shown in the figure below.
So, how to prevent problems like Permit and Permit2?
First, you can consider using a browser security plug-in such as Scamsniffer (I have been using this plug-in in my own Google Chrome) to prevent phishing links. Secondly, you can consider using a tool such as Revoke Cash to regularly check and cancel those unfamiliar or unnecessary authorizations or signatures. As shown in the figure below.
Alternatively, you can also consider using the authorization management tool launched by Scamsniffer specifically for Uniswap Permit2 to conduct regular checks. If there is any abnormal authorization, it is recommended to cancel the authorization in time. As shown in the figure below.
Of course, the most important thing is your own security awareness. Do not visit links or websites of unknown origin casually, and perform necessary checks when performing dApp interaction authorization.
(The above picture comes from bocaibocai@wzxznl)
Additional knowledge: How to identify whether the wallet signature belongs to Permit or Permit2?
When performing various signatures in daily life, we will see some codes appearing on the authorization confirmation interface. We need to use these codes to identify them, as shown in the figure below.
The above figure shows Owner (authorizing party address), Spender (authorized party address), Value (authorized quantity), Nonce (random number), and Deadline (expiration time).
3. Claim Phishing Attack
This type of phishing is also very common. For example, if we often browse the X platform, we will find a lot of information about so-called free airdrops. Sometimes we will even receive some small pictures of airdropped NFTs in our wallets (there may be a domain name address on the picture).
If you click on the designated phishing website and make a claim, the assets in your wallet may be directly transferred away by the hacker.
So, how to prevent this problem?
First of all, don’t believe in the kind of pie-in-the-sky stuff (i.e. don’t click on links to free NFTs, airdrops, etc. from unknown sources), and secondly, when making any claim operations, be sure to verify whether the address you are visiting is the real official website address, and don’t take it lightly.
4. Phishing by transferring funds to similar addresses
Such a case occurred on May 3 this year, when a whale encountered a phishing attack with the same address with the same first and last numbers, and 1,155 WBTC (worth about US$70 million at the time) were phished away.
SlowMist has previously made a detailed analysis of this incident, so I will not go into details here. Friends who are interested can search and review it.
This fishing method actually looks relatively simple:
First, hackers will generate a large number of phishing addresses in advance. These addresses are somewhat confusing, such as addresses whose first 4 digits and last 6 digits are the same as the victim's target transfer address.
Secondly, after distributed deployment of batch programs, based on the user dynamics on the chain, a phishing attack with the same first and last digits is launched to the target transfer address.
Then, after the target user (victim) makes a transfer, the hacker immediately uses the phishing address generated by the collision to follow a transaction, so that the phishing address appears in the user's transaction record. As shown in the figure below.
Then, because the user was accustomed to copying the most recent transfer information from the wallet history, after seeing the trailing phishing transaction, he did not carefully check whether the address he copied was correct, and as a result, 1,155 WBTC were mistakenly transferred to the phishing address.
So, how to prevent this problem?
First, you can save the frequently used addresses in the wallet's address book (or add them to the whitelist), and you can find the target address from the wallet's address book next time you transfer money. Secondly, carefully check whether the address is correct. Don't just check the first or last few digits before transferring money. It is recommended to test a small transfer before making a large transfer.
5. Authorization Signature Phishing
In fact, the Permit, Uniswap Permit2, and Claim mentioned above also fall into the category of authorization phishing. When it comes to authorization, there are many other ways that can be exploited by hackers, such as the more common Approve (authorization, which is equivalent to telling the USDT contract that Uniswap can divert USDT in my wallet), Increase Allowance, and so on.
The attack method is basically: the attacker uses phishing links or phishing websites, or directly hacks into the project's official website to install a Trojan horse, and then induces users to click and authorize the wallet.
Of course, we have only listed 5 common phishing attack methods above, and hackers' attack methods are also varied and endless. As the saying goes, the devil is always stronger than the saint. There is nothing that hackers can't think of, only what you can't think of. The security of wallet use cannot be ignored.
This is where we share the content for this issue. You can view more articles on the homepage of Hualihuawai.
Disclaimer: The above content is only a personal point of view and analysis, and is only used for learning records and communication purposes, and does not constitute any investment advice. The encryption field is an extremely high-risk market, and many projects have the risk of returning to zero at any time. Please treat it rationally and be responsible for yourself.
