Examining Permit Signatures: Is Phishing of Tokens Possible via Off-Chain Signatures?
Background
On May 11th, a Twitter user with the handle “pineapple.eth” shared a tweet reporting that they inadvertently clicked on a phishing website (syncswap[.]network). This unfortunate action led to the compromise of their wallet and a loss exceeding $100.
Despite the relatively small financial loss, it raised considerable security risks. Victims frequently experience substantial losses as a result of the seemingly inconspicuous and the “invisible” nature of signature risks. That is why we wrote this article to bring awareness to this topic.
Based on the victim’s account, the details of the compromised transaction are as follows:
By analyzing these two transactions, it is evident that the contract caller (0x00002…d0000) utilized the TransferFrom function to move 34.87 USDC from the victim’s address (0xA4089…82C3) to (0x8256…D6B8), and 81.36 USDC to (0x5A69…1C17). Looking at the transferFrom function alone, it becomes clear that its intention is to enable a third party to initiate a transaction, transferring the associated funds from the owner’s account to the recipient’s account.
Upon further examination of the contract caller address (0x00002…d0000), an additional permit operation is observed, but it’s not present in the victim’s transaction records. What is the significance or purpose of this permit? Let’s first learn what a permit is.
What is Permit?
Permit was introduced in the ERC20 protocol through EIP-2612. It enables users to interact with smart contracts without requiring prior authorization by attaching an authorization signature (permit). In ERC20 token transactions, it is common for account A to use the approve function to grant authorization to account B, allowing B to handle specific tokens owned by A. This approval function can only be invoked by the account owner who granted permission.
However, the permit function serves a different purpose. It allows account A to generate an off-chain authorization signature for the designated recipient. This signature can then be provided to account B, who can utilize it to execute the permit function and perform authorized operations on behalf of A. These operations may include using the allowance to conduct transfers through transferFrom. By employing this approach, account A can authorize token transfers without relying on on-chain transactions. It is noteworthy that the permit function can be executed by any account, regardless of ownership. Furthermore, Uniswap has introduced a new Token Authorization Standard called Permit2.
Below 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;
…
}Having gained a foundational understanding, let’s delve into the phishing incident itself. The permit function in question possesses seven parameters:
- Owner: The address being authorized
- Spender: The recipient being granted authorization
- Value: The amount of tokens being authorized
- Deadline: A timestamp indicating the expiration time for the authorization
- V: Unit8 (Signature Data)
- R: Bytes32 (Signature Data)
- S: Bytes32 (Signature Data)
The permit function is characterized by the following parameters: a deadline of 1714509304969, indicating an extended validity until August 22nd, 56300 at 00:42 GMT, practically making it an almost unlimited duration. The authorized token quantity is 116.239404 USDC, matching the amount stolen from the victim. The v, r, and s values represent the signature data generated by the user (owner) after signing on the phishing website. The permit function validates the authenticity of the signature data. Once the signature is successfully verified, the user’s tokens are authorized to the hacker (spender).
Overall process
The victim signed the permit and shared it with the phishing website without broadcasting it to the blockchain. The hacker obtained this signature information and submitted the permit on-chain, effectively invoking the approve function for authorization. It is important to note that the signature process occurs off-chain and does not incur any gas fees for the signing party (victim) in terms of authorization and token transfers.
Unfortunately, similar to phishing attacks utilizing approved authorization, permit presents even greater risks as the possession of the signature alone grants authorization. For instance, in a decentralized exchange (DEX), the order placement feature only requires the user to sign a specific message. Consequently, the user can delegate their assets to the DEX without incurring gas fees. However, if the DEX is a phishing website that presents malicious messages to deceive users into signing, there is a potential risk of asset loss. From our understanding, some wallets decode and display signature information to approve authorization phishing attempts, but there is a lack of sufficient warning regarding permit signature phishing, posing higher risks to users. Additionally, since permit signatures occur off-chain, users may face challenges in recognizing whether their signatures have been compromised.
MistTrack Investigation
MistTrack has identified the following addresses as malicious phishing addresses.
Address 1: 0x00002644e79602F056B03235106A9963826d0000
Address 2: 0x82563Ba592986Cb277d67B2E7c56ab3BB3FDD6B8
Address 3: 0x5A697967F0791d12db8A0f92344Abc6DD07a1C17
Both transactions of the victim’s USDC have been converted to ETH.
Through our analysis of the stolen tokens such as ETH, WBTC, USDT, USDC, SHIB, DAI, WETH, DAI, stETH, and APE tokens, we determined that address 1 has accumulated stolen funds of around $120,000. Address 2 stole approximately $200,000, and address 3 has obtained stolen funds of roughly $2,000. Additionally, as per the findings of Scam Sniffer, a Web3 anti-scam platform, by May 9th, over 300 victims have fallen prey to the theft of assets worth approximately $690,000 through malicious signatures utilizing Permit2. Since Uniswap’s introduction of Permit2 on May 9th, nearly 670,000 addresses on the Ethereum mainnet have granted Permit2 authorization. However, it is important to note that these numbers merely scratch the surface of the overall operations of this scam, and this article only covered the tip of the iceberg.
Summary
In conclusion, this article highlighted the risks associated with permit signatures by examining a real-life theft case. The SlowMist Security Team emphasizes the importance of being cautious when interacting with websites of unknown origin, exercising caution when using DApps, managing authorized token quantities granted to contracts, and carefully inspecting signature contents. It is recommended to periodically use authorization tools like RevokeCash (https://revoke.cash) to identify any abnormal authorizations. For Uniswap Permit2, the authorization management tool at https://app.scamsniffer.io/permit2 can be utilized for verification. If any irregular authorizations are detected, it is crucial to promptly revoke them. For further knowledge on security, readers are encouraged to explore the SlowMist-produced “Blockchain Dark Forest Self-Guard Handbook” (https://github.com/slowmist/Blockchain-dark-forest-selfguard-handbook/blob/main/README_CN.md).
Reference links:
About SlowMist
SlowMist is a blockchain security firm established in January 2018. The firm was started by a team with over ten years of network security experience to become a global force. Our goal is to make the blockchain ecosystem as secure as possible for everyone. We are now a renowned international blockchain security firm that has worked on various well-known projects such as Huobi, OKX, Binance, imToken, Crypto.com, Amber Group, Klaytn, EOS, 1inch, PancakeSwap, TUSD, Alpaca Finance, MultiChain, O3Swap, etc.
Website：
https://www.slowmist.com
Twitter：
https://twitter.com/SlowMist_Team
Github：
https://github.com/slowmist/
