Envenenamento de endereço: o ataque que só precisa que você copie a coisa errada
Quase todo ataque a usuários de cripto precisa que você cometa um erro: clicar num link, digitar uma frase-semente num formulário, aprovar algo que não leu. O envenenamento de endereço precisa de menos que isso. Precisa que você copie um endereço do seu próprio histórico de transações.
Não há malware, nem site de phishing, nem assinatura a ser arrancada de você. A contribuição inteira do atacante é deixar uma sequência de aparência plausível num lugar onde você mais tarde vai buscá-la.
Como funciona
Comece pelo que torna isso possível: ninguém lê endereços. Um endereço de Bitcoin ou Ethereum são trinta e tantos caracteres de base58 ou hexadecimal sem significado, sem soma de verificação que dê para julgar a olho e sem razão nenhuma para guardar na cabeça. Então toda carteira, explorador de blocos e corretora os encurta na exibição — 0x8f3C…9A063 — e todo usuário aprende a conferir as pontas visíveis e pular o meio.
Esse hábito é toda a superfície de ataque.
O atacante gera endereços por força bruta até que um compartilhe os primeiros e os últimos caracteres com um endereço que você de fato usa — em geral um para o qual você mandou dinheiro recentemente. É barato. Gerar pares de chaves é rápido, e casar, digamos, quatro caracteres iniciais e quatro finais leva segundos em hardware comum. Ninguém está quebrando nada; estão só jogando dados até um número parecer familiar.
Depois eles colocam esse endereço no seu histórico. Os métodos comuns:
Poeira. Mandam para você uma quantia minúscula — alguns satoshis, uma fração de centavo de algum token — a partir do endereço sósia. É uma transação de entrada comum, então cai no seu histórico como qualquer outra. Em redes UTXO essa poeira também vira uma moeda gastável dentro da sua carteira, o que importa mais adiante.
Transferências de valor zero. Em redes EVM, um transfer ERC-20 de zero tokens é uma transação válida. O atacante envia 0 tokens do seu endereço para o sósia dele, e algumas interfaces exibem isso como um pagamento de saída feito por você. Seu histórico agora mostra que você aparentemente enviou para um endereço que nunca escolheu.
Eventos falsos. Um contrato de token malicioso pode emitir um evento Transfer que nunca aconteceu. Exploradores e carteiras que confiam nos registros de eventos vão exibi-lo. Nada se moveu; o registro é simplesmente uma mentira.
E então esperam. Dias, às vezes meses. O ataque rende na próxima vez em que você for pagar a mesma contraparte, rolar o histórico atrás de «o endereço que usei da última vez» e copiar a linha errada. Os dois parecem 0x8f3C…9A063. Você confere as pontas. As pontas batem.
Por que o conselho de sempre não se sustenta
«Sempre confira o endereço duas vezes» é a orientação padrão e, sozinha, ela falha, porque conferir é exatamente o que o ataque antecipa. Você conferiu. Comparou os seis caracteres que a carteira mostrou com os seis caracteres da sua memória, e eram idênticos — porque o atacante os fez idênticos.
Verificação só funciona quando aquilo que você compara é caro de falsificar. Quatro ou seis caracteres coincidentes custam segundos. Dezesseis caracteres coincidentes custariam mais do que vale o roubo. O jogo inteiro é em que ponta dessa curva os seus hábitos estão.
Há uma segunda armadilha em redes UTXO. Aquele pagamento de poeira agora é uma moeda na sua carteira e, se sua carteira consolida entradas automaticamente, ela pode ser varrida para dentro de uma transação posterior — ligando o endereço empoeirado ao resto das suas moedas. É um problema de privacidade mais do que de roubo, mas é a razão pela qual poeira se ignora em vez de se arrumar.
O que de fato protege
Nunca tire um endereço de um histórico de transações. Essa é a única mudança que importa. Seu histórico é um registro do que aconteceu, não uma lista de em quem você confia — e qualquer pessoa no mundo pode escrever nele. Pegue endereços com a contraparte, por um canal em que você notaria um impostor, ou de uma agenda que você mesmo preencheu.
Compare endereços inteiros, ou compare algo que resuma o endereço inteiro. Ler os quarenta e dois caracteres não é realista. Comparar um identicon — uma imagenzinha gerada de forma determinística a partir da sequência inteira — é, porque um sósia que difere em qualquer ponto do meio produz um desenho visivelmente diferente. Seu olho faz o trabalho que sua paciência não fará.
Use um contato salvo. Um endereço que você salvou uma vez, de uma fonte que verificou uma vez, não pode ser envenenado depois. É para isso que servem as agendas, e é por isso que a SSP guarda contatos no seu aparelho e não num servidor: uma lista de contatos só é confiável se mais ninguém puder editá-la.
Mande um pagamento de teste em transferências grandes ou de primeira vez. Valor pequeno, confirme o recebimento por fora, depois mande o resto. As taxas tornam isso chato, e continua sendo o certo para um pagamento que você odiaria perder.
Ignore a poeira. Não gaste, não «faça faxina» e tenha cuidado com consolidação automática se privacidade importa para você.
O que a SSP faz a respeito
Envenenamento de endereço é um problema de renderização tanto quanto de segurança, então parte da resposta mora em como os endereços são desenhados.
A SSP encurta endereços com seis caracteres iniciais e seis finais — 0x8f3C4b…9A0631 — em vez dos três ou quatro que muitas interfaces usam. Não é escolha cosmética. Cada caractere a mais multiplica o custo de força bruta para produzir uma coincidência, e doze caracteres visíveis põem um sósia convincente bem fora do alcance da geração casual.
O meio é atenuado, não apagado. Na forma expandida a carteira mostra a sequência completa com as pontas em negrito e o meio numa cor mais clara, de modo que a parte com que os atacantes contam que você pule continua fisicamente na tela, em vez de ser trocada por reticências que poderiam esconder qualquer coisa.
O mesmo código roda nos dois aplicativos. splitAddressForDisplay na SSP Wallet é um port direto do da SSP Key, mantido deliberadamente idêntico para que um endereço apareça igual no seu navegador e no seu celular. Isso importa porque a SSP mostra a transação duas vezes, em dois aparelhos — e uma segunda olhada só é conferência de verdade se as duas superfícies renderizarem a mesma coisa do mesmo jeito. Dois truncamentos diferentes deixariam uma discrepância se esconder na diferença.
Na tela de aprovação da SSP Key, o destinatário aparece com um identicon gerado a partir do endereço completo, ao lado do texto encurtado, e tocar nele expande o endereço inteiro como texto selecionável. O identicon é a parte que derrota uma troca no meio da sequência: um atacante pode casar seus caracteres iniciais e finais, mas não consegue casar uma imagem derivada de todos os caracteres sem resolver um problema muito mais difícil.
Nada disso é garantia. Se você colar um endereço envenenado e aprová-lo nos dois aparelhos, a SSP vai assiná-lo — é isso que significa ser uma carteira que você controla e não um custodiante que questiona suas decisões. O multisig dois-de-dois impede que outra pessoa gaste suas moedas; não impede que você pague a pessoa errada de propósito. Como em todo ataque que funciona fazendo você agir, a defesa precisa chegar antes da assinatura, não durante.
A versão curta
Envenenamento de endereço funciona porque você compara seis caracteres em vez de quarenta e dois, e o atacante sabe quais seis. A defesa não é mais diligência — é nunca tirar um endereço de um lugar onde um atacante possa escrever, e usar ferramentas que devolvam para a sua frente as partes que você pularia.
