Phishing de aprovação: por que sua carteira pode ser esvaziada sem uma assinatura

📖 Por que uma carteira pode ser esgotada “sem assinatura”

Phishing de aprovação (ou phishing de gelo) não se trata de roubar uma frase-semente e não exige arrombamento da carteira. O ataque abusa de funções de permissão legítimas: o usuário confirma Approve (uma transação que registra o direito de gastar tokens para um endereço específico) ou DefinirAprovaçãoParaTodos (habilitando um operator que pode transferir todos os NFTs da coleção do proprietário) uma vez, após a qual um contrato inteligente recebe o direito de mover ativos sem novas confirmações.

Objetivo deste guia: explicar como funcionam as permissões (aprovação é o ato de outorga de direitos, allowance é o limite de gastos registrado), decompor o principal phishing de aprovação cenários, mostrar como inspecionar direitos concedidos em redes EVM, e explicar como funciona a revogação de permissões para que após a transação o endereço spender/operator não tenha mais o direito de gastar ativos.

A principal vulnerabilidade aqui é a expectativa de que cada gasto exija uma assinatura separada. Na interface de uma carteira, a assinatura parece uma etapa comum (“permitir”, “conectar”, “confirmar para troca”), então o usuário confirma não uma transferência, mas uma concessão de direitos que é armazenado no contrato e usado posteriormente sem outra janela de confirmação.

Um allowance desnecessário (um limite registrado no contrato que define quantos tokens podem ser gastos) para uma stablecoin ou um ativo setApprovalForAll (status operator para uma coleção NFT inteira) cria acesso duradouro aos ativos: gastos simbólicos através transferFrom (uma função ERC-20 que permite que um contrato gaste tokens do endereço do proprietário dentro de allowance sem uma nova assinatura) ou a transferência NFT por um operator é possível a qualquer momento até que a permissão seja revoked.

O phishing de aprovação usa concessões de permissão por meio de approve/permit (criando ou alterando um allowance) ou setApprovalForAll, não é um “hack” do protocolo. Uma assinatura é suficiente para que um registro de direitos apareça no contrato, permitindo que os ativos sejam gastos posteriormente sem a participação do proprietário.

Uma assinatura approve/permit ou setApprovalForAll cria um registro de direitos em um contrato; a retirada do token ou transferência NFT pode acontecer posteriormente, sem uma nova janela de confirmação, enquanto a permissão permanece ativa.

🎣 O que é phishing de aprovação e por que sua “honestidade” é desonesta

O phishing de aprovação utiliza mecanismos normais de permissão: a concessão de direitos parece legítima, não causa uma perda imediata de fundos e, portanto, muitas vezes não é percebida como um risco no momento da assinatura.

Phishing de aprovação é um ataque no qual um usuário é persuadido a conceder um permissão (aprovação/allowance) para gerenciar tokens ou NFTs, e esse direito é então usado para retirar ativos. A ação perigosa está disfarçada como uma etapa familiar da interface: “confirmar para troca”, “permitir cunhagem”, “assinar para reivindicação”, “conceder acesso para depósito”.

Ao contrário do roubo de chaves, o invasor não precisa da chave privada e não precisa de transferência direta de fundos. Basta que o usuário uma vez conceder a um endereço específico o direito de gastar ativos: um spender para tokens ERC-20 ou um operator para NFTs. Depois disso, o saque é realizado sem novas janelas de carteira e sem repetidas confirmações por parte do proprietário.

No nível do blockchain, as transações parecem válidas: o usuário realmente alterou o estado do contrato e concedeu direitos a um endereço específico. É por isso que a carteira não é formalmente “hackeada”: os ativos saem através de permissões previamente concedidas, e não através de um desvio da assinatura.

Em termos simples: approve não é uma transferência, mas uma concessão de direitos de gastos para um endereço específico. Phishing de aprovação significa que o usuário é induzido a conceder esse direito a um endereço controlado pelo invasor enquanto ele é apresentado como uma etapa normal de troca, cunhagem ou reivindicação.

O phishing de aprovação funciona por meio de permissões válidas. O perigo surge após a assinatura, quando um direito de gasto ativo é utilizado sem a participação do titular.

As permissões em EVM são registros de direitos em contratos, e não ações únicas; é por isso que approve pode permanecer ativo por meses e ser usado sem assinatura repetida.

🧠 Como funcionam as permissões em EVM: allowance, spender e “approve infinito”

Uma permissão EVM é um registro de estado em um token ou contrato NFT que conecta seu endereço a um endereço spender/operator específico. Este registro define quem pode gastar tokens através transferFrom ou transfira NFTs como operator, e ele permanecerá válido até que o proprietário o altere com uma nova transação.

1. ERC-20: approve → allowance → transferFrom
   • O usuário chama approve(spender, valor) e especifica o endereço spender.
   • O contrato de token armazena o allowance limit — o número máximo de tokens que spender pode gastar.
   • As chamadas spender transferFrom e gasta tokens sem novas assinaturas até que allowance se torne 0 ou se esgote.
   • O contrato verifica allowance durante transferFrom; não solicita a assinatura do proprietário para cada gasto.
2. A permissão está vinculada ao proprietário → spender → token
   • A permissão existe apenas para um token específico e um spender específico.
   • Um approve para USDT não concede acesso ao USDC e não se estende a outros contratos.
   • Cada novo token ou novo spender requer um approve separado.
3. Aprovação ilimitada é o valor máximo allowance
   • Com approve ilimitado, o allowance armazena o valor numérico máximo.
   • O spender recebe o direito de gastar tokens desse contrato dentro deste valor, incluindo depósitos futuros no endereço.
   • A permissão permanece ativa até uma transação revoke, mesmo que o serviço não seja mais usado.
4. NFT: setApprovalForAll é o status operator sem limite
   • setApprovalForAll(operator, verdadeiro) ativa o status operator para toda a coleção NFT do proprietário.
   • Não se trata de um limite por quantidade ou valor: o direito permanece até setApprovalForAll(operator, falso) é enviado.
   • Se o operator estiver comprometido, o NFTs poderá ser retirado sem confirmações do novo proprietário.

As permissões EVM são registros de direitos de longa duração em contratos. Um approve pode funcionar por meses, ilimitado aumenta o limite de gastos disponíveis e setApprovalForAll remove os limites de quantidade para NFT operator.

Uma assinatura permit (por exemplo, EIP-2612) dá a um aplicativo o direito de definir allowance por meio de uma mensagem assinada; o aplicativo então usa essa assinatura em uma transação que concede direitos e executa a ação em uma chamada.

🧾 Permissão, Permit2 e assinaturas de mensagens: como as permissões são concedidas sem um approve separado e por que os invasores usam isso

Além do approve comum, o EVM possui maneiras de conceder permissão sem uma transação separada. O usuário simplesmente assina uma mensagem, e o aplicativo usa essa assinatura em sua própria transação, que concede o direito de gastar e executa a ação – troca, depósito ou reivindicação. Essa mecânica é chamada permit e extensões como Permit2.

Do ponto de vista UX, isso parece menos etapas: não há nenhuma transação approve separada e nenhum gás é necessário para uma chamada approve separada. A consequência técnica é a mesma: um direito de gasto aparece no contrato, e esse direito pode permanecer ativo além de uma única operação se os parâmetros de assinatura estabelecerem um limite amplo ou uma expiração longa.

Permissão e “assinaturas sem gás” alteram apenas a forma de confirmação. Uma assinatura de mensagem pode instalar direitos de acesso a tokens ou NFTs, assim como approve, portanto, os parâmetros de assinatura devem ser lidos como concessões de permissão.

Em esquemas típicos de phishing de aprovação, o usuário é levado a assinar approve/permit ou setApprovalForAll sob o pretexto de “Reivindicação”, “Mint” ou “Depósito”, e o direito ativo é então utilizado para gastos.

🧪 Esquemas típicos de phishing de aprovação: como você é levado à assinatura “certa”

Esses esquemas usam interfaces familiares e fluxos de trabalho padrão, o que faz com que a concessão de permissões pareça uma etapa de serviço comum.

Quase todos os ataques seguem a mesma lógica: primeiro o usuário é levado a uma página que se parece com uma interface dApp, depois a página solicita uma assinatura que concede um direito de gasto ou direito operator, e depois disso a permissão ativa é usada para retirar ativos sem novas confirmações.

A principal característica é a ausência de solicitação direta de envio de transferência. Em vez de uma transferência, o site solicita approve/permit ou setApprovalForAll: uma mudança de estado contratual que cria o direito de administrar os ativos do proprietário.

1. Clone de um serviço popular
   • Um domínio falso ou link de publicidade leva a uma cópia visualmente semelhante de um DEX ou mercado.
   • A interface solicita approve “para troca” ou setApprovalForAll “para listagem NFT”.
   • Os parâmetros de assinatura contêm um spender/operator que não pertence ao serviço real.
2. Comprometimento dos canais oficiais
   • Um link é postado em Discord, Telegram ou X em nome do projeto ou de um moderador.
   • São utilizados gatilhos de urgência: “bug de contrato”, “migração mint”, “última chance”.
   • O link leva a uma página que solicita approve/permit o endereço do invasor.
3. Engenharia social através de “apoio”
   • O invasor envia uma mensagem privada fingindo ser o suporte do serviço.
   • A assinatura é solicitada sob o pretexto de “cancelar uma transação travada”.
   • Na prática, o usuário assina um permit ou concede approve a um endereço de terceiro.
4. Substituição do significado da assinatura
   • A janela da carteira exibe uma chamada técnica sem explicação clara da interface.
   • O usuário confirma sem verificar o endereço spender/operator e o limite.
   • O risco é maior quando a interface não mostra spender, limite ou tipo de permissão.

Esquemas típicos de phishing de aprovação disfarçam a concessão de direitos como ações familiares. Enquanto o status allowance ou operator estiver ativo, o invasor pode usá-lo a qualquer momento sem novas confirmações do proprietário.

Subsídio e setApprovalForAll não possuem prazo de validade: o registro de direitos permanece no contrato até que o proprietário envie uma transação que redefina o allowance ou desative o operator.

🧯 Erros comuns dos usuários: por que as aprovações se acumulam e se tornam uma ameaça

O perigo das aprovações raramente é sentido no momento da assinatura porque approve normalmente não altera o saldo. O risco aparece mais tarde, quando uma permissão ativa é usada para gastos, e torna-se mais forte se tais permissões permanecerem em várias redes e vários tokens.

A mesma lógica se aplica a setApprovalForAll para NFTs. O usuário trata isso como uma ação única para listagem ou cunhagem, mas um status operator ativo permanece no contrato de coleta e permite a transferência de NFT sem confirmações de novo proprietário.

Uma classe separada de erros vem da confiança na marca e no design visual. O usuário foca no domínio, logotipo ou layout, mas a permissão é sempre concedida para um endereço específico — spender ou operator. Se a interface for substituída, o design não altera o endereço nos parâmetros de assinatura.

Outro erro comum é considerar o problema encerrado após revoke em uma rede. As aprovações são isoladas por rede: allowance em Ethereum e allowance em Arbitrum são registros diferentes em contratos diferentes, portanto uma permissão pode permanecer ativa em outra rede.

Assinaturas sem gás criam confusão adicional. A permissão e mecanismos semelhantes são percebidos como confirmações “soft”, mas o resultado é o mesmo: o aplicativo recebe a capacidade de instalar uma permissão que é então usada para gastos.

Os erros tornam-se mais perigosos quando uma carteira é usada ao mesmo tempo para armazenamento, negociação ativa e experiências. Nesse modo, um spender/operator desnecessário cria acesso a ativos que não faziam parte da operação original.

A principal ameaça das aprovações são as permissões ativas que permanecem nos contratos após a conclusão de uma tarefa. allowance ilimitado, um NFT operator habilitado e permissões em diversas redes aumentam a quantidade de ativos disponíveis para gastos sem novas confirmações.

As permissões devem ser verificadas separadamente para cada rede: as listas allowance e operator em Ethereum não correspondem a Arbitrum, Optimism, Polygon ou BSC, porque os registros de direitos são armazenados em contratos na rede específica.

🔎 Onde verificar as permissões: o que exatamente inspecionar e em que ordem

A revisão de permissão é uma sequência de etapas por rede e tipo de ativo. Os tokens ERC-20 e NFTs usam mecanismos de acesso diferentes, portanto, devem ser analisados ​​separadamente e fechados em ordem de prioridade: primeiro endereços desconhecidos e limites amplos, depois as permissões de trabalho restantes.

1. Identifique a rede com mais atividade
   • As permissões não são “globais”: Ethereum, Arbitrum, Optimism, Polygon e BSC têm listas de aprovação separadas.
   • Comece pela rede onde a liquidez está concentrada e onde aconteceram as últimas transações.
2. Verifique as aprovações ERC-20 e reduza o que é desnecessário
   • A prioridade vai para spenders desconhecidos e allowance ilimitados em stablecoins e tokens líquidos.
   • Remova permissões não utilizadas e reduza os limites da quantidade necessária para a operação atual.
3. Verifique as aprovações NFT separadamente
   • Preste atenção especial a setApprovalForAll para mercados e jogos dApps.
   • Mantenha um operator ativo apenas durante o período em que for realmente necessário.
4. Verifique os endereços que você deixa ativos
   • Combine endereços spender/operator com serviços confiáveis pelo endereço na assinatura ou no explorador.
   • Se um endereço não for reconhecível, redefina allowance ou desative operator e conceda uma nova permissão somente quando necessário.

O que procurar em uma lista de permissões

A revisão de permissões deve corresponder à forma como as permissões são armazenadas: redes separadas, tokens separados, spenders/operators separados. Priorizar permissões desconhecidas e ilimitadas fecha os principais cenários de gastos sem novas confirmações.

Revoke é uma transação que define allowance como 0 para o par de tokens ou switches proprietário→spender→ setApprovalForAll(operator) para falso; após a confirmação da rede, o endereço spender/operator perde o direito de gasto.

🧹 Como obter permissões revoke corretamente: tokens, NFTs e erros comuns

Revoke é uma transação on-chain que altera allowance ou desativa um NFT operator. Com isso, o contrato registra um novo estado: um endereço específico não tem mais o direito de administrar seus ativos. Revoke interrompe gastos futuros, mas não reverte transações que já foram executadas.

Algoritmo revoke passo a passo para ERC-20

1. Identifique a rede. As aprovações são isoladas por rede: Ethereum, Arbitrum, Optimism e outros L2s possuem listas de permissões separadas.
2. Encontre o token e spender. Verifique o endereço do contrato do token, o nome do token e o limite allowance atual, especialmente para stablecoins e ativos líquidos.
3. Execute revoke. A opção padrão é definir allowance como 0 por meio de approve(spender, 0) ou usar um botão revoke em um serviço.
4. Verifique o resultado. Certifique-se de que allowance tenha se tornado 0 e a permissão não seja mais exibida como ativa.

Algoritmo revoke passo a passo para NFTs

1. Abra a lista da coleção operator. Procure ativo setApprovalForAll entradas e endereços operator relacionados.
2. Desative operator. O status deve ser alterado para falso.
3. Repita para coleções de chaves. Verifique primeiro as coleções com maior valor e liquidez.

Revoke altera o registro de direitos no contrato: allowance passa a 0 ou operator está desabilitado. Para que revoke realmente feche o acesso, ele deve ser realizado na rede correta e para o par token→spender ou coleção correto→operator correto.

Se você concedeu approve/permit ou setApprovalForAll para um invasor, os gastos podem acontecer mais tarde, inclusive depois de você recarregar o saldo. Uma ordem de ação clara ajuda primeiro a mover os ativos para fora do escopo das permissões ativas, depois redefinir allowance e desabilitar operator para fechar o acesso a gastos.

🚨 Se você já concedeu um approve perigoso: um plano rápido de redução de danos

Nessa situação, a ordem das ações é importante: primeiro afaste os ativos das permissões ativas, depois redefina allowance e desative operator, e somente depois disso investigue a origem da assinatura.

Se phishing de aprovação se houver suspeita, o ponto crítico é que as permissões concedidas já podem ser utilizáveis. Embora allowance esteja acima de zero ou operator esteja ativado, os gastos podem ser iniciados a qualquer momento, inclusive após a chegada de novos fundos ao endereço.

Após a concessão de uma permissão perigosa, a prioridade é reduzir a quantidade de ativos acessíveis por meio de allowance/operator e, em seguida, redefinir esses direitos com transações revoke. Enquanto os direitos permanecerem ativos, os gastos poderão acontecer sem novas confirmações.

Prevenir o phishing de aprovação se resume a controlar dois parâmetros: quem recebe o direito (spender/operator) e quão grande ou amplo é esse direito (allowance ou setApprovalForAll).

🛡️ Prevenção: como conceder permissões sem se tornar um alvo fácil

A prevenção de phishing de aprovação é construída em torno do gerenciamento de permissões: separando funções de carteira, limitando allowance e desabilitando operator após a conclusão da tarefa.

A maioria das perdas está vinculada a permissões ativas que permanecem nos contratos após o término de uma operação: allowance ilimitado, um NFT operator habilitado e o hábito de confirmar assinaturas sem verificar o endereço. Esses registros de direitos permitem gastos sem novas confirmações até revoke.

Separando funções de carteira

Usar um endereço para armazenamento, negociação e experimentos torna qualquer approve crítico para todo o saldo desse endereço. A separação de endereços limita a quantidade de ativos expostos por meio de allowance ou operator. Se você escolher uma carteira de “armazenamento” de longo prazo, comece com uma revisão de carteira criptografada de hardware e configure o armazenamento frio antes do trabalho ativo do DeFi.

Reduzindo o escopo de cada permissão

Mesmo ao trabalhar com serviços confiáveis, considere o cenário de um erro ou comprometimento spender/operator. Para ERC-20, o escopo do direito é definido por allowance; para NFTs, o escopo é definido por setApprovalForAll estado.

Modo de revisão: quando verificar as aprovações

1. Após uma operação única. Se o serviço não for usado regularmente, redefina allowance ou desative operator após a conclusão da operação.
2. Para um endereço DeFi operacional. Com atividade constante, revise as aprovações uma vez a cada uma ou duas semanas e remova permissões desnecessárias.
3. Para um endereço experimental. Para novos dApps e airdrops, verifique e feche as permissões após cada sessão.

A prevenção de aprovação é o gerenciamento ativo de permissões: separação de endereços, limites exatos de allowance e desativação de operator após a tarefa reduzem a quantidade de ativos disponíveis para gastos sem novas confirmações.

Approve permite chamada de protocolos transferFrom sem assinatura para cada operação; o mesmo mecanismo significa que uma permissão ativa pode ser usada para gastos posteriores, caso tenha sido concedida a um endereço desnecessário.

⚖️ Approve como mecanismo: pontos fortes e riscos integrados

Approve é a base da infraestrutura DeFi: permite que protocolos executem operações por meio de transferFrom baseado em allowance, mas torna o proprietário responsável pelo endereço spender e pelo limite allowance.

O mecanismo approve é uma compensação entre manter ativos em seu próprio endereço e automatizar ações de protocolo. Os ativos permanecem em seu endereço, mas o contrato recebe o direito de gastá-los dentro do allowance definido em approve.

Approve é um mecanismo de infraestrutura para gerenciamento de direitos. É conveniente porque a transferência é executada por meio de allowance sem assinaturas repetidas e arriscado porque uma permissão ativa funciona até revoke e pode ser usada para gastos posteriores.

📚 Casos e lições: por que um “contrato correto” ainda pode se tornar um problema

Mesmo ao trabalhar com serviços legítimos, as aprovações ativas criam riscos: uma vulnerabilidade, atualização ou substituição de frontend torna-se perigosa se allowance já estiver registrado ou operator estiver habilitado no contrato.

A principal propriedade das aprovações é a ausência de “vida útil”. Caso a permissão tenha sido concedida, o contrato não precisa solicitar novamente approve: ele utiliza os direitos já registrados. Portanto o risco depende não só do serviço atual, mas também da lista de aprovações acumuladas no endereço.

Na prática, os incidentes acontecem porque as permissões permanecem após a conclusão das operações. A revisão regular e a desativação de allowances e operators desnecessários limitam a quantidade de ativos disponível para gastos sem uma nova assinatura.

Um approve/permit errado ou setApprovalForAll concede a um endereço externo o direito de gastar tokens por meio de allowance ou transferir NFTs como operator; enquanto a permissão estiver ativa, a carteira não solicitará uma nova assinatura para os gastos em si.

✅ Como se proteger contra phishing de aprovação e manter as permissões sob controle

As permissões são a base da mecânica DeFi, mas os status allowance e operator são exatamente o que permitem que os ativos sejam retirados sem uma assinatura repetida se o direito for concedido a um endereço desnecessário.