Permit signature analysis: Can off-chain signatures also catch your Token?

When interacting with DApps, users need to pay attention to controlling the number of authorized Tokens, checking signature content and abnormal authorization situations.

Written by: Lisa

background

On May 11, the Twitter user "pineapple.eth" tweeted that his wallet was stolen due to a mistaken click on a phishing website (syncswap[.]network), and he lost more than $100.

(

Although the amount of loss is not large, there is a huge security risk hidden in it. Victims often lose huge assets because of the "inconspicuous" signature risk of "not being able to see". That's why we wrote this article.

According to the victim's description, the stolen transactions are as follows:

(

(

From these two transactions, the contract caller (0x00002…d0000) transfers 34.87 USDC on the victim’s address (0xA4089…82C3) to (0x8256…D6B8) and transfers 81.36 USDC to (0x5A69… 1C17). If you just look at the transferFrom function, it is not difficult to find that the function of this function is to allow a third party to initiate a transaction to transfer the relevant digital assets from the owner's account to the recipient's account.

Then analyze the address of the contract caller (0x00002...d0000), and find that there is an extra permit operation, which is not in the victim's transaction records. What is the role of the permit?

(

What is a Permit?

According to the official introduction, permit was introduced into the ERC20 protocol in EIP-2612, and users can interact with the application contract by attaching an authorization signature (permit) without prior authorization. Specifically, we all know that in the transaction of ERC20 currency, A can call the approve function to authorize B, that is, to authorize the token specified by A to another account to operate, and must be the owner of this account to call approve function. The function of the permit function is that A signs the authorization object in advance under the chain, and informs B of the obtained signature, and B can use this signature to call permit to realize the authorization operation of A (use transferFrom to transfer the allowance) , A can transfer the specified token without sending the transaction, and whether he is the owner of the account or not, he can execute the permit to authorize the operation. In addition, Uniswap has released a new Token authorization standard Permit2.

The following is a comparison between approve and permit:

function approve(address usr, uint wad) external returns (bool)

{

allowance[msg.sender] [usr] = wad;

…

}

function permit(

address holder, address spender,

uint256 nonce, uint256 expiry, bool allowed,

uint8 v, bytes32 r, bytes32 s

) external {

…

allowance [holder] [spender] = wad;

…

}

After understanding the basics, and then returning to the phishing event itself, you can send this permit function with 7 parameters:

• owner: authorized address
• spender: Who is authorized to
• value: the number of authorized tokens given
• deadline: is a timestamp, valid only before the given time
• v, r, s: signature data

Among them, the deadline is 1714509304969, and the value is 116239404, which means that the authorization is valid until 0:42 on August 22, 56300 (GMT), almost indefinitely. And the number of authorized tokens is 116.239404 USDC, which is the same as the amount stolen by the victim. The values of v, r, and s are the signature data after the user (owner) signs on the phishing website, and the permit function will verify the validity of the signature data. After the signature verification is passed, the user's token will be authorized to the hacker (spender).

The whole process is very clear: the victim signed the signature and sent it to the phishing website but did not upload it to the chain. After getting the signature information, the hacker submitted the permit on the chain, that is, called approve for authorization. Signing is done off-chain without spending any gas. But it needs to be clear that no gas here does not mean that there is no gas consumption, but that the signer (victim) does not need to pay gas for authorization and transfer.

Undoubtedly, similar to approve authorized phishing, permit is more dangerous than approve authorized phishing, after all, as long as the signature is stolen, authorization is obtained. For example, the pending order function in dex only needs the user to sign a certain message, and the user can entrust the asset to the dex for processing without paying gas. The user's assets may be lost. As far as we know, some wallets will decode and display the signature information of approve authorization phishing, but the wallet has almost no warnings for permit signature phishing, and users are at a higher risk of being attacked. At the same time, the permit signature is an off-chain behavior, and it is difficult for users to notice whether their signatures have been leaked.

MistTrack

At present, the hacker address has been marked as a malicious phishing address by MistTrack.

Address 1: 0x00002644e79602F056B03235106A9963826d0000

Address 2: 0x82563Ba592986Cb277d67B2E7c56ab3BB3FDD6B8

Address 3: 0x5A697967F0791d12db8A0f92344Abc6DD07a1C17

Both USDC of the victim were exchanged for ETH.

Using MistTrack to analyze ETH, WBTC, USDT, USDC, SHIB, DAI, WETH, DAI, stETH, APE, the current profit of address 1 is about 120,000 US dollars, the profit of address 2 is about 200,000 US dollars, and the profit of address 3 About $2,000. In addition, according to the analysis of Scam Sniffer, a Web3 anti-fraud platform, as of May 9, a total of more than 300 victims have been stolen about US$690,000 in assets by malicious signatures based on Permit2. From the launch of Permit2 on Uniswap to May 9 So far, nearly 670,000 addresses on the Ethereum mainnet have authorized Permit2. Of course, this data is only the tip of the iceberg for the whole picture of this gang.

Summarize

This article mainly starts with an actual stolen case and introduces the risk of the permit signature. The SlowMist security team reminds you not to open websites of unknown origin to operate at will. When interacting with DApps, pay attention to controlling the number of Tokens authorized to the contract and carefully check the signature content. Use authorization tools such as RevokeCash from time to time (check for abnormal authorization, and also You can use the authorization management tool for Uniswap Permit2 (to check, if there is any abnormal authorization, please cancel the authorization in time.

Reference link: