This article explores FailSafe’s transformative X-Ray upgrade, and how it addresses a nefarious technique that’s quickly infiltrated the world of Web3: phishing via offline signatures. Largely unaddressed, the severity of this issue is underscored by the millions of dollars stolen from wallets via this method. FailSafe’s X-Ray innovation now provides a timely and crucial shield against this critical vulnerability.
Consider this scenario: you are navigating a dApp, clicking through numerous MetaMask popups. One popup asks you to sign something. After a quick click on a screen full of technical details, doubts begin to set in. On taking a second look, you start noticing a few anomalies in the dApp’s interface. A sinking feeling sets in. Did I just get phished?
You quickly rush over to Etherscan’s token approval checker, in the hope of revoking an inadvertent allowance approval. No, nothing new, and no new MetaMask transaction notification either. Perhaps everything is fine, perhaps too many Web3 fraud stories are taking their toll! And then you glance over at your USDC token balance: it goes from 2,000 to 0! How could that have happened?
These are the hallmarks of a rapidly growing type of Web3 attack: phishing via offline signatures. SlowMist, a blockchain security auditor, provides a thorough deep dive into past incidents involving ERC20 permits; an examination of how this vulnerability is amplified with the Uniswap V3 Permit2 contract is described here; and a good read on how this threat extends beyond ERC20s: OpenSea-related offline signature phishing attack.
This figure illustrates what this attack looks like for ERC20 tokens.
A user is misled into signing a Permit – a message authorising the payee address, to transfer funds from the victim’s account to the payee. It is offline, in the sense that the permit message, once in the possession of the attacker can be exercised at some point in the future (that is, no state changed on the blockchain, and therefore no transaction on the blockchain). In the figure above, after obtaining a signed permit, the attacker moves the victim’s ERC20 funds by executing two transactions: first calling the permit function on the ERC20 token, and then the transferFrom function. This is precisely the attack that OxPineapple.eth experienced. In this case, the attacker used an externally owned address (EOA). Depending on the timing, if there is a long enough delay between the above two transactions, it could be possible for the user to revoke the attacker’s allowance before funds are transferred out.
Unfortunately, for a manual response, this time window can be closed entirely as illustrated below.
The attacker simply uses a contract address instead of EOA during the phishing phase (when the victim signs the permit). The permit call and the transferFrom call are executed as part of a single transaction by the attacker’s contract (aka internal transactions). The above attack pattern was cited by the Web3 incidents report in which a top ten Degen Score user lost about USD 500,000.
While initially, permit functionality had limited adoption, there are now over 150 such ERC20 tokens on Ethereum alone (with links from crypto drainer sites as potential targets of opportunity; that we will not link here!). Uniswap V3 further popularised this approach via Permit2 functionality for legacy ERC20 tokens.
How does FailSafe address the above offline signature based attacks?
FailSafe Interceptor became generally available in September of 2023. It is part of the overall defence-in-depth product line up outlined in our whitepaper. At its core, the Interceptor detects unauthorised access to the user’s wallet assets (e.g., ERC20s, ERC721 tokens) and moves funds to the designated self-custody recovery wallet ahead of the attacker’s transaction. The attacker might outright gain access to the user’s private key, or obtain the user’s permission to transfer funds (via offline signature phishing attacks as described above). Irrespective, at some point, the attacker will submit a transaction, from an EOA, or via a contract, that will call one or more ERC20 or ERC721 token contract methods, to move the user’s funds. If the user enrols the wallet prior to this event with FailSafe, the user’s funds will be saved!
How does this work?
The enrollment process is illustrated below. Upon wallet authentication, the user activates the protection of various tokens owned by the wallet. This involves granting allowance to a per-user dedicated FailSafe wallet contract, as well as granting a gas allowance to the FailSafe Interceptor (to cover gas costs, if an interception transaction is needed to save the user’s assets). Note that no value is transferred to the FailSafe system. The above permissions are only used in the event an interception transaction becomes necessary. Moreover, the dedicated FailSafe wallet contract (that acts as a recovery vault for the intercepted tokens), is deployed just in time; thus the user does not need to pay for gas costs of deploying this contract until an interception becomes necessary.
FailSafe adheres to the secure by default principle: that is, the vast majority of Web3 users conduct transactions a very small percentage of the time. When the user is inactive, for almost all scenarios, no transactions should be initiated from the user’s wallet. The green system armed slider (above), enforces this expectation. Any transactions initiated by the user’s wallet key or via delegated permissions (such allowance or offline signatures, i.e., permits) will be intercepted. To transact, the user can temporarily disarm the green slider (refinements are in progress that will enable the user to transact with safe counterparties while the general protection remains in place).
The transaction interception process itself works as follows. The Interceptor service is globally distributed and co-located with bloXroute BDN endpoints in Europe, North America and Asia to minimise latencies. The Interceptor service processes an incoming stream of pending transactions (this includes MEV bundled transactions that do not show up directly in the public mempool). Based on ‘to’, ‘from’, and ‘tx’ input fields, a fast lookup is performed to a globally distributed redis cache to determine if the transaction is attempting to move assets under FailSafe’s protection (enrolled assets as shown above). If so, the Interceptor submits a transaction to the high speed bloXroute BDN with a higher gas price than that of the attacker (price influences order in which transactions are finally executed). It should be noted that the attacker’s transaction is still executed, but by the time it is executed the user’s funds have been moved to the user’s recovery vault contract.
The above works in practice. Using a fleet of test wallets, FailSafe executes numerous such attacks daily, for our Polygon, Ethereum, and BNB Chain deployments. The target Service Level Objective (SLO) for the upcoming quarter is 99% in-time interception (with upcoming optimisations to improve this success rate further).
Circling back to the permit attack from an Externally Owned Address, FailSafe detects a call to the permit method and ‘from’ address via the pending transaction’s input field, and submits a transaction to move the funds as described above.
However, this approach by itself doesn’t cover the scenario where the attacker uses a contract rather than an EOA. The attacker’s contract invocation of ERC20 permit and transferFrom methods are performed as internal transactions and are not visible from simply monitoring all pending transactions.
Enter X-Ray Mode
This month we released the X-Ray upgrade for FailSafe, which takes advantage of contract transaction simulation to process a real time stream of internal transactions while the parent transaction is still in pending state! This enables FailSafe to detect any ERC20 and ERC721 method invocations performed internally, triggering the Interceptor to move the user’s assets to their designated Recovery Vault. Please note that X-Ray is currently available on Ethereum and BNB Chain for public memory pools. Support for Polygon and private transactions is coming soon!
Dr. Gennady ‘Ari’ Medvinsky, FailSafe CTO