WEB3-BLIND-SIGNING-2024
Web3 · Wallets · Blind signing of opaque transactions and messages
Résumé
Blind signing, approving a payload the wallet cannot decode, is the final step behind the largest multisig drains: Radiant Capital lost about $50M in October 2024 and Bybit about $1.5B in February 2025, both via hardware-wallet signers approving transactions whose true effect their devices could not render. In the Radiant attack, malware showed legitimate-looking transaction data in the Gnosis Safe front-end while the hardware wallets actually received and signed a Safe execTransaction whose inner operation was a delegatecall to an attacker contract; that delegatecall executed in the Safe's own storage context and overwrote the implementation/owner state, handing control to the attacker. Because a hardware wallet's small display can only show a four-byte selector and raw hex, signers cannot parse a nested execTransaction or distinguish a benign call from a delegatecall that rewrites storage slot zero. The same root cause applies to legacy eth_sign, which signs an arbitrary 32-byte hash with no context, letting a phishing site obtain a signature reusable as a transaction authorization. The signer sees one intent and authorizes a different one.
Comment l’éviter dans votre code
- Wallets and signers must adopt clear-signing (ERC-7730 descriptors) to render structured human-readable intent, and disable or hard-warn on legacy eth_sign.
- Builders should make hardware wallets decode Safe execTransaction, flag delegatecall operations distinctly, and refuse to show only raw calldata hashes.
- Multisig operators must independently verify transaction hashes on each signer's device against an out-of-band computed hash before approving.
- Teams should simulate every multisig transaction (Tenderly, Blockaid) and compare the simulated state change to the front-end's claimed intent.
- Users and signers should never approve a payload their device cannot fully decode; treat any opaque hash prompt as hostile.
Références
- https://www.cyfrin.io/blog/blind-signing-solved-130cb
- https://www.halborn.com/blog/post/explained-the-radiant-capital-hack-october-2024
- https://www.nccgroup.com/research/in-depth-technical-analysis-of-the-bybit-hack/
- https://unchainedcrypto.com/ethereum-foundation-launches-clear-signing-standard-to-end-blind-signing-exploits/
Vulnérabilités liées
Tout Web3 →- CRITICALWEB3-PERMIT-PHISHING-2024
Gasless permit signatures are now the dominant phishing vector: Scam Sniffer found Permit-type signatures accounted for 56.7% of 2024 wallet-drainer attacks within $494M of total losses, with cases like an October 13, 2024 Permit2 phish that drained roughly $1.39M of PEPE, MSTR and APU from one victim. EIP-2612 adds a permit(owner, spender, value, nonce, deadline, v, r, s) function so an owner signs an off-chain EIP-712 Permit struct that sets an ERC-20 allowance; the standard explicitly allows any address to submit it on-chain. The phishing dApp prompts that off-chain signature with the attacker as spender and value set to the full balance or type(uint256).max; the victim never sends a transaction or pays gas, and the wallet often shows an opaque typed-data blob. The attacker then submits permit() to register the allowance and immediately calls transferFrom to sweep the tokens. Uniswap's Permit2 generalizes this to every ERC-20: a single PermitSingle/PermitTransferFrom signature authorizes the attacker as spender, and because Permit2 defaults to the entire balance, one careless signature empties the wallet.
- HIGHWEB3-ADDRESS-POISONING-2024
Address poisoning exploits the human habit of verifying only the first and last few characters of a wallet address; on May 3, 2024 a whale lost roughly $68M in WBTC after copying a poisoned look-alike address, the single largest recorded case. Attackers brute-force a vanity address whose leading and trailing characters match an address the victim recently transacted with, then seed it into the victim's history. They do this cheaply by emitting a Transfer event the victim did not authorize: a zero-value ERC-20 transferFrom, or a fake-token contract that emits Transfer logs, so the look-alike address appears in the wallet's recent-activity list at essentially gas-only cost (the $68M poisoning transaction carried 0 ETH value and about $0.65 gas). Later, the victim copies the recipient from their own transaction history, pastes the attacker's near-identical address, and sends funds directly to it. No signature exploit is involved; the attack is pure UI deception of the wallet's transaction-history display.
- HIGHWEB3-APPROVAL-PHISHING-2023
On-chain approval phishing remains a core drainer technique within the hundreds of millions stolen annually (Scam Sniffer attributed $295M in 2023 and $494M in 2024 to wallet drainers), abusing the standard ERC-20 approve and ERC-721/1155 setApprovalForAll authorization model. A malicious dApp prompts the victim to send a real on-chain transaction calling approve(spender, type(uint256).max) for a token, or setApprovalForAll(operator, true) (selector 0xa22cb465) for an NFT collection, designating the attacker contract as spender or operator. Wallets historically rendered these as a generic approve with no amount or as an unreadable contract interaction, so the victim confirms a high-value, broad authorization without understanding its scope. Once the allowance or operator flag is set, the attacker's contract calls transferFrom or safeTransferFrom at any later time to drain every token or NFT covered, with no further victim interaction. The approval persists indefinitely until revoked, so victims who signed months earlier remain exploitable.
- CRITICALWEB3-DRAINER-2024
Drainer-as-a-service kits (Inferno, Pink, Angel) industrialized crypto phishing, stealing roughly $295M from over 324,000 victims in 2023 and $494M from 332,000 victims in 2024 per Scam Sniffer; Inferno alone took nearly $88M from 137,000 victims before its November 2023 shutdown, with operators keeping a 20% cut of every theft and handing affiliates ready-made phishing scripts spoofing 100+ brands. The kit serves a malicious dApp front-end that injects a JavaScript drainer; it enumerates the connected wallet's most valuable tokens and NFTs, then sequences signature prompts whose intent the wallet cannot meaningfully render: an EIP-2612/Permit2 permit, an unlimited ERC-20 approve, or setApprovalForAll. Because the wallet shows an opaque EIP-712 hash or a generic approval, the victim clicks sign or confirm; the drainer relays the resulting signature or on-chain approval and immediately calls transferFrom or safeTransferFrom from a backend to sweep assets to attacker wallets, splitting proceeds with the kit operator. The affiliate model means thousands of low-skill actors run identical, optimized drainer logic at scale.
- CRITICALWEB3-BNB-CHAIN-2022
On October 6, 2022, an attacker exploited the BSC Token Hub, the cross-chain bridge of BNB Chain, forging Merkle proofs to mint about 2 million BNB worth roughly $570 million. The root cause was a flaw in the IAVL Merkle-tree range-proof verification, which computed the tree root using only the left path and failed to verify that intermediate nodes had no right child; an attacker could append an arbitrary malicious right-leaf hash plus an empty inner node to balance the path without changing the root hash, so a forged proof passed validation. After registering as a relayer by depositing 100 BNB to reach the handlePackage() handler, the attacker submitted the forged proof to the iavlMerkleProofValidate precompile at address 0x65, validating a fabricated cross-chain message that authorized minting 1M BNB to their address, executed twice. BNB Chain halted all 44 validators (26 active), freezing the bulk of the funds on-chain; only about $137 million escaped to other networks, of which around $7 million was further frozen by Tether. No named attribution and no existing user funds were drained since the tokens were freshly minted.
- CRITICALWEB3-SIG-REPLAY-2022
Signature replay occurs when a signed message lacks binding context (nonce, chainId, or an EIP-712 domain separator), so a signature valid for one execution can be re-submitted on another call or another EVM chain. The canonical 2022 case is the Optimism/Wintermute loss of 20,000,000 OP tokens disclosed June 9, 2022: Wintermute provided a Gnosis Safe address deployed on Ethereum mainnet but not on Optimism. Because the Gnosis Safe factory's original deployment transaction used a pre-EIP-155 signature, its hash covered only six RLP fields (nonce, gasPrice, gas, to, value, data) and omitted chainId, so anyone could rebroadcast the identical signed transaction on Optimism. An attacker replayed that deployment to recreate the factory and Safe at the same counterfactual address on L2, gained control of the contract account before the rightful owners, and swept the 20M OP. The same low-level flaw appears in application contracts that ecrecover a digest missing nonce/chainId, letting one signed approval be replayed repeatedly.