This article is completed by Bocai Bocai (twitter@wzxznl), an independent researcher, and Sivan, a Beosin security researcher.

Hackers scare everyone in the Web3 ecosystem. For crypto projects, they are afraid of writing a wrong line of code when developing because of the open-source nature of Web3. Once a security incident occurs, the consequences will be difficult to bear.

Personally, every on-chain interaction or signature that you make has the potential to have your assets stolen if you don’t understand what you’re doing. Therefore, security issues have always been one of the most troublesome issues in Web3. Due to the characteristics of the blockchain, once assets are stolen, there is almost no way to recover them so it is especially important for users to have security knowledge.

Bocai Bocai discovered a new phishing method that has been active in the past two months. As long as you sign a message, your assets are stolen, which is extremely hidden and difficult to prevent. Addresses that have interacted with Uniswap may be exposed to risk. In this article, Bocai and Beosin will analyze this signature phishing and try to help everyone avoid asset losses.

The following is a retelling of Bocai's personal experience:

Recently, a friend asked Bocai for help after his assets were stolen. Unlike the usual way of asset theft, the victim did not disclose his private key and did not interact with the contract of the phishing website, so Bocai started to investigate the incident.

In the blockchain explorer, we can see that the stolen USDT from the victim is transferred through the TransferFrom function. When we transfer tokens on Ethereum, we actually call the Transfer function of a token's smart contract. The difference between the two functions is simply that Transfer function is called by the asset owner to transfer the token to another address, while TransferFrom function is a third party's transfer of the token in an address to other addresses. This also means that the stolen asset was transferred by another address.

By looking into the transaction details, we can find some key clues:

● The address ending in fd51 transfers the victim's assets to the address ending in a0c8.

● This operation interacted with Uniswap's Permit2 contract.

So here comes a doubt, how did the address ending in fd51 get permission for this asset? Why is it related to Uniswap?

First of all, we need to know that the prerequisite for successfully calling the TransferFrom function is that the caller needs to have approval of a token. When we use some Dapps, we need to perform an authorization (approve) operation first, so that Dapps' contract has the right to transfer our assets.

Before the address ending in fb51 called TransferFrom to transfer A’s assets, you can see that this address has also called a Permit operation, and the interaction object of these two operations is Uniswap's Permit2 contract. What are this Permit function and Uniswap Permit2?

The Uniswap Permit2 contract is a new smart contract launched by Uniswap at the end of 2022. According to the official statement, it is a token approval contract that allows token authorization to be shared and managed in different applications, creating a more unified, more cost-effective, and more secure user experience.

In the future, as more and more projects integrate with Permit2, Permit2 can achieve standardized token approval in all applications. Permit2 will improve user experience by reducing transaction costs while increasing the security of smart contracts.

Let's first explain why Uniswap launched Permit2. Let's assume a scenario. When we want to perform a Swap operation on a Dex, the traditional interaction method is that we need to authorize (approve) the Dex before performing Swap. We usually need to pay some gas fees twice, which is a great friction cost for us. I believe everyone has such an experience.

The launch of Permit2 may change the rules of the entire Dapp ecosystem. Simply put, the traditional method is that you need to authorize every time you interact with a Dapp for asset transfer, and Permit2 can save this step. This can effectively reduce user interaction costs and bring a better user experience.

The solution is that Permit2 acts as an intermediary between the user and the Dapp. The user only needs to authorize the permission of a token to the Permit2 contract. All Dapps that integrate the Permit2 contract can share this approved amount. For users, it reduces interaction costs and improves user experience. For Dapp, the improvement of user experience brings more users and funds, which is a win-win situation. At the same time, it can also be a double-edged sword, and the problem lies in the way of interaction with Permit2.

In the traditional interaction mode, whether it is authorization or transfer of funds, it is an on-chain interaction for users. Permit2 turns the user's operation into an off-chain signature, and all operations on the chain are completed by intermediate roles (such as the Permit2 contract and the projects integrating Permit2, etc.). The role of interaction is transferred from users to intermediate roles. Even if the user does not have ETH in the wallet, the user can use other Tokens to pay the gas fee or be fully covered by the intermediate role, depending on the choice of the intermediate role.

Although the launch of Permit2 may change the rules of Dapps in the future, it can be a strong double-edged sword. For users, an off-chain signature is the easiest step to put down their defenses. For example, when we use wallets to log in some Dapps, a signature is required to connect, and most people do not carefully check the content of the signature and do not understand the content of the signature.

After understanding the Permit2 contract, we will understand why the stolen assets interact with the Permit2 contract when we go back to the above incident. Let Bocai reproduce the Permit2 phishing. First of all, a crucial prerequisite is that the phished wallet needs to have a token authorized to Uniswap’s Permit2 contract. Bocai found that as long as swap is performed on the Dapps integrated with Permit2 or Uniswap, it needs to be authorized to the Permit2 contract (Bocai uses a security plug-in in the picture below).

Another risky point is that no matter how much you want to swap, Uniswap's Permit2 contract will allow you to authorize the entire balance of a token by default. Although MetaMask will allow you to customize the input amount, I believe most people will click directly on the maximum or default value and the default value of Permit2 is unlimited.

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

The focus is the Permit function that interacted with the Permit2 contract in the address ending in fd51. This function simply uses your wallet to transfer the token amount that you authorized to the Permit2 contract to another address. That is to say, as long as hackers attain your signature, they can get permission for the token in your wallet and transfer your assets away.

Event Detailed Analysis

permit function:

You can think the Permit function as a way to sign a contract online. This function allows you to pre-sign a "contract" that allows someone else (spender) to spend some of your tokens in the future.

At the same time, you also need to provide a signature, just like signing a paper contract, to prove that this "contract" is really signed by you.

So how does this function work?

● First, it checks whether the current time exceeds the expiration date of your signature (sigDeadline). Just like the contract you signed has an expiration date, if the current time exceeds the expiration date, then this "contract" can no longer be used and the program will stop directly.

● Next, it checks if your signature is really yours. The program will use a special method (signature.verify) to check the signature to ensure that the signature is really signed by you and has not been forged by others.

● Finally, if the checks pass, the program updates the record to note that you have allowed others to use some of your tokens.

The focus is mainly on the verify function and the _updateApproval function.

verify function:

It can be seen that the verify function will obtain the three data v, r, and s from the signature parameter. v, r, and s are the values of the transaction signature. They can be used to restore the address of the transaction signature. You can see that after the contract restores the address of the transaction signature, it compares the restored address with the token owner's address. If they are the same, the verification is passed. The call of the _updateApproval function is continued. If they are different, the transaction is rolled back.

_updateApproval function:

When the signature verification is passed, the _updateApproval function will be called to update the authorization value, which means that your permissions have been transferred. At this time, it is convenient to call the TransferFrom function to transfer tokens to the specified address after being authorized, as shown in the code below.

After explaining the permit function, let's take a look at the real transactions on the chain. We can find out the details of this interaction:

Owner is the victim's wallet address (end number 308a).

In Details section, we can see the authorized token contract address (USDT) and amount and other information.

Spender is the hacker address ending in fd51.

sigDeadline is the effective time of the signature, and signature is the signature information of the victim

Looking back at the interaction records of the victim, we will find that when he used Uniswap before, he clicked on the default authorization amount, which is almost unlimited.

A simple recap shows that the victim authorized Uniswap Permit2 to use unlimited USDT when using Uniswap before. Then he accidentally fell into the Permit2 signature phishing trap designed by hackers when performing wallet operations, and the hackers got his signature and used the signature to perform two operations, Permit and TransferFrom, in the Permit2 contract to transfer the victim's assets away. What Bocai has observed is that Uniswap's Permit2 contract has become a phishing haven. Permit2 phishing appears to be active about two months ago.

Source: https://etherscan.io/address/0x000000000022d473030f116ddee9f6b43ac78ba3

In the interaction records, it can be found that almost most of them are marked phishing addresses (Fake_Phishing) and there are more and more victims.

Source: https://etherscan.io/address/0x000000000022d473030f116ddee9f6b43ac78ba3

How to prevent it?

Considering that the Uniswap Permit2 contract may become more popular in the future and more projects will integrate the Permit2 contract for authorization sharing, some effective prevention methods for Permit2 phishing are as follows:

1. Understand and identify signature content:

The signature format of Permit usually includes several keys such as Owner, Spender, value, nonce, and deadline. If you want to enjoy the convenience and low cost brought by Permit2, you must learn to recognize this signature format. (Downloading a security plugin is a good option)

We recommend Beosin Alert, an anti-phishing extension that can identify most phishing websites in Web3 and protect users' wallet and asset security.

Anti-phishing extension download link:

https://chrome.google.com/webstore/detail/beosin-alert/lgbhcpagiobjacpmcgckfgodjeogceji?hl=en

2. Wallets for assets storage and interaction can be separated:

If you have a large number of assets, it is recommended to put these assets in a cold wallet and put a small number of funds in a wallet for interactions, which can greatly reduce the loss in case of phishing scams.

3. Do not authorize a great amount to the Permit2 contract/cancel the authorization:

When you swap on Uniswap, you can only authorize the amount that you want to interact with so that although each interaction needs to be re-authorized with more interaction costs, it can avoid the signature phishing of Permit2. If you have already authorized a great amount, you can find the corresponding security plug-ins to cancel the authorization.

4. Check whether a token supports the permit function:

In the future, more and more ERC20 tokens may realize the permit function. Users need to pay attention to whether the token you hold supports this function. If it supports, then you must be careful and check whether each unknown signature is a signature of the permit function.

5 If there are assets stored on other platforms after being hacked, a comprehensive rescue plan is needed:

When you find that your assets have been transferred out by hackers and there are some tokens stored on other platforms by locking or staking, you need to withdraw and transfer them to a safe address. At this time, hackers may monitor your wallet all the time. Since they have your signature, as long as the tokens are in your stolen wallet, hackers can transfer the funds away directly. It is necessary to seek professional security company for help. The two processes of tokens withdrawal and tokens transfer need to be executed in one block. MEV transfers can be used, which requires some blockchain knowledge and coding skills. Victims can ask a professional security company such as the Beosin team to use frontrun script to save your assets.

Case reading: https://medium.com/@Beosin_com/a-crypto-influencer-is-under-a-sweeper-bot-attack-how-can-beosin-help-recover-his-funds-1db672c51ace

It is believed that there will be more and more phishing based on Permit2 in the future. This phishing method is extremely hidden and difficult to prevent. With the wider application of Permit2, more and more addresses will be exposed to risks. It will be helpful to share this article to others to prevent more people from being stolen.

Contact

If you need any blockchain security services, welcome to contact us:

Official Website Beosin EagleEye Twitter Telegram LinkedIn