Em 1993, os criptógrafos o chamaram de "o ataque mais simples do mundo": pegar uma mensagem válida, esperar e enviá-la novamente. Ninguém constrói um cofre esperando que a chave seja reutilizada.
Mas foi exatamente isso que aconteceu quando o Ethereum e o Ethereum Classic se separaram: a mesma transação assinada, transmitida em duas blockchains, movimentou fundos reais duas vezes. Sem hackers, sem senhas roubadas, sem links de phishing.
Um ataque repetitivo, fazendo o que sempre fez: usar a legitimidade como arma.
Junte-se à UEEx
Experimente a plataforma líder mundial em gestão de patrimônio digital
O que é um ataque de repetição (ou ataque de repetição)?
Um ataque de repetição é um tipo de violação de segurança de rede em que um invasor intercepta transmissões de dados válidas e as reutiliza ou reenvia maliciosamente para enganar um sistema.
Ao contrário de ataques que alteram ou falsificam dados, um ataque de repetição simplesmente retransmite informações capturadas anteriormente, como credenciais de login, tokens de autenticação ou solicitações de transação, para enganar um sistema, fazendo-o acreditar que está recebendo um comando novo e legítimo.
Atenção: Um ataque de repetição (ou ataque de repetição) pode ocorrer na mesma cadeia ou em cadeias diferentes.
Qual a diferença entre um ataque de repetição na mesma cadeia e um ataque de repetição entre cadeias diferentes?
Um ataque de repetição na mesma cadeia ocorre dentro de uma mesma blockchain: a mesma transação ou mensagem assinada é submetida várias vezes à mesma rede.
O mecanismo nonce impede isso em transações padrão do Ethereum; uma vez que um nonce (número usado uma vez) é consumido, a mesma transação é rejeitada.
Os ataques de repetição entre cadeias ocorrem entre duas blockchains que compartilham formatos de endereço e lógica de assinatura — mais comumente após um hard fork.
O nonce (número usado uma única vez) não ajuda neste caso, porque as duas blockchains rastreiam nonces de forma independente. Uma transação com nonce 5 no Ethereum e uma transação com nonce 5 no Ethereum Classic são registros diferentes em sistemas diferentes, mas os dados da transação assinada são idênticos.
O ID de cadeia do EIP-155 é a solução específica para a repetição entre cadeias. Para a verificação de assinaturas de contratos inteligentes, o separador de domínio do EIP-712 lida com variantes tanto da mesma cadeia quanto de cadeias diferentes.
Junte-se à UEEx
Experimente a plataforma líder mundial em gestão de patrimônio digital
Quando os ataques de repetição realmente aconteceram: três casos documentados
Os ataques de repetição em blockchain não são teóricos. Eles causaram perdas financeiras comprovadas em diversos casos.
A bifurcação Ethereum/Ethereum Classic — 2016
Quando a rede Ethereum se bifurcou em Ethereum (ETH) e Ethereum Classic (ETC) após o ataque ao DAO, todas as transações assinadas antes da bifurcação eram válidas em ambas as cadeias.
As duas cadeias compartilhavam espaços de endereço, formatos de transação e lógica de verificação de assinatura idênticos.
Uma transação assinada por qualquer carteira era simultaneamente uma transação válida tanto em ETH quanto em ETC.
As corretoras que detinham fundos de usuários em ETH e ETC tornaram-se alvos imediatamente.
Os atacantes interceptaram transações válidas de saque de ETH e as reproduziram na rede ETC, drenando saldos de ETC que os usuários não tinham intenção de utilizar.
Mais de 40,000 ETC foram retirados das corretoras no período posterior ao fork, antes que a proteção contra replay fosse amplamente implementada.
Esse evento motivou diretamente a criação do EIP-155.
A Fusão do Ethereum — 2022
Quando o Ethereum fez a transição de Prova de Trabalho para Prova de Participação (a Fusão), uma cadeia bifurcada chamada Ethereum foi criada. PoW (ETHW) foi criado.
Em poucos dias, um atacante explorou o contrato cross-chain da Omni Bridge, que não possuía proteção contra replay específica para ETHW, e reproduziu transações que transferiram 200 ETHW do contrato da ponte.
O atacante utilizou dados de preço do oráculo da rede principal Ethereum (mainnet) na cadeia ETHW, onde os dados estavam desatualizados e manipuláveis, como parte da exploração.
Roubo de Tokens do Optimism OP — 2022
Num incidente de repetição entre cadeias, 20 milhões de dólares em tokens OP foram roubados da Optimism durante uma sequência de transações multisig contestada.
O ataque explorou a lacuna entre os contextos das cadeias L1 (Ethereum) e L2 (Optimism), onde a reprodução de uma mensagem assinada específica na cadeia errada movimentou tokens sem autorização.
Esses não são incidentes isolados. Eles representam um padrão documentado: sempre que uma nova bifurcação ou implantação de camada 2 cria dois ambientes que compartilham formatos de endereço ou assinatura sem vinculação específica da cadeia, existe o risco de repetição.
Pense na última vez que uma nova blockchain foi lançada compartilhando seu endereço Ethereum. Você verificou se suas autorizações assinadas existentes eram válidas nessa nova blockchain? Você verificou se o esquema de assinatura da sua carteira incluía o EIP-155? A maioria das pessoas não verificou. A maioria não teve problemas. Mas aqueles que não tiveram problemas perderam fundos reais, e nenhum deles esperava que isso acontecesse.
EIP-155: A solução que se seguiu à bifurcação de 2016
A EIP-155, introduzida pelo cofundador do Ethereum, Vitalik Buterin, em 2016, foi criada especificamente para impedir que transações sejam reproduzidas em cadeias bifurcadas.
A solução era, em princípio, simples: incorporar o identificador único da cadeia (chainId) em cada assinatura de transação.
Antes da EIP-155, uma assinatura de transação abrangia seis campos de dados: nonce, preço do gás, limite de gás, endereço do destinatário, valor e dados.
A assinatura era válida em qualquer cadeia compatível com EVM usando a mesma lógica de verificação, pois nenhum desses campos identificava para qual cadeia específica a transação se destinava.
Após a EIP-155, as transações incluem três campos adicionais no hash da assinatura: chainId e dois valores de espaço reservado vazios.
Uma transação assinada por Ethereum MainNet (chainId = 1) não é uma assinatura válida em Optimism (chainId = 10), Polygon (chainId = 137) ou qualquer outra cadeia EVM.
O nó que recebe a transação verifica o chainId em relação ao seu próprio e rejeita qualquer discrepância.
Essa única alteração reduziu significativamente os ataques de repetição entre cadeias para transações padrão.
A limitação importante: A EIP-155 protege apenas as transações brutas do Ethereum.
Não protege as assinaturas em nível de aplicação, ou seja, as mensagens assinadas que os contratos inteligentes verificam internamente usando a função ecrecover.
Um contrato que valida assinaturas fora da cadeia sem verificar o chainId ainda é vulnerável a ataques de repetição, mesmo que o EIP-155 esteja totalmente implementado no nível da transação. É aí que entra o EIP-712.
O Nonce — Como ele impede a repetição na mesma cadeia
O nonce (número usado uma única vez) é o mecanismo que impede ataques de repetição dentro da mesma blockchain. Cada conta Ethereum mantém um contador que começa em 0 e incrementa em 1 a cada transação enviada.
Ao submeter uma transação com nonce = 5, a rede só a aceita se o nonce da sua conta atual for exatamente 5.
Após o processamento, o nonce da sua conta passa a ser 6, e qualquer tentativa de reproduzir a transação com nonce 5 falhará porque a rede agora espera o nonce 6.
É por isso que você não pode enviar a mesma transação Ethereum duas vezes na mesma cadeia: o nonce impede isso. A pegadinha identificada pela análise da Gate.io de março de 2026: um nonce sozinho impede a repetição na mesma cadeia, mas não a repetição entre cadeias diferentes, porque cadeias diferentes mantêm contagens de nonce separadas.
O nonce da sua conta na rede principal Ethereum e o nonce da sua conta no Ethereum Classic são rastreados independentemente.
Uma transação com nonce = 5 no Ethereum também pode ter nonce = 5 no Ethereum Classic se você tiver feito o mesmo número de transações em ambas as blockchains. A EIP-155 resolve essa lacuna ao tornar o chainId parte da própria assinatura.
Junte-se à UEEx
Experimente a plataforma líder mundial em gestão de patrimônio digital
A EIP-155 resolveu ataques de repetição em nível de transação. Ela não ajuda na verificação de assinaturas de contratos inteligentes.
Quando um contrato inteligente usa o ecrecover para validar uma assinatura fora da cadeia, ele está verificando uma mensagem, não uma transação. A proteção chainId do EIP-155 se aplica à transação Ethereum que transporta a mensagem, não ao conteúdo da mensagem em si.
Se um desenvolvedor criar um contrato que valide assinaturas sem incluir o chainId, o endereço do contrato e o nonce nos dados assinados, essas assinaturas poderão ser reproduzidas por qualquer pessoa que as intercepte.
O EIP-712 (Assinatura de Dados Estruturados Tipados) aborda essa questão. Ele define uma maneira padrão de estruturar mensagens assinadas, incluindo um separador de domínio, um hash que incorpora o chainId, o endereço do contrato verificador e o nome e a versão do contrato.
Uma assinatura criada sob o EIP-712 está vinculada a um contrato específico em um endereço específico em uma cadeia específica.
Não pode ser reproduzido em uma cadeia diferente ou em um contrato diferente, mesmo que o bytecode seja idêntico.
Para desenvolvedores: antes de implantar qualquer contrato que verifique assinaturas fora da blockchain, certifique-se de que seu esquema de assinatura inclua os três elementos: nonce (impede a reutilização da mesma mensagem), chainId (impede a repetição entre blockchains) e endereço do contrato (impede a repetição entre contratos). A biblioteca ECDSA do OpenZeppelin, versão 4.7.3 e superiores, implementa os três corretamente.
Sistemas e protocolos vulneráveis a ataques de repetição
Sistema/Protocolo Alvo
Por que é vulnerável
Exemplos e falhas comuns
Redes sem fio
A transmissão em campo aberto facilita a interceptação e o reenvio de dados.
Wi-Fi desatualizado (WEP/WPA fraco) sem sequenciamento de pacotes; dispositivos Bluetooth sem validação de nonce ou emparelhamento de sessão.
Protocolos criptográficos
Depende de chaves estáticas ou não possui verificações de atualização sensíveis ao contexto.
Kerberos ou OAuth quando os tokens de sessão ou as credenciais não possuem registros de data e hora e regras de expiração rigorosas.
Internet of Things (IoT)
Prioriza o baixo consumo de energia e a conveniência em detrimento da segurança robusta.
Fechaduras e câmeras inteligentes que utilizam protocolos de IoT (MQTT, CoAP) sem proteção contra repetição integrada devido à capacidade computacional limitada.
Sistemas de pagamento
Vulnerável se as transações não possuírem códigos de autenticação dinâmicos e de uso único.
Cartões contactless e terminais POS mais antigos que não possuem criptogramas EMV ou tokens por transação.
1. Validação de carimbo de data/hora e monitoramento de logs
Os ataques de repetição frequentemente reutilizam dados sem modificar seu registro de data e hora original.
Ao monitorar e validar os registros de data e hora, os sistemas podem detectar quando as mensagens estão inesperadamente atrasadas ou fora de um intervalo de tempo aceitável.
Implemente verificações rigorosas de validade baseadas em tempo para tokens, transações e chamadas de API.
Sinalize mensagens que parecem estar atrasadas ou processadas fora da duração normal da sessão.
Faça referência cruzada de logs do sistema para identificar solicitações com registros de data e hora idênticos que aparecem mais de uma vez.
2. Detecção de mensagens duplicadas
Uma característica fundamental dos ataques de repetição é a repetição de mensagens ou pacotes idênticos.
Os sistemas devem monitorar esses padrões, principalmente em áreas críticas como autenticação, transações financeiras e gerenciamento de sessões.
Use hashing ou impressão digital para detectar pacotes ou solicitações duplicadas.
Compare os dados recebidos com as entradas processadas recentemente para verificar se há conteúdo repetido.
Registre e investigue tokens de sessão repetidos, chamadas de API ou cargas úteis criptografadas.
3. Rastreamento de Número de Sequência e Nonce
Sistemas seguros geralmente dependem de números de sequência ou nonces (números usados uma única vez) para rastrear e validar a unicidade dos dados.
As mensagens reproduzidas geralmente reutilizam o mesmo nonce ou número de sequência, o que pode ser sinalizado.
Mantenha uma memória de curto prazo (cache ou banco de dados) de nonces ou números de sequência usados recentemente.
Descarte ou registre solicitações que contenham valores reutilizados.
Alerta sobre tokens de sessão ou identificadores de solicitação que já foram processados.
4. Detecção de Anomalias Comportamentais
Os ataques de repetição nem sempre são duplicatas técnicas; às vezes, o contexto comportamental pode revelar a ameaça.
Por exemplo, um usuário que realiza exatamente a mesma transação duas vezes em questão de segundos pode ser considerado suspeito.
Monitore o comportamento do usuário e crie perfis básicos para atividades normais.
Sinalize padrões anormais, como ações repetidas de alta frequência, solicitações idênticas de IPs diferentes ou vários logins usando o mesmo token.
Integre sistemas de detecção de anomalias que possam aprender e se adaptar a padrões típicos de tráfego.
5. Análise do tráfego de rede
Ferramentas avançadas de detecção podem analisar o tráfego de rede em tempo real para procurar padrões suspeitos, especialmente em ambientes sem fio ou IoT, onde ataques de repetição são comuns.
Use Sistemas de Detecção de Intrusão (IDS) ou Sistemas de Prevenção de Intrusão Sem Fio (WIPS) para detectar retransmissões de pacotes suspeitos.
Analise cabeçalhos de pacotes em busca de identificadores reutilizados, nonces ou parâmetros de criptografia.
Fique atento a cargas criptografadas repetitivas que não variam entre as sessões.
6. Análise do Token de Sessão e do Log de Autenticação
Ataques de repetição geralmente envolvem tokens de autenticação reutilizados. Os sistemas devem auditar e analisar os registros de emissão e uso de tokens para identificar tokens que parecem estar sendo reutilizados ou mal utilizados.
Acompanhe a vida útil dos tokens de sessão e suas informações de IP/dispositivo associadas.
O log tenta reutilizar credenciais de autenticação expiradas ou já consumidas.
Investigue tentativas de login que reutilizam cabeçalhos, metadados ou detalhes de sessão.
Qual é a diferença entre um ataque de repetição e um ataque MITM?
Um ataque de repetição envolve capturar e reenviar dados válidos para enganar um sistema, enquanto um ataque man-in-the-middle (MitM) intercepta e altera ativamente a comunicação entre duas partes em tempo real.
Quais são os tipos mais comuns de pacotes capturados em um ataque de repetição?
Os tipos mais comuns de pacotes capturados em um ataque de repetição incluem solicitações de autenticação, tokens de sessão, mensagens de transação e comandos de controle usados em comunicações sem fio ou de rede.
Como o TLS previne um ataque de repetição?
O TLS previne ataques de repetição usando chaves de sessão exclusivas, números de sequência e códigos de autenticação de mensagens (MACs) para garantir que cada mensagem seja atualizada e não possa ser reenviada ou alterada sem detecção.
O que é um ataque de repetição Kerberos?
Um ataque de repetição Kerberos ocorre quando um invasor captura e reenvia uma mensagem de autenticação Kerberos válida para enganar o sistema e fazê-lo conceder acesso não autorizado sem reautenticar.
Junte-se à UEEx
Experimente a plataforma líder mundial em gestão de patrimônio digital
Os ataques de repetição podem parecer simples, mas seu impacto pode ser grave, variando de acesso não autorizado a perdas financeiras e interrupção de serviços.
Reconhecer sistemas vulneráveis, entender como esses ataques funcionam e aplicar defesas em camadas, como nonces, timestamps e criptografia, é essencial.
Como as ameaças continuam a visar pontos fracos nos processos de verificação, a detecção e a prevenção precoces se tornam essenciais.
Fortalecer os sistemas contra ataques de repetição não se trata apenas de proteção; trata-se de garantir confiança, integridade dos dados e serviço consistente em ambientes digitais onde a segurança não pode ser comprometida.
Akindele T. Francis é uma redatora de conteúdo versátil com vasta experiência em diversos setores. Especializada em posts para blogs, conteúdo para sites, páginas de serviços, textos de vendas atraentes, etc., a Akindele colaborou com diversas agências para produzir materiais escritos envolventes e eficazes. Com um olhar atento aos detalhes e paixão por criar narrativas impactantes, a Akindele supera consistentemente as expectativas dos clientes, gerando resultados e aprimorando a mensagem da marca em diversas plataformas.
Aviso Legal: Este artigo destina-se exclusivamente a fins informativos e não deve ser considerado aconselhamento sobre negociação ou investimento. Nada aqui contido deve ser interpretado como aconselhamento financeiro, jurídico ou tributário. Negociar ou investir em criptomoedas acarreta um risco considerável de perdas financeiras. Sempre realize a devida diligência antes de tomar qualquer decisão de negociação ou investimento.
