Ir para o conteúdo
Financial Context Wiki

Envenenamento de endereço

O envenenamento de endereço insere um destinatário parecido no histórico de transações ou em outra interface aparentemente confiável para que um pagamento posterior seja copiado para o invasor; ele explora a verificação do destinatário, sem alterar o endereço real nem roubar sua chave.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

O envenenamento de endereço é uma fraude de substituição do destinatário. O invasor gera outro endereço cujo prefixo e sufixo visíveis se parecem com os de um destinatário confiável e o insere no histórico de transações ou em outra interface aparentemente confiável. Ele espera que um remetente copie depois esse endereço parecido e assine um pagamento válido para ele. O ataque não altera o endereço legítimo, não viola sua chave privada nem faz o consenso desviar a transferência.

O registro inserido pode resultar de uma transação real de ativo nativo, de uma transferência de token de valor zero compatível com o padrão ou de um log emitido por outro contrato de token. As páginas de atividade de wallets e exploradores são visualizações derivadas: uma linha rotulada como “enviado” pode vir de campos de eventos, não de uma transação externa assinada pelo endereço from exibido. Verifique separadamente remetente e destino da transação externa, contrato chamado, contrato emissor do evento, campos indexados e mudanças reais de saldo.

O checksum ERC-55 ajuda a detectar alguns erros acidentais de digitação, mas outro endereço do invasor pode ser sintaticamente válido e ter checksum correto. Endereços EVM comuns de 20 bytes também não identificam por si sós a chain pretendida, o ativo, a função do destinatário, o memo de depósito nem a chamada ao contrato. Uma instrução de pagamento segura vincula todos esses fatos ao destino completo.

Envenenamento de endereço
0 / 5
0 itens revisados; 5 itens ainda não resolvidos

A conclusão desta revisão não prova que um ativo, transação ou sistema seja seguro.

Como funciona

O invasor observa um padrão público de pagamentos e busca um vanity address que corresponda aos caracteres que a wallet exibe de forma truncada. Fazer alguns caracteres hexadecimais coincidirem não clona uma conta: os bytes ocultos continuam diferentes e o invasor controla a nova chave. Uma transferência minúscula pode inserir esse endereço real no histórico. Separadamente, o ERC-20 exige que transferências de valor zero sejam tratadas como transferências normais e emitam Transfer; portanto, um registro de valor zero não comprova, por si só, falsificação, comprometimento, autorização nem perda econômica.

Um contrato de token malicioso também pode emitir seu próprio log Transfer(victim, lookalike, 0). Esse log é um dado real do recibo atribuível ao contrato emissor, mas não é um evento do contrato canônico do ativo nem comprova que a vítima assinou a transação externa. Ainda assim, um indexador que classifique atividade por topics de eventos sem contexto suficiente do contrato e da chamada pode apresentar uma linha de saída enganosa.

O controle decisivo é a intenção final do pagamento. Ela deve vincular chain e rede, ativo nativo ou contrato exato do token, endereço completo e tipo do destinatário, valor e unidades raw, além de qualquer calldata, memo, destination tag ou período de validade. Endereços de depósito de exchanges, bridges, proxies e rotas de uso único podem ficar obsoletos ou exigir mais que um endereço. Malware de área de transferência e códigos QR comprometidos são ataques distintos, mas a mesma verificação do destino completo detecta a substituição antes da assinatura.

Nomes e pagamentos de teste são controles auxiliares, não provas de identidade. Resolva um nome ENS para a chain e o registro pretendidos no momento da assinatura; se um nome reverso for exibido, faça a resolução direta de volta ao mesmo endereço. Um pequeno teste só ajuda quando o destinatário o confirma de forma independente e o pagamento principal reutiliza o mesmo destino fixado. Copiar novamente do histórico descarta essa proteção.

Use este fluxo de trabalho:

  1. Fixe chain, rede, ativo e contrato exato do token, tipo de destinatário, formato do endereço, valor e qualquer memo, tag, calldata, versão ou expiração com base em uma fonte independente autenticada.
  2. Resolva uma vez o nome ou QR, valide formato e checksum e vincule os bytes completos do destino à chain pretendida; confirme diretamente qualquer nome reverso em vez de tratar o rótulo como identidade.
  3. Compare o destino com uma allowlist controlada, catálogo de endereços ou fatura assinada, nunca com o histórico; exija aprovação independente ou dupla para destinatário novo ou alterado de forma relevante.
  4. Decodifique a transação exata ainda não assinada: diferencie o to nativo de um contrato de token ou bridge e inspecione na calldata destinatário, token, valor raw, aprovação, deadline e semântica do destino.
  5. Quando apropriado, envie um pequeno teste ao destino fixado e obtenha confirmação independente do destinatário; não copie novamente um endereço do histórico para o pagamento principal.
  6. Assine a transferência principal apenas a partir do registro verificado, compare destino e valor completos em uma tela confiável e depois confira recibo, contrato emissor, logs e variações de saldo na chain correta.
  7. Se houver suspeita de envenenamento ou envio incorreto, interrompa pagamentos posteriores, preserve hashes e evidências e contate prontamente o serviço destinatário, emissor ou autoridades quando pertinente; trate congelamento, devolução e recuperação como condicionais, nunca garantidos.

Exemplos

  • O truncamento oculta a diferença. O endereço legítimo 0x12ab1111111111111111111111111111111189ef e o do invasor 0x12ab9999999999999999999999999999999989ef aparecem ambos como 0x12ab...89ef. Eles compartilham 4 + 4 = 8 caracteres hexadecimais exibidos, mas diferem em todos os 32 caracteres centrais. Comparar só as extremidades renderizadas produz uma falsa correspondência; comparar todos os bytes, não.
  • Trabalho da busca vanity. Fazer corresponder k = 8 caracteres hexadecimais escolhidos exige trabalho esperado de 16^8 = 4,294,967,296 candidatos. A uma velocidade hipotética de 50,000,000 candidates/s, o tempo esperado é 4,294,967,296 / 50,000,000 = 85.89934592 s. Isso ilustra um espaço de busca, não um tempo de execução prometido nem um limite de alerta da wallet.
  • Log versus estado. Um contrato de token emite Transfer(victim, lookalike, 0). O saldo da vítima passa de 250,000.000000 para 250,000.000000, portanto a variação é 0.000000; um índice de atividade ainda pode exibir uma linha de transferência. Confira o contrato emissor e a autorização da chamada: a linha isolada não comprova movimentação de valor nem assinatura da vítima.
  • Um teste deve fixar o destino. Uma tesouraria planeja 50,000 USDC, envia 1 USDC a um endereço verificado, recebe confirmação independente e envia 49,999 USDC usando o mesmo registro fixado: 1 + 49,999 = 50,000 USDC. Se a equipe copiar novamente um endereço parecido do histórico para a segunda etapa, o teste deixa de proteger o pagamento de 49,999 USDC.

Riscos

  • O remetente copia um endereço parecido de um histórico envenenado.
  • Uma interface truncada oculta os caracteres centrais diferentes.
  • Um prefixo ou sufixo vanity é confundido com identidade do destinatário.
  • Uma transferência ERC-20 de valor zero cria uma linha de histórico enganosa.
  • Um token falsificado ou seu log é confundido com atividade do ativo canônico.
  • Um indexador classifica mal campos de eventos ou os corrige tarde demais.
  • Nome, símbolo ou ícone de token spam imita um ativo confiável.
  • Malware da área de transferência substitui um endereço verificado antes da assinatura.
  • Um catálogo de endereços local ou sincronizado está envenenado ou obsoleto.
  • Uma allowlist vincula chain, ativo, função ou versão do endereço incorretos.
  • Um aviso de checksum inválido ou ausente é ignorado.
  • Um checksum válido é confundido com prova de identidade do destinatário.
  • A resolução ENS muda, usa o coin type errado ou fica obsoleta.
  • Um nome reverso é exibido sem confirmação por resolução direta.
  • Após um teste, o endereço é copiado novamente de uma fonte não confiável.
  • O endereço de depósito, rede, memo ou tag de um exchange está errado ou expirado.
  • O destino e a calldata exigida por bridge, proxy ou contrato são mal interpretados.
  • O signatário verifica apenas texto truncado, até mesmo em dispositivo de hardware.
  • Uma transferência ao destinatário errado se torna canônica antes da intervenção.
  • A vítima depende do congelamento discricionário pelo emissor ou de um golpe de recuperação.

Equívocos comuns

  • Envenenamento de endereço significa que wallet, chave ou blockchain foi invadida. O ataque comum explora a seleção do destinatário enquanto criptografia e consenso válidos executam a intenção assinada errada.
  • Uma linha de valor zero deve ser uma transação on-chain falsa. Transferências compatíveis e logs reais podem ter valor zero; inspecione sua origem e efeito no estado.
  • Extremidades iguais mais checksum comprovam o destinatário. Outro endereço válido pode corresponder aos caracteres visíveis e ter seu próprio checksum válido.
  • Um teste bem-sucedido protege automaticamente a próxima transferência. A proteção se perde se o pagamento principal não reutilizar o destino fixado e confirmado.
  • Wallet, validador ou emissor do token sempre pode reverter o pagamento. Poderes e cooperação para recuperação dependem de ativo, serviço, jurisdição, evidências e tempo.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...