Como revogar aprovações maliciosas e fechar brechas

Revogar aprovações maliciosas significa enviar uma transação on-chain que reescreve a permissão de um token, geralmente definindo-a como 0 para o gastador que pode chamar transferFrom do seu saldo. Desconectar uma carteira de um dApp é apenas uma ação de interface, portanto, não remove aprovações de tokens nem impede um drainer de carteira que já possui permissão de gasto.

Principais Conclusões

• Uma aprovação de token é uma permissão permanente no contrato do token, e persiste até que você a altere on-chain.
• Para revogar a aprovação, você envia uma transação que define a permissão do gastador como 0 ou um valor menor, e você paga gas.
• Aprovações ilimitadas são a versão explosiva das permissões porque um gastador comprometido pode drenar esse saldo de token até o limite da permissão.
• Permit2 pode esconder riscos por trás de assinaturas: você pode ver apenas uma aprovação on-chain para o Permit2 enquanto o verdadeiro perigo é assinar uma autorização EIP-712 maliciosa.

Por que as aprovações de token podem ser perigosas

Uma aprovação maliciosa não é "uma conexão de dApp." É uma permissão ativa em um contrato de token que diz que um gastador específico pode mover seus tokens com transferFrom.ERC-20transferências delegadas funcionam em três funções: approve(spender, amount), allowance(owner, spender) e transferFrom(from, to, amount). Uma vez que essa autorização existe, o gastador não precisa mais da sua carteira. Ele só precisa que a autorização ainda seja não zero.

Essa persistência é todo o problema. As autorizações permanecem ativas até serem explicitamente alteradas, razão pela qual os botões de “desconectar carteira” e as listas de conexão de carteira são uma falsa sensação de segurança. Desconectar remove a capacidade de um site de solicitar sua carteira. Isso não faz nada para o estado do contrato do token que realmente autoriza o gasto.

É por isso quephishing de aprovaçãofunciona: o objetivo do atacante é obter uma aprovação de token (ou uma assinatura estilo permissão) uma vez, e então usá-la mais tarde quando a vítima não estiver mais prestando atenção.

Aprovações ilimitadas são onde o risco de cauda reside. Muitas interfaces padrão para “infinito” porque isso reduz a fricção futura, mas aprovar o valor máximo uint256 efetivamente entrega ao gastador um cheque em branco para aquele token. Se o contrato do gastador for malicioso hoje, ou for explorado mais tarde, a autorização é o caminho de drenagem.

Para os traders, o modelo mental que se sustenta é “linha de crédito disponível”. Cada aprovação de token é um item de linha: token → gastador → limite. Se o leitor não consegue apontar para o contrato exato que atualmente tem permissão para chamar transferFrom (seja diretamente ou via Permit2), a exposição real é desconhecida. Esta é uma das mecânicas centrais por trás das fraudes de carteiras de criptomoedas e como evitá-las.

Como funciona a revogação de uma aprovação

Revogar não é um botão de configuração. É uma mudança de estado na blockchain, o que significa que custa gás e deixa um registro de transação. Mecanicamente, uma revogação de aprovação é apenas reescrever o mapeamento de autorização no contrato do token para que a autorização do gastador se torne 0 (ou um número menor se o objetivo for continuar usando o aplicativo com um limite máximo).

Dois detalhes operacionais importam mais do que a maioria dos guias admite.

Uma é que "remover a aprovação do token" é específica para cada token. Revogar USDC para um gastador não faz nada para as aprovações de WETH para o mesmo gastador. O livro-razão de permissões é por contrato de token.

A outra é que as atualizações de permissões podem ter um caso de borda de condição de corrida ao mudar uma permissão não zero N para outra permissão não zero M. O padrão mais seguro é o que Speedrun Ethereumchama de "aprovar-para-zero-então-definir." A ideia é simples: defina a permissão para 0 primeiro, aguarde a confirmação, e então defina o novo valor.

Isso remove a janela onde um gastador poderia potencialmente usar tanto os valores antigos quanto os novos de permissão.

Se uma carteira ou dApp gera erros como "Aprovar para zero falhou" ou "Aprovar para novo valor falhou," geralmente não é um sinal de que revogar é impossível. É um sinal de que o comportamento de aprovação do token é peculiar ou que a interface do usuário não está lidando com as regras do token de forma clara.

A solução é usar uma ferramenta de permissão diferente ou a interface de aprovação de token de um explorador de blocos, e então tentar novamente a mesma alteração on-chain.

A estrutura chave permanece consistente: revogar é simplesmente reescrever a permissão on-chain. Se o leitor não consegue identificar o gastador que detém a permissão, a revogação não pode ser direcionada corretamente.

Revogação passo a passo usando Revoke.cash

Revoke.cash é um fluxo de trabalho comum porque exibe aprovações em um único painel e permite que o usuário envie a transação de revogação on-chain da mesma tela. Os passos abaixo refletem o fluxo dentro da carteira documentado pela Bifrost Wallet, mas a sequência é amplamente a mesma entre carteiras.

1. Abra um navegador de carteira confiável e navegue até Revoke.cash. Usar um navegador dentro da carteira reduz a chance de cair em um domínio semelhante a partir de anúncios ou DMs. 2. Conecte a carteira e selecione a rede correta. As aprovações são específicas para a cadeia, então uma aprovação do Ethereum não aparecerá quando a ferramenta estiver configurada para Flare, Base ou outra cadeia EVM. 3.

Abra a visualização de aprovações de token e classifique por risco. Comece com permissões ilimitadas e tokens com saldos significativos, já que esses são os caminhos de drenagem de maior impacto. 4. Identifique o gastador para cada linha de risco. O gastador é o contrato que pode chamar transferFrom. Se o nome do gastador parecer desconhecido, trate-o como hostil até que se prove o contrário. 5. Clique em revogar para as aprovações selecionadas.

Isso envia uma transação que define a permissão para 0 para aquele token e gastador. 6. Confirme a transação na carteira e pague o gás. Se o gás estiver alto, revogar as maiores permissões primeiro ainda é uma troca racional de "prêmio de seguro". 7. Verifique novamente a lista de aprovações após a confirmação. A permissão agora deve ser exibida como 0, ou a linha deve desaparecer dependendo da interface do usuário da ferramenta.

Esta é a resposta central sobre como revogar aprovações: o usuário não está "desvinculando" nada. O usuário está alterando a permissão no contrato do token. Se o drenador de carteirajá tem aprovação, esta é a ação que fecha o caminho.

Aprovações Permit e Permit2 para verificar

O final de 2022 é o ponto de inflexão que a maioria dos usuários perdeu.Uniswapo Roteador Universal fez do Permit2 o caminho de aprovação padrão, o que deslocou muito do 'risco de aprovação' de transações óbvias de approve() para assinaturas EIP-712.

Permit2 é um contrato de aprovação singleton da Uniswap Labs: os usuários aprovam o Permit2 uma vez por token, depois os aplicativos solicitam autorizações assinadas que incluem gastador, valor, prazo e nonce.

Isso cria dois livros contábeis paraauditar.

O primeiro livro contábil são as permissões clássicas ERC-20: token → gastador. Isso é o que a maioria dos painéis de 'aprovação de token' mostra, e é onde aprovações ilimitadas para contratos aleatórios geralmente residem.

O Ledger dois é o Permit2: token → permissão Permit2 on-chain, além das autorizações assinadas off-chain que os aplicativos solicitam. O Permit2 suporta tanto o modo de permissão contínua quanto o modo de transferência única, e suas autorizações têm prazos. Os prazos podem reduzir a exposição a permissões inativas porque as autorizações podem expirar automaticamente, mas não resolvem o roubo de assinatura.

Campanhas de phishing de aprovação visam cada vez mais os prompts de assinatura de permissão e Permit2 porque uma única mensagem assinada pode ser suficiente para mover fundos.

A implicação prática é desconfortável, mas clara: “Não me lembro de ter aprovado nada” não é um sinal de segurança. Um usuário pode estar exposto após assinar dados digitados que nunca pareceram uma transação approve() em seu histórico.

Ao fazer a limpeza após um susto, a auditoria deve responder a uma pergunta por token: qual contrato pode atualmente causar um transferFrom deste token desta carteira? Às vezes, é um gastador direto. Às vezes, é o Permit2 porque o token está aprovado para o singleton e o usuário continua assinando prompts cegamente.

O hábito que previne incidentes repetidos é o mesmo abordado em como verificar uma transação antes de assinar: trate cada solicitação de assinatura como autoridade de gasto até que se prove o contrário.

Lista de verificação de prevenção após revogar

Depois que as transações de revogação forem confirmadas, o objetivo é parar de recriar a mesma exposição na próxima vez que uma interface de swap, bridge ou staking pedir permissão. A postura limpa é tratar as aprovações como dimensionamento de posição: o limite deve corresponder à ação pretendida, não ao máximo possível.

1. Prefira aprovações de valor exato quando a interface permitir. Aprovações ilimitadas são convenientes, mas também são o modo de falha de maior impacto se o gastador estiver comprometido. 2. Se uma permissão precisar ser alterada de um valor não zero para outro, use “aprovar-para-zero-então-definir”. É um pequeno hábito operacional que reduz um risco conhecido de condição de corrida. 3.

Revise aprovações periodicamente com um rastreador de permissões. Ferramentas mencionadas nas orientações de segurança do usuário incluem Etherscan Token Approvals, Revoke.cash, Debank e Unrekt. 4. Trate os prompts de Permit e Permit2 como momentos de alto risco. O Permit2 usa assinaturas EIP-712 com prazos e nonces, mas o phishing de assinatura ainda é a principal maneira de os usuários serem drenados. 5.

Mantenha o modelo “dois ledgers” na mesa: permissões clássicas e Permit2. Revogar um gastador aleatório não ajuda se o token ainda estiver aprovado para o Permit2 e a carteira continuar assinando autorizações de um site não verificado.

É aqui que a disciplina mais ampla de golpes em carteiras de criptomoedas e como evitá-los se torna operacional: reduzir permissões permanentes, verificar o que está sendo assinado e pagar o gás para fechar linhas antigas quando elas deixarem de ser úteis.

A Conclusão

Eu vi pessoas fazerem a versão cara dessa limpeza: desconectam um site em sua carteira, se sentem seguras e depois são atingidas novamente porque a permissão no contrato do token nunca mudou. A única pergunta que importa é se um gastador ainda pode chamar transferFrom naquele token. Se a resposta for “sim”, o caminho de drenagem ainda está aberto.

O hábito que mantém isso barato é tratar as aprovações como linhas de margem. Dimensione-as para a negociação e, quando algo parecer errado, revogue as ilimitadas primeiro, mesmo que o gás esteja feio. Se o Permit2 estiver no fluxo desde o final de 2022, o segundo hábito é recusar assinar prompts EIP-712 que você não pode ler. É onde o phishing de aprovação vive agora.

Fontes

• Speedrun Ethereum
• Suporte para Bifrost Wallet
• Suporte Ecológico