Sequestros de front-end: quando o site verdadeiro se volta contra você

A maioria dos conselhos contra phishing se resume a uma regra: confira se você está no site verdadeiro. Digite o endereço você mesmo, use favoritos, ignore links em mensagens. É um bom conselho, mas tem um ponto cego. Às vezes o site verdadeiro, no endereço verdadeiro, começa a servir algo malicioso.

Isso é um sequestro de front-end. Os smart contracts por trás de um dApp podem estar perfeitamente seguros enquanto o site que você usa para acessá-los foi substituído silenciosamente, e cada transação que ele pede para você assinar foi feita para esvaziar a sua carteira.

O site é uma coisa separada do protocolo

Um aplicativo descentralizado tem duas metades:

• Os contratos na blockchain, que guardam os fundos e aplicam as regras.
• O front-end — o site —, que lê dados, monta transações e as envia para a sua carteira assinar.

Os contratos geralmente são auditados, públicos e difíceis de alterar. O front-end é um site comum, hospedado em uma infraestrutura comum, e é ele que decide exatamente o que chega até você para assinatura. Se um atacante controla o site, ele não precisa mexer nos contratos. Basta que você assine a transação dele no lugar da verdadeira.

Como os front-ends são sequestrados

• Sequestro de DNS. O atacante assume as configurações do domínio — muitas vezes pelo registrador de domínios ou pela conta que o administra — e aponta o endereço verdadeiro para o próprio servidor. A URL no seu navegador está correta; o site, não.
• Hospedagem ou implantação comprometidas. Um atacante com acesso à hospedagem do projeto, ao pipeline de build ou às chaves de implantação publica uma versão modificada do site.
• Dependências maliciosas. Um script ou biblioteca de terceiros carregado pelo site — analytics, um componente de interface, um pacote de conexão de carteiras — é comprometido, e todos os sites que o usam passam a servir o código do atacante.
• Scripts injetados. Uma vulnerabilidade permite que um atacante insira código em uma página que, de resto, é legítima.

Em todos os casos, tudo na visita parece normal. Mesma URL, mesmo design, mesmo fluxo — até o pedido de transação.

Como é o ataque

Um front-end sequestrado costuma mirar em um de poucos pedidos de alto valor:

• Aprovações ilimitadas de tokens para um endereço do atacante, disfarçadas de uma etapa normal de "aprovar para continuar".
• "Aprovação para todos" em NFTs, apresentada como listagem ou resgate.
• Assinaturas off-chain — permits ou ordens de marketplace — que podem ser enviadas mais tarde para movimentar fundos sem nenhum outro aviso.
• Transferências diretas disfarçadas de depósitos, resgates ou migrações.

O sinal de alerta é a incompatibilidade entre o que você está fazendo e o que estão pedindo para você assinar. Trocar um valor pequeno não deveria exigir aprovar uma permissão ilimitada para um endereço que você não reconhece. Resgatar uma recompensa não deveria exigir a transferência de tudo.

Como se defender

Você não consegue detectar um servidor sequestrado olhando para a página. Sua defesa é a etapa de assinatura, porque é ali que a intenção do atacante precisa ficar visível.

• Leia cada pedido na sua carteira, não no site. A página pode dizer qualquer coisa; a carteira mostra o que você está realmente assinando.
• Confira o gastador e o valor nas aprovações. Endereços desconhecidos e permissões ilimitadas merecem uma parada imediata.
• Desconfie de mudanças repentinas no fluxo. Um site que nunca pedia assinatura ou aprovação em determinada etapa e de repente passa a pedir é um sinal de alerta.
• Use simulação quando tiver. Pré-visualizar o que uma transação vai fazer pega pedidos cujo efeito real é diferente do rótulo.
• Acompanhe os comunicados. Projetos que detectam um comprometimento do front-end costumam avisar rapidamente em seus canais oficiais. Se algo parecer estranho, verifique antes de assinar.
• Revogue depois se estiver em dúvida. Se você aprovou algo durante um período em que um site estava comprometido, revogue a aprovação imediatamente.

Isso complementa os conselhos clássicos sobre phishing, em vez de substituí-los. Conferir o endereço protege você de sites falsos; ler o pedido protege você de sites verdadeiros que se tornaram maliciosos.

Onde o SSP ajuda

Quando um dApp conectado pelo WalletConnect pede ao SSP para assinar, o pedido mostra qual site está pedindo, a rede e o endereço, e o SSP decodifica as chamadas mais comuns antes de você aprovar: transferências, aprovações e pedidos de aprovação para todos em NFTs são identificados, com avisos explícitos nos mais arriscados. As mensagens são exibidas como texto legível sempre que possível, com os dados brutos disponíveis para inspeção.

Depois, cada pedido precisa de uma segunda aprovação no SSP Key, em um dispositivo separado. Isso não impede que um site sequestrado peça algo malicioso, mas dá a você duas chances claras de ver o pedido como ele realmente é, e nenhuma delas na página que o atacante controla.

Para equipes, os cofres do SSP Enterprise adicionam simulação de transações e alertas de risco antes que os signatários aprovem, de modo que uma proposta criada por meio de um front-end comprometido recebe uma segunda análise independente de todos que precisam assiná-la.

O resumo honesto

Um sequestro de front-end transforma um site confiável em ferramenta do atacante sem tocar nos contratos nem na URL. Você não consegue identificá-lo olhando a barra de endereços.

O que você pode fazer é tratar cada pedido de assinatura como a interface verdadeira: leia-o na sua carteira, confira o gastador, o valor e o destinatário, e recuse tudo o que não corresponder ao que você pretendia fazer.