This article introduces a new phishing method that has been active in the past two months. As long as the signature is stolen, the method is extremely hidden and difficult to prevent, and addresses that have interacted with Uniswap may be exposed to risks. This article will popularize this signature phishing technique, and try to avoid more asset losses for everyone.
Written by: Spinach Spinach, Beosin Invited Independent Researcher; Sivan, Beosin Security Researcher
Hackers, this is an existence that scares everyone in the Web3 ecosystem. For the project side, when hackers all over the world may stare at you, the open source nature of the code makes the project side afraid of writing a wrong line of code when developing Leaving loopholes, once a security incident occurs, the consequences will be difficult to bear.
Personally, every on-chain interaction or signature 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 the encryption world, and due to the characteristics of the blockchain, once assets are stolen, there is almost no way to recover them, so it is especially important to have security knowledge in the encryption world.
Just recently, Beosin’s good friend Pincai discovered a new phishing method that has been active in the past two months . As long as the signature is stolen, the method is extremely hidden and difficult to prevent, and addresses that have interacted with Uniswap may be exposed to risk Next, in this article, Beosin and independent researcher Pincai will popularize this signature phishing technique, and try to avoid more asset losses for everyone.
The following is a retelling of Spinach's personal experience:
process
Recently, a friend (tentatively named Little A) found Spinach after the assets in his wallet were stolen. Unlike the usual way of theft, Little A did not disclose the private key and did not interact with the contract of the phishing website, so Spinach started The theft of assets was investigated.
In the blockchain browser, you can see that the USDT stolen from the small A wallet is transferred through the Transfer From function. Let’s popularize the science here. When we transfer Token on Ethereum, we actually call The Transfer function of the Token smart contract, the difference between the two is simply that Transfer is the asset owner's own operation to transfer the Token to another address, while Transfer From is the third party's transfer of the Token in the address to other addresses. This also means that the stolen asset was transferred from another address, rather than the private key of the wallet was leaked.
By querying the transaction details, we can find some key clues:
- The address ending in fd51 transfers Little A’s assets to the address ending in a0c8
- This operation interacts with Uniswap's Permit2 contract
So here comes the doubt, how did the address ending in fd51 get the permission of this asset? Why is it related to Uniswap?
First of all, we need to know that in order to successfully call the Transfer From function, the premise is that the caller needs to have the quota authority of this Token, that is, approve. I believe that everyone who has operated on the chain must be familiar with it. When we use some Dapp Sometimes, once the transfer of assets is involved, we need to perform an authorization (approve) operation first, so that the Dapp contract has the right to transfer our assets.
To solve this puzzle, we need to continue digging, and the answer is in the interaction record of the address ending in fd51. Before this address performs Transfer From to transfer A’s assets, you can see that this address has also performed a Permit operation, and the interaction object of these two operations is Uniswap's Permit2 contract, so what is the situation between 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, this is a token approval contract that allows token authorization to be shared and managed in different applications, creating a more unified and more Cost-effective, more secure user experience.
And 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 understand why Uniswap launched Permit2. Let's assume a scenario. When we want to perform Swap on a certain Dex, the traditional interaction method is that we need to authorize (approve) the Dex before performing Swap. It usually costs us two gas fees, which is too much friction cost for users. I believe everyone has had such an experience.
Image source: https://github.com/dragonfly-xyz/useful-solidity-patterns/tree/main/patterns/permit2
The launch of Permit2 may change the game 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 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 the Token to the Permit2 contract. All Dapp that integrate the Permit2 contract can share this authorization 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, but 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 interaction on the chain for the user of the operation. On the other hand, 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 project party integrating Permit2, etc.). The role of interaction is transferred from the user to the intermediate role. Even if the user does not have ETH in the wallet, the user can use other Tokens to pay the gas fee or be completely reimbursed by the intermediate role, depending on the choice of the intermediate role.
Image source: https://github.com/dragonfly-xyz/useful-solidity-patterns/tree/main/patterns/permit2
Although the emergence of Permit2 may change the game rules of Dapp in the future, it can be seen that this is a strong double-edged sword. For users, off-chain signature is the easiest link to put down their defenses. For example, when we use When the wallet logs in to some Dapp , 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, and this is the scariest part.
After understanding the Permit2 contract, we will understand why the asset theft interacts with the Permit2 contract when we go back to the small A incident, so let Spinach reproduce the Permit2 signature phishing method, first of all, a crucial prerequisite The phished wallet needs to have a Token authorized to Uniswap’s Permit2 contract. Spinach found that as long as Swap is performed on the Dapp or Uniswap integrated with Permit2, it needs to be authorized to the Permit2 contract (Spinach uses a security plug-in in the picture below).
Another scary point is that no matter how much you want to Swap, Uniswap's Permit2 contract will allow you to authorize the entire balance of the 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 quota....
This also means that as long as you have interacted with Uniswap and authorized the amount to the Permit2 contract after 2023, you will be exposed to the risk of this phishing scam.
Because the focus is on 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 you authorized to the Permit2 contract to another address. That is to say, as long as With your signature, the hacker can get the permission of the Token in your wallet and transfer your assets away.
Event Detailed Analysis
permit function:
You can think of the Permit function as a way to sign a contract online. This function allows you (PermitSingle) to pre-sign a "contract" that allows someone else (spender) to spend some of your tokens at some point in the future.
At the same time, you also need to provide a signature (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 that 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 of v, r, and s from the signature information parameter. v, r, and s are the values of the transaction signature, and they can be used to restore the address of the transaction signature. You can see in the code above After the contract restores the address of the transaction signature, compare it with the incoming token owner address. If they are the same, the verification is passed, and the call to 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.
Well, 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 A's wallet address (end number 308a)
- In Details, you 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 Little A
And looking back at the interaction records of Little A, we will find that when Little A used Uniswap before, he clicked on the default authorization amount, which is almost unlimited.
A simple recap shows that Little A authorized Uniswap Permit2 unlimited USDT quota in the process of using Uniswap before, and Little A accidentally fell into the Permit2 signature phishing trap designed by hackers when performing wallet operations, and the hackers got After Little A's signature, he used Little A's signature to perform two operations, Permit and Transfer From, in the Permit2 contract to transfer Little A's assets away. What Spinach has observed is that Uniswap's Permit2 contract has become a fishing paradise. Permit2 signature phishing appears to have only been active about two months ago.
Source: https://etherscan.io/address/0x000000000022d473030f116ddee9f6b43ac78ba3
And in the interaction records, it can be found that almost most of them are marked phishing addresses (Fake_Phishing), and people are constantly being fooled.
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, we can think of effective prevention methods as follows:
1 Understand and identify signature content:
The signature format of Permit usually includes several key formats 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 the security plugin is a good option)
We recommend the following Beosin Alert anti-phishing plug-in to readers and friends, which can identify most phishing websites in the Web3 field and protect everyone's wallet and asset security.
Anti-phishing plug-in download:
https://chrome.google.com/webstore/detail/beosin-alert/lgbhcpagiobjacpmcgckfgodjeogceji?hl=en
2 The asset wallet and the interactive wallet are used separately:
If you have a large amount of assets, it is recommended to put all assets in a cold wallet, and put a small amount of funds in the interactive wallet on the chain, which can greatly reduce the loss in case of phishing scams.
3 Do not authorize excessive amounts to the Permit2 contract or cancel the authorization:
When you perform Swap on Uniswap, you only authorize the amount you want to interact with, so that although each interaction needs to be re-authorized, there will be some interaction costs, but it can avoid the signature phishing of Permit2. If you have already authorized the quota, you can find the corresponding security plug-in to cancel the authorization.
4 Identify the nature of the token and whether it supports the permit function:
In the future, more and more ERC20 tokens may use this extension protocol to realize the permit function. For you, you need to pay attention to whether the token you hold supports this function. If it supports it, then you must Be extra careful, and strictly check whether each unknown signature is a signature of the permit function.
5 If there are tokens stored on other platforms after being cheated, a comprehensive rescue plan needs to be formulated:
When you find that you have been defrauded and your tokens have been transferred out by hackers, but you still have tokens stored on other platforms through methods such as pledge, etc., you need to withdraw them and transfer them to a safe address. At this time, you need to know that hackers may monitor you all the time The token balance of the address, because he has your signature, as long as the token appears on your stolen address, the hacker can transfer it directly. At this time, it is necessary to formulate a complete token rescue process. The two processes of extracting tokens and transferring tokens need to be executed together. Hacker transactions cannot be inserted into it . MEV transfers can be used, which requires some blockchain knowledge and code skills. You can find a professional security company such as the Beosin team to use the transaction preemption script to achieve it.
Case reading: Encryption big V encountered a "scavenger" attack, how did the Beosin security team help him recover funds?
It is believed that there will be more and more phishing based on Permit2 in the future. This signature phishing method is extremely hidden and difficult to prevent. With the wider application of Permit2, more and more addresses will be exposed to risks. I hope you in front of the screen can spread it to more people after reading this article, so as to prevent more people from being stolen.
Reference:
https://t.co/G9Mnq8eUle
https://github.com/dragonfly-xyz/useful-solidity-patterns/tree/main/patterns/permit2
