Phishing com setApprovalForAll: leia as assinaturas da carteira antes de assinar

Porque é que a maioria dos utilizadores de cripto subestima as assinaturas de carteira

Os pop-ups da carteira são todos parecidos: o nome de um site em cima, o nome do método no meio, um botão Confirmar em baixo. Como o aspeto visual quase não muda entre uma troca de tokens de 5 $ e o esvaziamento total da carteira, os utilizadores aprendem a clicar sem pensar. Esse hábito é exatamente aquilo que o phishing de assinaturas explora.

A verdade é que os quatro tipos de assinatura mais comuns, approve(), setApprovalForAll(), permit e eth_sign, fazem coisas radicalmente diferentes. Três são bem compreendidos e têm utilizações legítimas. Um deles, eth_sign, não tem qualquer utilização legítima na Ethereum moderna e existe quase exclusivamente em kits de phishing. Tratá-los como se fossem intercambiáveis é a forma como as pessoas perdem as suas coleções.

Antes de analisar cada um, vale a pena lembrar que uma assinatura de carteira é uma autorização, não apenas uma autenticação. Quando assina com a sua chave privada, não está apenas a provar quem é; está muitas vezes a dar ao destinatário permissão para mover um ativo em seu nome. A assinatura é a permissão.

Os tipos de assinatura, ordenados pela frequência com que esvaziam carteiras

Nem todas as assinaturas colocam os seus fundos em risco de igual forma. Eis como os quatro tipos principais se comparam, ordenados aproximadamente do mais perigoso para o mais inofensivo.

eth_sign: quase sempre uma burla

eth_sign produz uma assinatura ECDSA em bruto sobre texto arbitrário, sem dados estruturados e sem domínio on-chain. Não há um formato de mensagem padrão, pelo que o site lhe tem de dizer em linguagem simples o que está a assinar, e a maioria das carteiras nem sequer o interpreta. Qualquer coisa que lhe peça para assinar uma mensagem eth_sign em 2026 é, na esmagadora maioria dos casos, uma tentativa de phishing. Algumas ferramentas legítimas ainda a utilizam (autenticadores mais antigos, algumas consolas de debug), mas para o uso quotidiano em DeFi e NFTs deve tratar eth_sign como um recusa automática.

setApprovalForAll: acesso total a NFTs

setApprovalForAll(tokenAddress, operator, true) diz ao contrato de NFT para permitir que um endereço operador específico mova todos os NFTs que possui dessa coleção, presentes e futuros. Aprovar um marketplace de NFTs como o OpenSea ou o Blur é normal: o marketplace precisa de transferir os NFTs quando uma sua ordem é executada. O problema é que a mesma chamada para um contrato de phishing entrega toda a sua coleção Bored Ape, e não apenas um token.

Os danos não são limitados. Se cunhar um novo NFT dessa coleção mais tarde, a aprovação antiga continua a cobri-lo. Se receber um airdrop no mesmo contrato ERC-721, o operador pode varrê-lo também. Não há prazo de validade nem limite por token.

Assinaturas Permit: aprovações de tokens sem gás

Permit (EIP-2612) e o seu sucessor Permit2 permitem-lhe autorizar um gasto de ERC-20 com uma assinatura off-chain em vez de uma transação approve on-chain. A vantagem é real: sem gás, UX mais fluida, sem passo de aprovação separado. O custo é que uma assinatura permit é um cheque em branco que o spender pode submeter a qualquer momento antes do prazo que definiu.

As stablecoins são o alvo principal. Um site de phishing que ofereça um "reclamação de USDC" ou um "verificador de airdrop" pode silenciosamente pedir um permit que dá ao atacante USDC ilimitado durante a próxima hora ou mais. Pode sair do site, ir embora e voltar horas depois para descobrir que o seu USDC desapareceu. A transação mostra até o token legítimo e o seu próprio endereço, o que a faz parecer normal nos exploradores de blocos.

approve(): o padrão limitado, mas ainda assim arriscado

approve(spender, amount) define uma allowance de token. Se o amount for pequeno (digamos, 5 USDC para uma troca), o raio de destruição é pequeno. Se o amount for a constante mágica MaxUint256 (~2^256 - 1), a aprovação é efetivamente ilimitada e comporta-se de forma semelhante a um permit.

Muitos protocolos DeFi legítimos pedem aprovações ilimitadas por defeito porque só precisam de perguntar uma vez e liquidam mais tarde. Essa conveniência é também a conveniência do atacante: quando as chaves do spender são comprometidas, os seus tokens vão com elas.

Passo a passo: como ler uma janela da carteira antes de assinar

Seja qual for a carteira, a rotina é a mesma. Não assine no piloto automático.

Passo 1: ler o nome da função

Se vir setApprovalForAll, permit ou eth_sign, abrande. Cada uma comporta os riscos acima. Uma troca limpa mostrará transferFrom ou uma chamada do router de swap, e não uma concessão de permissão.

Passo 2: ler os parâmetros

Para aprovações, verifique quem é o spender. Para setApprovalForAll, verifique o endereço do operator. Confirme ambos com o contrato real do protocolo (separador "Contract" no Etherscan, documentação do projeto). Se o endereço for novo ou não tiver um nome público, trate-o como hostil até prova em contrário.

Passo 3: ler a simulação

As carteiras modernas (Rabby, Frame, MetaMask com simulação do Tenderly) mostram uma pré-visualização da mudança de estado: que tokens se movem, em que direção e em que contrato. Se a simulação estiver vazia ou não carregar, isso por si só é um sinal de alerta. Assinaturas legítimas produzem simulações previsíveis.

Passo 4: verificar o prazo

As mensagens de permit incluem um timestamp de prazo. Um prazo daqui a um ano é mais perigoso do que um que expira em dez minutos. O signatureTransfer do Permit2 inclui campos adicionais (witness, expiration) que determinam quão amplamente a assinatura pode ser usada. Trate prazos invulgarmente longos como suspeitos.

Passo 5: usar uma carteira descartável dedicada

Para airdrops, mints e sites desconhecidos, mantenha uma carteira separada, financiada apenas com o que está disposto a perder. As aprovações na carteira descartável nunca conseguem tocar nos seus fundos principais. Esta é a forma mais barata de seguro em cripto.

Como os atacantes transformam assinaturas legítimas em esvaziamentos

O assustador é que o atacante raramente precisa de quebrar qualquer criptografia. Só precisa que clique uma vez em Confirmar.

A armadilha clássica da listagem de NFTs

Calha numa página falsa do OpenSea que replica a interface real. Pede-lhe para "cancelar uma listagem presa" assinando um setApprovalForAll para o contrato do marketplace. A maioria dos utilizadores não repara que "cancelar listagem" não exige qualquer assinatura, por isso assinam. O atacante passa agora a controlar todos os NFTs nessa carteira para essa coleção, e a aprovação nunca expira.

Assinaturas de marketplace estilo Seaport

O protocolo Seaport da OpenSea usa assinaturas de ordens off-chain (em vez de listagens on-chain) para tornar ofertas e listagens mais baratas. Uma ordem Seaport assinada é um conjunto de parâmetros: zone, conduit, fulfilling components, etc. As páginas de phishing aprenderam a imitar estas assinaturas porque os utilizadores veem "OpenSea" na assinatura e assumem que é seguro. Leia os parâmetros, não o nome do protocolo.

Phishing de permit em stablecoins

USDC e USDT suportam permits do EIP-2612. Um site que "verifica o seu saldo de USDC" pode esconder um permit no botão Sign. Confirma uma vez, segue em frente, e a assinatura fica no mempool à espera que o atacante a submeta dentro da janela de validade. A transação on-chain parece um TransferFrom normal de USDC, o que dificulta a sua identificação num explorador de blocos mais tarde.

Address poisoning encontra aprovações

Alguns kits de phishing geram agora um endereço personalizado que começa e termina com os mesmos caracteres do seu contraparte real. Quando um utilizador olha de relance para o destinatário, a correspondência do prefixo parece correta. O mesmo truque está a ser adaptado aos campos de spender de aprovação: o spender malicioso partilha os primeiros e últimos quatro caracteres de um legítimo, esperando que aprove visualmente em vez de ler o endereço completo.

Implicações práticas: como tornar a sua carteira mais difícil de esvaziar

Ler assinaturas é hábito, não talento. Crie alguns padrões que resistam a noites de cansaço.

• Use Rabby ou Frame como carteira de uso diário. Ambas interpretam os tipos mais comuns de assinatura em linguagem simples e mostram a função que está a ser chamada, e não apenas o nome do método.
• Mantenha uma hardware wallet para quaisquer fundos com significado. As chaves de assinatura nunca tocam numa máquina ligada à internet, por isso nem uma dapp maliciosa consegue extrair uma assinatura utilizável.
• Faça uma auditoria mensal de aprovações usando revoke.cash (interface popular e amigável) ou o verificador de aprovações do Etherscan (sem login, dados brutos). Revogue tudo o que diga respeito a um contrato que não utilizou nos últimos 90 dias.
• Substitua aprovações genéricas após cada grande swap: altere a allowance para 0 e depois volte a aprovar um valor pequeno. Isto invalida aprovações ilimitadas antigas.
• Desative o eth_sign nas definições da carteira, se a opção existir. MetaMask, Rabby e Rainbow expõem isto nas definições avançadas.
• Adicione aos favoritos as dapps que realmente utiliza. A maior parte do phishing chega aos utilizadores através de anúncios de pesquisa ou links no Twitter, não de favoritos. Tudo o que é acedido por um resultado de pesquisa merece uma leitura extra.

Nenhuma destas medidas é um grande esforço. O ponto é que o esforço marginal para verificar uma assinatura é pequeno, enquanto o custo de o saltar é a carteira inteira.

Perguntas frequentes sobre phishing de assinaturas

Seguem-se as perguntas que os leitores mais escrevem em motores de busca sobre phishing de assinaturas de carteira. As respostas cingem-se a factos educativos, e não a aconselhamento financeiro, porque o comportamento correto aqui depende dos fundos e do modelo de ameaça de cada leitor.

Como acompanhar a segurança de carteiras de forma inteligente

O phishing de assinaturas em carteiras avança depressa porque a superfície de ataque também avança depressa: cada nova primitiva de DeFi é um novo tipo de assinatura a aprender, e cada nova funcionalidade de carteira é um novo sinal visual a interpretar. Acompanhar aprovações, denúncias de burlas e análises pós-incidente em várias cadeias é um trabalho a tempo inteiro, e a maioria dos utilizadores não tem esse tempo.

Zippfeed agrega manchetes de segurança em Ethereum e no ecossistema cripto em geral, atribui a cada notícia uma pontuação de sentimento (bullish, neutro ou bearish quanto ao protocolo mencionado) e apresenta uma classificação de importância de 0 a 100, para que possas analisar o dia em poucos minutos, perceber que assinaturas e aprovações estão a ser abusadas neste momento e revogar permissões de gastadores arriscados antes que esvaziem a tua carteira.