Como ler uma transação antes de assiná-la

Duas das maiores perdas do nosso Rastreador de Incidentes compartilham um mecanismo, e não é o que as pessoas imaginam. Ninguém adivinhou uma chave. Aos signatários foi mostrada uma transação e eles aprovaram outra.

Este guia trata da distância entre o que um site diz que uma transação vai fazer e o que a transação de fato faz — e de qual tela resolve essa divergência.

Por que essa distância existe

Quando você interage com uma aplicação web que quer uma transação assinada, várias coisas acontecem ao mesmo tempo. A página constrói uma transação. Sua carteira a recebe. Sua carteira — ou um dispositivo de hardware conectado — exibe alguma representação dela. Você aprova.

A descrição que você lê na página é escrita pela própria página. É texto de divulgação sobre a transação. Ela não deriva da transação, e nada obriga as duas a coincidirem.

No incidente da Bybit, a falha relatada foi exatamente essa: uma transferência de rotina em que o payload executado diferia do que a interface de assinatura exibia. Aproximadamente US$ 1,5 bilhão foi movimentado, segundo o anúncio do próprio FBI. Vários signatários aprovaram. A cada um foi mostrada a mesma representação incorreta, de modo que ter vários deles não acrescentou nada.

A hierarquia das telas

Nem todas as exibições merecem a mesma confiança. Em ordem decrescente:

1. A tela da própria carteira de hardware. Ela é gerada pelo dispositivo a partir da transação que ele foi de fato solicitado a assinar. É o elo mais difícil de ser influenciado por uma página web comprometida — que é toda a razão de o dispositivo ter uma tela.
2. A caixa de confirmação do software da sua carteira. Melhor que a página, mas roda na mesma máquina e, no caso de uma extensão de navegador, em um ambiente que a página compartilha.
3. A descrição da página web. Útil para entender a intenção. Inútil como verificação.

O comprometimento do Ledger Connect Kit ilustra isso com precisão. Código malicioso foi injetado em uma biblioteca carregada por muitos dapps, e ele apresentava aos usuários uma transação de drenagem. Quem leu a tela do dispositivo antes de aprovar conseguia ver uma transferência que não havia solicitado. Quem confirmou pela descrição da página, não.

O que de fato observar

Na tela do dispositivo, para uma transferência:

• O endereço de destino — inteiro, não os quatro primeiros e os quatro últimos caracteres. Os ataques de envenenamento de endereço funcionam justamente produzindo endereços cujas pontas coincidem com as de um endereço que você já usou.
• O valor e o ativo. Confirme os dois, inclusive a posição da casa decimal.
• A rede. A transação certa na blockchain errada continua sendo uma perda.

Para uma interação com contrato:

• A função que está sendo chamada, quando o dispositivo consegue decodificá-la. Um approve, setApprovalForAll ou permit inesperado quando você acreditava estar fazendo stake ou um resgate é o sinal para parar.
• O endereço gastador ou operador em uma aprovação, que é o endereço que você está autorizando — não o contrato que você acha que está usando.
• Avisos de assinatura às cegas. Se o dispositivo diz que não consegue decodificar o que está sendo solicitado a assinar, isso é informação, não um obstáculo.

Confirmação por canal independente

Para qualquer coisa relevante, confirme o destino por um canal que não seja o que está propondo a transação. Se uma página fornece um endereço e a mesma página confirma que o endereço está correto, você não verificou nada. Esta é a versão organizacional do mesmo controle: a razão pela qual os procedimentos de transferências elevadas exigem confirmação por uma via separada é que um único canal comprometido pode ser internamente consistente.

Do que isso não protege você

• Uma aprovação que você já concedeu. Ler transações com cuidado a partir de hoje não resolve nada quanto a um limite autorizado permanente do ano passado. Veja como verificar suas aprovações.
• Uma frase de recuperação comprometida. Nenhum cuidado no momento da assinatura ajuda se outra pessoa consegue reconstruir a conta.
• Um protocolo que em si está quebrado. Uma transação perfeitamente legítima para um contrato vulnerável continua exposta a essa vulnerabilidade. A maioria dos incidentes do nosso rastreador envolve usuários que assinaram exatamente o que pretendiam.
• Fadiga. Este é o limite real. Ninguém lê a centésima aprovação de rotina com o cuidado que dedicou à primeira, e os ataques são desenhados em torno disso.

O resumo honesto

Ler o que você assina é o único controle que teria evitado várias das perdas que registramos, e também é genuinamente difícil de sustentar. Trate isso de forma proporcional: interações pequenas e rotineiras não precisam de cerimônia, e qualquer transação cuja perda faria diferença para você merece a tela do dispositivo, o endereço completo e uma pausa.