Explicação dos ataques do Sweeper Bot EIP-7702
A atualização Pectra do Ethereum trouxe a revolução do EIP-7702, mas também armou os hackers com a arma definitiva: robôs varredores financiados por patrocinadores que drenam carteiras comprometidas sem precisar de gás nativo.
Ataques de bots varredores EIP-7702: quão comprometidos Carteiras Esvazie-se quando o gás chegar instantaneamente
- A chegada do hard fork Pectra da Ethereum representa um dos pontos de viragem mais críticos na história da arquitetura de contas descentralizadas. No centro deste salto programático está a EIP-7702, uma proposta concebida para resolver o atrito de longa data entre as Contas de Propriedade Externa (EOAs), as carteiras padrão controladas por chave privada utilizadas pela grande maioria dos utilizadores retalhistas, e Contrato Inteligente Contas (CAs).
- Ao permitir que um EOA padrão adote temporária ou persistentemente os comportamentos de um contrato inteligente Carteira , EIP-7702 traz utilidade avançada, como lote de transações, patrocínio de gás e lógica de recuperação personalizada, diretamente para o cenário de carteira existente.
- No entanto, no ecossistema adversário das blockchains públicas, cada avanço tecnológico inevitavelmente expande o playground para atores mal-intencionados. Enquanto os desenvolvedores da Web3 comemoram a democratização da abstração de contas, os círculos de segurança de chapéu preto se adaptaram silenciosamente. A integração do EIP-7702 armou os golpistas com uma ferramenta altamente perigosa: o robô varredor financiado por patrocinadores.
- Historicamente, uma carteira cujas chaves privadas foram vazadas teria grandes chances de recuperação se não contivesse nenhum token de gás nativo (como ETH). As equipes de segurança poderiam coordenar resgates de transações privadas antes que o script de monitoramento automatizado de um hacker pudesse antecipar o depósito das taxas de gás. Sob o EIP-7702, toda esta estrutura defensiva foi completamente desmantelada.
1. O Gênese: Reduzindo a divisão entre contas EOA e contas inteligentes
- Para entender por que o EIP-7702 representa uma mudança tão grande na mecânica dos robôs varredores, devemos primeiro traçar o pipeline evolutivo da abstração de contas. Durante anos, a comunidade Ethereum lutou com as limitações dos EOAs padrão. Um EOA é uma entidade monolítica: depende estritamente de um par de chaves do Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA) para autorizar transações. Essa arquitetura introduz atrito substancial, particularmente o problema de inicialização de gás, fragilidade de assinatura única e falta de lotes atômicos.
- Um EOA totalmente novo não pode executar nenhuma ação na cadeia até que seja financiado com tokens de gás nativos, criando um grave obstáculo de integração. Além disso, se a chave privada de uma EOA for perdida ou roubada, a conta fica permanentemente comprometida; não há mecanismo de recuperação nativo ou opção multisig sem transferir os fundos para um contrato separado. Além disso, a execução de uma exchange descentralizada básica (DeFi) o swap requer duas transações distintas e sequenciais: uma transação inicial de aprovação ERC-20 seguida pela execução real do swap. Isso custa gás extra e degrada a experiência do usuário.
O caminho para a abstração de contas
- A primeira grande tentativa estrutural para resolver essas limitações foi a ERC-4337. Este padrão introduziu um mempool de transações fora da cadeia completamente separado, onde os usuários podiam enviar operações de usuários para empacotadores descentralizados. Esses empacotadores empacotariam múltiplas operações em uma única transação Ethereum padrão, encaminhando-as através de um contrato EntryPoint central para executar a lógica de carteira de contrato inteligente.
- Embora o ERC-4337 tenha conseguido provar a viabilidade da abstração de contas, ele sofreu de duas limitações principais: exigiu que os usuários migrassem seus ativos inteiramente de seus EOAs existentes para contas de contratos inteligentes totalmente novas e introduziu custos de gás mais elevados devido às complexas camadas de execução de contratos inteligentes.
- Para contornar o obstáculo da migração, os desenvolvedores propuseram o EIP-3074. Esta proposta introduziu dois novos opcodes EVM que permitiram a uma EOA delegar a sua autoridade a um contrato invocador externo, permitindo ao invocador realizar transações em nome da EOA. No entanto, os auditores de segurança rapidamente sinalizaram vulnerabilidades graves: um único contrato de invocador comprometido ou malicioso poderia obter controle ilimitado e permanente sobre qualquer EOA que o autorizasse, abrindo um vetor devastador para ataques de phishing.
O compromisso final
- Em resposta a essas preocupações de segurança, Vitalik Buterin formulou o EIP-7702. Em vez de introduzir opcodes de delegação brutos de baixo nível, o EIP-7702 introduz um tipo de transação especializado que permite que um EOA defina temporária ou persistentemente seu próprio slot de código para apontar para um contrato externo. Quando uma transação EIP-7702 é executada, o EOA especifica uma lista de autorizações.
- Para cada entrada nesta lista, o EVM escreve temporariamente um prefixo de designação de delegação diretamente no slot de código do EOA. Esta designação diz ao EVM para rotear todas as chamadas de contrato subsequentes direcionadas a esse EOA diretamente para a lógica de implementação do contrato delegado especificado. Este mecanismo permite que EOAs padrão herdem instantaneamente todos os recursos das contas inteligentes (incluindo patrocínio de gás, controles multi-sig e processamento em lote de transações), mantendo a compatibilidade retroativa total e deixando um caminho claro para reverter a delegação, apontando a conta de volta para o endereço nulo.
2. O Velho Paradigma: Como Operavam os Sweeper Bots Clássicos
- Para apreciar plenamente como o EIP-7702 otimizou a eficiência dos bots sweeper maliciosos, devemos analisar as limitações estruturais do cenário de bots sweeper pré-Pectra. Historicamente, quando a chave privada ou a frase inicial de recuperação de um usuário era comprometida, o invasor implantava imediatamente um robô varredor: um script automatizado executado em um nó RPC de alta velocidade que verificava continuamente o mempool público em busca de quaisquer transações recebidas direcionadas ao endereço da carteira comprometida.
- O clássico robô varredor operava sob uma restrição rígida: cada transação de mudança de estado na rede Ethereum requer a execução de gás nativo. Se a carteira comprometida contivesse tokens ERC-20 de alto valor ou NFTs valiosos, mas não contivesse gás nativo, o bot varredor do invasor ficaria temporariamente paralisado. O bot não conseguiu mover os tokens porque não havia gás dentro da carteira comprometida para pagar aos validadores pela transação de transferência.
Consequentemente, o robô varredor teve que esperar que a vítima ou uma equipe de resgate de chapéu branco depositasse ETH nativo na carteira comprometida para facilitar a recuperação, ou que a vítima tentasse executar uma transação diretamente.
- No momento em que o robô varredor detectou uma transação pendente depositando ETH no endereço comprometido, ele calculou a taxa de gás exata necessária para executar quaisquer transações de resgate subsequentes. Usando leilões prioritários de gás ou encaminhando transações diretamente para construtores de blocos públicos, o robô varredor enviaria instantaneamente uma transação de transferência com um preço de gás extremamente alto. A transação do bot seria empacotada no topo do próximo bloco, varrendo com sucesso os ativos da vítima e deixando a transação de resgate recebida falhar devido à falta de tokens restantes.
A escotilha de fuga do chapéu branco: Flashbots e MEV-Share
- Essa exigência de gás criou um nicho altamente especializado para operações de resgate de chapéu branco. Quando um usuário percebesse que a chave de sua carteira havia vazado, ele poderia entrar em contato com especialistas em segurança para coordenar um resgate de Flashbots. Como os mempools públicos são fortemente monitorados por robôs hackers, os socorristas usaram endpoints RPC privados para contornar totalmente o mempool público.
- Usando ferramentas como Flashbots ou MEV-Share, as equipes de resgate construiriam um pacote de transações atômicas contendo duas etapas distintas. Primeiro, uma carteira externa segura de propriedade da equipe de resgate enviaria a quantidade exata de ETH necessária para o gás para a carteira comprometida. Em segundo lugar, a carteira comprometida transferiria imediatamente os seus valiosos tokens ERC-20 ou NFTs para um endereço de destino seguro, utilizando o ETH recém-depositado para cobrir o gás.
- Como essas duas transações foram agrupadas e enviadas diretamente para construtores de blocos cooperativos, foi garantido que elas seriam executadas exatamente no mesmo bloco, uma após a outra, sem espaço para a intervenção de um robô varredor externo. O público nunca viu o depósito de gás recebido até que o bloco já estivesse extraído e finalizado, resgatando com sucesso milhões de dólares em riqueza digital.
3. Sweeper Bot: Desvendando a exploração de patrocínio
- A integração do EIP-7702 desmantelou completamente as garantias de segurança do clássico pacote de resgate Flashbots ao introduzir o patrocínio de gás. De acordo com o EIP-7702, uma transação pode ser enviada por um terceiro (conhecido como retransmissor ou patrocinador) que paga as taxas de gás em nome da EOA alvo. Essa única modificação eliminou o maior gargalo do robô varredor clássico: a necessidade da carteira da vítima armazenar o gás nativo.
- Quando um invasor obtém acesso a uma chave privada comprometida na era pós-Pectra, ele não precisa mais implantar um script passivo que aguarde um depósito de ETH recebido. Em vez disso, o invasor pode configurar seu robô varredor para atuar como seu próprio patrocinador de gás. O bot constrói uma transação EIP-7702 contendo uma carga útil de autorização assinada pelo EOA comprometido. Essa carga atualiza temporariamente o EOA da vítima para uma carteira de contrato inteligente que contém uma rotina de transferência em lote.
- O invasor então transmite essa transação de sua própria carteira externa totalmente financiada. Como a carteira do invasor é a origem da transação, as taxas do gás são deduzidas diretamente do saldo do invasor. O EVM processa a transação, instala temporariamente a lógica de transferência personalizada no EOA da vítima e executa instantaneamente uma transferência em lote de todos os tokens ERC-20 e NFTs para o endereço seguro do invasor: tudo em uma única etapa atômica paga pelo patrocinador. A carteira da vítima fica completamente esgotada, sem nunca conter uma única gota de ETH nativo.
Os dois principais vetores de ataque
Esta nova classe de ataques de bots sweeper opera através de dois vetores de entrada distintos:
A chave privada comprometida: Se um hacker roubar uma frase-semente ou chave privada por meio de um arquivo de configuração vazado, um backup em nuvem comprometido ou malware da área de transferência, ele detém a autoridade final para assinar qualquer carga útil. Em vez de esperar pelo gás, o bot varredor do invasor assina imediatamente uma carga de autorização EIP-7702 em nome da vítima. O bot então envia a transação, paga o gás e limpa a conta instantaneamente. As equipes de resgate de chapéu branco não podem realizar um resgate clássico de Flashbots porque não há nenhuma etapa de financiamento a ser agrupada; o invasor pode iniciar a varredura a qualquer momento de sua escolha, de forma totalmente independente das ações da vítima.
Assinatura da delegação de phishing: O segundo vetor, ainda mais insidioso, não exige que o invasor roube a chave privada da vítima. Em vez disso, depende de interfaces de phishing enganosas. Quando um usuário visita um site malicioso (disfarçado como uma declaração de lançamento aéreo ou um painel de otimização de portfólio), o dApp solicita que ele assine uma mensagem fora da cadeia. Para o olho destreinado, isso parece uma assinatura padrão e inofensiva. Na realidade, o usuário está assinando uma tupla de autorização EIP-7702.
- Assim que esta assinatura for capturada, a delegação estará completa. O invasor agora possui uma carga criptograficamente válida que permite atualizar o EOA da vítima para apontar para um contrato de implementação malicioso a qualquer momento. Como as transações EIP-7702 podem ser enviadas por qualquer pessoa, o invasor pode manter essa assinatura em reserva, aguardando semanas ou meses até que a vítima deposite uma quantidade significativa de ativos em sua carteira.
- No instante em que um ativo de alto valor chega, o robô varredor do invasor envia a lista de autorização à rede, atualiza o EOA e drena os ativos usando seu próprio gás patrocinado.
Tabela 1: Modelos de Varredora
| Sistema | Requisito de gás |
| Varredora antiga | Precisa de ETH da vítima |
| Nova varredora | Usa gás atacante |
4. Fluxo de execução em nível EVM e modificações de estado
- Para entender como o EIP-7702 altera o comportamento central da Máquina Virtual Ethereum, devemos observar as regras exatas de mudança de estado introduzidas por este tipo de transação. O EIP-7702 introduz um novo tipo de transação, formalmente designado por um wrapper especializado. A carga útil de uma transação EIP-7702 inclui uma estrutura de transação padrão junto com uma adição crítica: a lista de autorizações.
- A lista de autorização é representada como uma lista de tuplas serializadas contendo parâmetros como o identificador da cadeia, o endereço do contrato inteligente alvo, o nonce da conta e os componentes de assinatura (paridade y, r e s) gerados pela chave privada do EOA.
- O identificador de cadeia especifica a rede exata para evitar cadeia cruzada ataques de repetição. O endereço indica a implementação alvo do contrato inteligente à qual o signatário deseja delegar sua conta. O nonce rastreia a contagem atual de transações do EOA do signatário para evitar a reutilização de assinatura ou execução fora de ordem. Finalmente, os componentes de assinatura são gerados assinando o hash dos dados de autorização.
O Processo de Transição de Estado
Quando uma transação EIP-7702 é empacotada em um bloco, o EVM processa a lista de autorizações antes de executar qualquer carga útil da transação. Para cada tupla válida na lista, o EVM realiza diversas operações:
Recuperação de assinatura: O EVM usa o algoritmo de recuperação de assinatura padrão para derivar a chave pública e identificar o endereço da autoridade de assinatura.
Verificação de Nonce: O EVM verifica se o nonce on-chain do signatário corresponde ao nonce especificado na tupla. Se o nonce on-chain for maior, a autorização é descartada como inválida.
Escrevendo o Designador da Delegação: Se a verificação for bem-sucedida, o EVM modifica o estado da conta de autoridade. Ele grava os bytes designadores de delegação diretamente no slot de código da conta. Este prefixo especial instrui o EVM que a conta não é mais um EOA padrão para fins de execução. Todas as futuras chamadas externas direcionadas ao endereço de autoridade redirecionarão imediatamente seu contexto de execução para o código residente no endereço delegado.
Incrementando o Nonce: O nonce on-chain da conta de autoridade é incrementado em um para evitar que exatamente a mesma carga útil de autorização seja executada novamente.
5. A destruição da compatibilidade com versões anteriores: a falácia somente EOA
- Além da ameaça imediata de robôs varredores patrocinados, o EIP-7702 introduz um risco sistêmico para o ecossistema mais amplo de contratos inteligentes ao quebrar uma suposição fundamental da segurança do Ethereum: a verificação somente EOA. Por quase uma década, os desenvolvedores de contratos inteligentes utilizaram uma verificação de segurança comum e específica para verificar se uma chamada recebida é originada de um usuário padrão ou de outro contrato inteligente.
- Historicamente, esta verificação foi considerada uma salvaguarda confiável. Como as transações padrão do Ethereum só podiam ser iniciadas por um EOA, a verificação de que o chamador imediato correspondia ao iniciador original da transação garantia que o chamador não era um contrato inteligente.
- Essa suposição foi amplamente usada para defesa contra diversas vulnerabilidades críticas, como explorações de empréstimos instantâneos (impedindo que contratos inteligentes interajam com as funções de um protocolo durante um único bloco de transação para neutralizar ataques de levantamento de capital) e ataques de reentrada (garantindo que a conta chamadora não pudesse executar funções de fallback maliciosas para sequestrar loops de execução).
O Subversão EIP-7702
- EIP-7702 invalida completamente esta verificação. Como um EOA agora pode delegar seu slot de código para apontar para um contrato externo, um EOA pode se comportar exatamente como um contrato inteligente, permanecendo ainda como o iniciador da transação. Quando um EOA delegado interage com um protocolo, o chamador e a origem da transação ainda corresponderão, mas o slot de código do EOA contém bytecode ativo e executável que pode executar lógica maliciosa personalizada.
- Um exemplo proeminente do mundo real dessa vulnerabilidade ocorreu na cadeia BNB. Um invasor identificou um contrato DeFi não verificado que dependia apenas da verificação EOA para restringir o acesso ao seu pool de liquidez interno. O invasor implantou um contrato de delegação malicioso, assinou uma carga útil de autorização EIP-7702 em seu próprio EOA e iniciou uma transação.
- Como o EOA carregava código delegado, ele contornou com êxito a verificação somente EOA do contrato. Quando o protocolo transferiu tokens nativos para o EOA, ele acionou instantaneamente a função de fallback do contrato delegado, permitindo ao invasor executar uma exploração de reentrada recursiva e drenar o protocolo.
Tabela 2: Técnicas de recuperação
| Método | Mecanismo |
| Resgate Antigo | Pacotes de mempool privados |
| Novo resgate | Redefinição de endereço zero |
6. Operações defensivas: substituição e eliminação de delegações mal-intencionadas
- Se você descobrir que sua carteira foi comprometida por meio de uma assinatura de delegação EIP-7702 maliciosa, as medidas de segurança tradicionais, como a revogação das permissões de token ERC-20, não serão mais suficientes. Como o ponteiro de delegação dá ao invasor controle de execução permanente sobre seu EOA, você deve limpar ativamente a delegação para recuperar a segurança da sua conta.
Felizmente, os arquitetos do EIP-7702 construíram um mecanismo nativo para redefinir o slot de código de um EOA: delegação para o endereço zero.
- Quando um EOA autoriza uma delegação apontando para o endereço zero, o EVM intercepta isso como um comando especial. Em vez de escrever um prefixo de delegação, o EVM limpa completamente o slot de código da conta e redefine seu hash de código de volta ao estado vazio padrão. Esta ação restaura instantaneamente a carteira para um EOA padrão e limpo, cortando o controle de execução do invasor.
Manual de recuperação: executando uma limpeza patrocinada
Como uma carteira comprometida é provavelmente monitorada por um robô varredor ativo, tentar financiar a carteira com ETH para limpar a delegação é extremamente arriscado. Para recuperar a conta com segurança, você deve executar uma limpeza financiada pelo patrocinador usando um endereço secundário seguro para pagar as taxas de gás.
Etapa 1: Isole o EOA comprometido. Pare de depositar quaisquer ativos ou executar quaisquer transações da carteira comprometida. Certifique-se de ter uma carteira secundária segura (com ETH suficiente para pagar o gás) para atuar como seu patrocinador ou retransmissor.
Etapa 2: Gere a carga útil de redefinição. Elabore uma carga útil de autorização EIP-7702 onde o campo de endereço de destino é definido como o endereço zero. A carga útil deve fazer referência ao nonce atual na cadeia do EOA comprometido. Assine esta carga usando a chave privada do EOA comprometido.
Passo 3: Transmissão através da Carteira do Patrocinador. Usando uma ferramenta de desenvolvedor de linha de comando ou uma estrutura de desenvolvedor verificada, empacote a carga de autorização assinada em uma transação EIP-7702. Configure os parâmetros da transação para deduzir as taxas do gás diretamente da sua carteira segura do patrocinador secundário. Transmita a transação para a rede.
Etapa 4: Verifique a redefinição do estado. Assim que a transação for minerada, o EVM incrementará o nonce do EOA comprometido e limpará completamente o ponteiro de delegação de seu slot de código. Você pode verificar a redefinição executando uma verificação de saldo e código no endereço usando uma ferramenta de linha de comando de desenvolvimento.
7. Telemetria em tempo real e segurança on-chain via DEXTools
- No ecossistema pós-Pectra altamente fragmentado, onde rollups modulares, tokens de gás personalizados e contas de contratos inteligentes delegadas estão se expandindo rapidamente, manter visibilidade absoluta sobre seus ativos é uma necessidade. Quando os usuários interagem com novos protocolos DeFi, pools de rendimento ou estruturas de reestabelecimento líquido, eles são rotineiramente solicitados a assinar transações que podem, se maliciosas, conter cargas úteis de autorização EIP-7702 ocultas.
- Para proteger seu portfólio dessas táticas avançadas de phishing, você deve praticar a verificação proativa na rede. Depender de alertas básicos do navegador não é mais suficiente; você precisa de dados em tempo real para auditar a segurança dos pools e contratos inteligentes com os quais você interage.
- DEXTools fornece a infraestrutura analítica crítica necessária para realizar essas verificações antes de autorizar qualquer assinatura em sua carteira. Ao inserir o endereço do contrato de qualquer token diretamente no avançado Explorador de pares DEXTools, você pode monitorar instantaneamente históricos de transações ao vivo, analisar o status de verificação do código-fonte do contrato, verificar bloqueios de pool de liquidez e auditar pontuações gerais de confiança de segurança.
- Essa telemetria transparente garante que você interaja apenas com protocolos verificados e de alta integridade, mantendo seus ativos digitais protegidos das armadilhas pré-calculadas das redes drenadoras modernas.
Você pode acessar DEXTools aqui e comece a negociar hoje!
Isenção de responsabilidade: Este artigo é apenas para fins informativos e não constitui aconselhamento de investimento, aconselhamento financeiro, aconselhamento comercial ou qualquer outro tipo de aconselhamento. DEXTools não recomenda comprar, vender ou manter qualquer criptomoeda ou token. Os usuários devem realizar suas próprias pesquisas e consultar um consultor financeiro qualificado antes de tomar qualquer decisão de investimento. Os investimentos em criptomoedas são voláteis e de alto risco. DEXTools não é responsável por quaisquer perdas incorridas.