Is your wallet still safe? How hackers use Permit, Uniswap Permit2, and authorization signatures for phishing

I remember a partner in the group shared a saying: "If you are unclear about who is providing the profits, then you are the one providing the profits." I feel this statement makes a lot of sense. The same applies to the security of using a crypto wallet; if you are unsure what the actions you are taking mean, then every on-chain interaction or signature you perform could potentially lead to the loss of assets in your wallet.

Recently, Scam Sniffer released a phishing report for mid-2024: In the first half of this year, there were 260,000 victims of phishing attacks on EVM chains (i.e., Ethereum-based chains), resulting in a total loss of $314 million. Compared to the $295 million stolen in phishing attacks last year (2023), this year's figure was reached in just six months. As shown in the figure below.

According to the report, most thefts of ERC20 tokens currently stem from signing phishing signatures, such as Permit (offline authorization signature method), Increase Allowance (increase authorization limit method), and Uniswap Permit2. Phishing attacks undoubtedly remain a major issue in on-chain security.

A few days ago, a partner reported an issue: this partner transferred money from Coinbase Wallet to Binance in three transactions (based on Ethereum chain transfers) two months ago (on June 14). The first transfer was successful, but the subsequent two transfers have not been received, and two months have passed without knowing what went wrong.

So, I checked the token transaction records on Etherscan, but I only saw one corresponding transfer (Transfer) and did not see records for the other two transactions. As shown in the figure below.

I further looked at all the on-chain transaction records for June 14 and found that there were indeed three transfer records; however, the latter two showed that the transactions had failed. As shown in the figure below.

Next, I opened one of the failed (Fail status) transaction records and saw that the error message displayed was "Error encountered during contract execution." Theoretically, such errors should not lead to the loss of assets in the wallet, as per the official documentation from Etherscan, the assets (tokens) sent by the sender do not leave the sender's wallet address; only the gas fee is deducted. As shown in the figure below.

Therefore, to resolve such issues, it is necessary to confirm:

• Whether the funds in the wallet were actually transferred out or lost that day (i.e., whether they were not returned to the wallet after the transaction failed).

• If it is confirmed that the assets have been transferred out or lost, then it may be necessary to contact the customer service of the corresponding website for support (this situation mainly involves contacting the sender or withdrawal platform, which is the source of the transfer, as the receiving platform or address cannot handle it).

Based on this issue, my general advice is: during daily transactions, it is best to maintain a transaction record sheet, such as using Excel or other tools to keep daily transaction (buy/sell) records, and money expenditure (income/outgoing) records. Then, if any issues arise, this sheet can be compared with the on-chain transaction records for verification. In fact, I also have such a spreadsheet; I record every transaction in detail (some records also include notes on trading insights).

At this point, the above issue seems to be mostly clarified. However, during the process of querying the transaction records on-chain, I discovered that this partner's wallet had a more serious problem: it had been targeted by hackers!

What happened? Let's continue to look (as shown in the figure below):

First, look at the red box in the figure above (real transaction):

The wallet holder just performed a $10,000 swap operation and transferred the exchanged USDT to a wallet starting with 0x8F (ending with f103).

Next, look at the green box in the figure above (phishing transaction):

Immediately after, the hacker created several fake transactions, and note that the wallet address created by the hacker also starts with 0x8F (ending with f103).

Let's further compare these wallet addresses:

Here is the real address of the wallet holder:

0x8F773C2E1bF81cbA8ee71CBb8d33249Be6e5f103

Here are the hacker's wallet addresses:

0x8F7cCF79d497feDa14eD09F55d2c511001E5f103

0x8F776d5623F778Ea061efcA240912f9643fdf103

At this point, everyone should see the problem. The first four and last four digits of these wallet addresses are the same. If you don't look closely, you might not notice. If you directly copy the wallet address from the transaction record for transfer, it essentially means the money will be transferred directly to the hacker.

Therefore, it is certain that this partner's wallet has indeed been targeted by hackers, who hope to deceive this partner's assets through phishing. Moreover, from the transaction hash page data, we can also find that the corresponding Transaction Action is marked as Fake_Phishing, which is 100% a hacker address. As shown in the figure below.

Supplementary Knowledge: Why can't you 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 defaults to hiding invalid transactions and zero transfer records. If you need to view such data, you can enable advanced features in the settings page of Etherscan. Similarly, if you prefer to use the Simplified Chinese interface, you can also select it in the settings page. As shown in the figure below. Alternatively, you can consider using third-party multi-chain browsers like Oklink (which also supports Simplified Chinese display).

The issue of wallet security is indeed something that needs special attention, especially for wallets with large assets (over $1 million). It is advisable to allocate assets to different wallets based on usage to enhance security. For example, my own wallets are divided into the following levels:

Level one is a cold wallet made with an Apple phone, used for holding coins, in a disconnected state and will not perform any transaction/transfer operations. I will not consider touching this part of the assets for at least 10 years. Of course, if you wish to trade with a cold wallet, you can consider purchasing well-known hardware wallets (like Trezor, Ledger, etc.) through legitimate channels.

Level two is a hot wallet with relatively large funds; I use Trust Wallet and will not authorize any dApp, only transferring funds between my own wallets, including withdrawals or transfers with Binance.

Level three consists of dozens of small wallets, some for testing (such as interacting with various new projects to experience products or casually grabbing airdrops), and some were previously used for buying altcoins or meme coins (though I have rarely engaged in such transactions in recent years), with each wallet containing small amounts of funds, ranging from hundreds to thousands of dollars. I am relatively casual with daily authorizations/signatures for these wallets, and even if they are stolen, it doesn't matter. Although managing these wallets may seem a bit troublesome, it is mainly for security purposes.

In summary, different people may have different preferences for wallet usage, depending on their personal situation. Experienced users may prefer to store assets on-chain, but for most newcomers entering this field, directly using large exchanges like Binance or OKX to store assets (not exceeding $100,000) may actually be safer.

Next, let's continue to outline several currently common phishing methods:

1. Permit Phishing Attack

First, we need to provide some basic knowledge: When we perform token transfers on Ethereum, we usually call the Transfer function or Transfer From function of the token smart contract. Among them, Transfer refers to the asset owner authorizing the operation and transferring the token to another address, while Transfer From refers to a third party directly transferring tokens from one address to another.

The attack process of Permit phishing attacks is as follows:

First, the attacker creates a phishing link or phishing website to lure users into signing through their wallets (off-chain).

Second, the attacker calls the Permit function to complete the authorization.

Then, the attacker calls the Transfer From function to transfer the victim's assets out, completing the phishing attack.

This phishing method has a characteristic: after the attacker obtains the signature authorization, they execute the Permit and Transfer From operations, while the authorization records of the victim's address are not visible in the on-chain transaction records, but can be seen in the attacker's address.

Generally speaking, this type of signature authorization attack is one-time and does not produce repeated or ongoing phishing risks. In simple terms: signature phishing cannot steal your wallet's mnemonic phrase (or private key); a single signature phishing can only be used once and only targets the corresponding token of that account on the corresponding chain (for example, if you authorized USDT, then the hacker can only steal your USDT). In short, being phished once means the hacker can only use it once, unless you continue to mistakenly sign and be exploited by the hacker. (The above image is from bocaibocai@wzxznl)

2. Uniswap Permit2 Phishing Attack

This phishing method is similar to the Permit mentioned above and also falls under 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 tokens to be authorized to share and manage across different applications, creating a more unified, cost-effective, and secure user experience. Currently, many projects have integrated with Permit2.

Recently, I also read several articles written by bocaibocai (X@wzxznl) to further understand the phishing attack method of Uniswap Permit2. Here, I will provide a brief summary:

When we want to perform a swap operation on a certain DEX, the traditional interaction method requires us to first approve the DEX for authorization and then perform the swap transaction, which usually requires us to pay two gas fees, resulting in high friction costs for users. Permit2 can eliminate this step, effectively reducing user interaction costs and providing a better user experience.

In other words, Permit2 acts as an intermediary between users and dApps; users only need to authorize the token permissions to the Permit2 contract, and all dApps integrated with the Permit2 contract can share this authorization limit. For users, this reduces interaction costs and improves user experience, while for dApps, the enhancement of user experience brings more users and funds.

This was originally a win-win situation, but it can also be a double-edged sword. In the traditional interaction method, whether authorizing or transferring funds, the operations are on-chain interactions for the user. Permit2, however, turns user operations into off-chain signatures, with all on-chain operations completed by intermediary roles (such as the Permit2 contract and projects integrated with Permit2). The benefit of this solution is that the role of on-chain interaction shifts from the user to the intermediary, but for users, off-chain signatures are the easiest part to let down their guard. For example, when we log into certain dApps with a wallet, we need to sign to connect, and the vast majority of 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 that is the most frightening part.

Another alarming point is that regardless of the amount you want to swap, Uniswap's Permit2 contract will default to allowing you to authorize the entire balance of that token. Although wallets like MetaMask allow you to customize the input amount, most people will likely click the maximum or default value, and the default value for Permit2 is unlimited. As shown in the figure below.

This means that as long as you have interacted with Uniswap and authorized the limit to the Permit2 contract, you are exposed to the risk of this phishing scam.

For example, Xiao Li previously authorized an unlimited USDT limit to Uniswap Permit2 during his use of Uniswap, and when Xiao Li was performing wallet operations, he accidentally fell into a phishing trap designed by hackers for Permit2 signatures. After obtaining Xiao Li's signature, the hacker could use it to perform Permit and Transfer From operations in the Permit2 contract to transfer Xiao Li's assets away.

The specific steps of this phishing attack are roughly as follows:

First, the user's wallet has previously used Uniswap and authorized token limits to the Uniswap Permit2 contract (as mentioned earlier, the default value of Permit2 is unlimited authorization).

Second, the attacker forges a phishing link or phishing website page to lure the user into signing through the phishing link or website, allowing the attacker to obtain the required signature information (this step is similar to the 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 out, completing the phishing attack.

In general, this type of attack often has multiple addresses receiving the assets, some specifically used for phishing, and some are addresses provided by black market services (such as some DaaS provider addresses; it seems that phishing targeting crypto wallets has already formed a complete black industry chain). As shown in the figure below.

So, how can we prevent issues like Permit and Permit2?

First, consider using browser security plugins like Scamsniffer (I have been using this plugin on my Google Chrome) to prevent phishing links. Secondly, you can consider using tools like Revoke Cash to regularly check and revoke any unfamiliar or unnecessary authorizations or signatures. As shown in the figure below.

Alternatively, you can consider using the authorization management tool specifically launched by Scamsniffer for Uniswap Permit2 to conduct regular checks. If there are any abnormal authorizations, it is recommended to revoke them promptly. As shown in the figure below.

Of course, the most important thing is to maintain your own security awareness, avoid casually visiting links or websites of unknown origin, and conduct necessary checks when authorizing dApp interactions. (The above image is from bocaibocai@wzxznl)

Supplementary Knowledge: How to identify whether a wallet signature belongs to Permit or Permit2?

When performing various signatures, we will see some codes appear on the authorization confirmation interface, and we need to identify them through these codes, as shown in the figure below.

In the figure above, Owner (authorizing address), Spender (authorized address), Value (authorized amount), Nonce (random number), Deadline (expiration time).

3. Claim Phishing Attack

This phishing method is also very common. For example, if we frequently browse platform X, we will find many so-called free airdrop claims, and sometimes we may even receive some airdropped NFT images in our wallets (which may have a domain address on them).

If you click into the specified phishing website and perform a claim operation, then the assets in your wallet may be directly transferred away by hackers.

So, how can we prevent this issue?

First, do not believe in things that seem too good to be true (i.e., do not click on links for free NFTs, airdrops, etc., from unknown sources). Secondly, when performing any claim operation, be sure to verify that the address you are visiting is indeed the official website address, and do not let your guard down.

4. Similar Address Transfer Phishing

On May 3 of this year, there was a case where a whale encountered a phishing attack with similar starting and ending address numbers, losing 1,155 WBTC (worth about $70 million at the time).

Slow Mist previously conducted a detailed analysis of this incident, so I won't elaborate further. Interested partners can search for and review it.

This phishing method appears to be relatively simple:

First, hackers will pre-generate a large number of phishing addresses, which are somewhat misleading, such as addresses where the first four digits and last six digits match the victim's target transfer address.

Second, after deploying a distributed batch program, they will initiate phishing attacks on target transfer addresses with matching starting and ending numbers based on on-chain user dynamics.

Then, when the target user (victim) performs a transfer, the hacker immediately follows up with a transaction using the generated phishing address, causing the phishing address to appear in the user's transaction records. As shown in the figure below.

Next, since users are accustomed to copying recent transfer information from their wallet history, they may not carefully check whether the address they copied is correct after seeing the trailing phishing transaction, resulting in mistakenly transferring 1,155 WBTC to the phishing address.

So, how can we prevent this issue?

First, you can save commonly used addresses in your wallet's address book (or add them to a whitelist), so you can find the target address from the wallet's address book for future transfers. Secondly, carefully verify whether the address is correct; do not simply check the first few or last few digits before transferring. It is advisable to conduct a small transfer test before making large transfers.

5. Authorization Signature Phishing

In fact, the Permit, Uniswap Permit2, and Claim mentioned above all fall under the category of authorization phishing. When it comes to authorization, there are many methods that hackers can exploit, such as the more common Approve (i.e., authorization, which is equivalent to telling the USDT contract that Uniswap can use my USDT in the wallet), Increase Allowance (increasing the authorization limit), etc.

The attack methods are generally: attackers use phishing links or phishing websites, or directly hack the project's official website to install malware, then lure users to click and authorize their wallets.

Of course, we have only listed five currently common phishing attack methods, and hackers' attack methods are diverse and ever-evolving. As the saying goes, "The higher the skill, the more cunning the devil," there is nothing that hackers cannot think of. The issue of wallet security cannot be ignored.

We will conclude this content here. More articles can be viewed through the homepage of "Talk Li Talk Outside."

Disclaimer: The above content is merely personal opinions and analyses, intended for learning records and communication purposes only, and does not constitute any investment advice. The crypto field is a high-risk market, and many projects carry the risk of going to zero at any time. Please view it rationally and take responsibility for yourself.