Plataformas Verificadas
Quick Links
Onde Permanecer Protegido
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Você fez tudo que os guias mandam. Digitou o endereço à mão em vez de clicar num link. Viu o cadeado. Já tinha usado o site muitas vezes antes.
Então você assinou uma transação, e a carteira esvaziou.
Nada no smart contract falhou. Ele leu o seu pedido, conferiu a sua assinatura e moveu os fundos exatamente como estava escrito. O ataque nunca esteve no contrato. Esteve no site ao qual você conecta a sua carteira.
Este é um walkthrough da Kodex com a Eunha, que entende o que um sistema faz pelo que ele toca, não pelo que ele promete. A pergunta que vocês dois vão encarar é aquela que quase todo mundo responde rápido demais: é seguro conectar sua carteira a um dApp?
A Eunha não começa pela carteira. Ela começa pela página. "Antes de clicar em Confirmar", ela diz, "me diga em qual metade desse app você está confiando de verdade."
No dia 27 de junho, cerca de US$ 3,1 milhões saíram das carteiras de usuários no mercado de previsões Polymarket sem que uma única linha do código on-chain quebrasse. A CoinDesk noticiou que o dreno atingiu onze carteiras, com os saldos roubados convertidos em cerca de 1.893 ETH e transferidos da Polygon para a Ethereum. Os contratos fizeram exatamente o que foram escritos para fazer. O comprometimento estava uma camada acima deles, no frontend do site, onde o código de um fornecedor terceirizado tinha sido envenenado com JavaScript malicioso.
A Eunha coloca os dois fatos lado a lado. "O código na blockchain era honesto", ela diz. "O código no seu navegador não era. Os dois rodaram. Você assinou o segundo."
Aqui está o que incomoda as pessoas nisso. As vítimas não caíram em phishing. Nenhum domínio parecido, nenhum clone falso, nenhum erro de digitação na barra de endereço. Elas estavam na Polymarket de verdade, o site que já tinham usado antes, e aprovaram a transação por conta própria. A página simplesmente construiu um pedido diferente daquele que elas achavam que estavam fazendo.
Este não é o tipo de roubo em que alguém rouba suas chaves. Nenhuma seed phrase vazou. Nenhuma senha foi adivinhada. Você segura as suas chaves o tempo todo, e as usa para assinar a sua própria perda.
A Polymarket removeu a dependência comprometida e prometeu reembolso total às carteiras afetadas. Foi o segundo incidente da plataforma em semanas, depois de uma invasão separada no fim de maio às carteiras internas de pagamento. (Uma investigação atual da CFTC sobre a empresa é outro assunto, sobre marketing, não sobre este ataque. Mantenha os dois separados.) Pelo monitoramento da DefiLlama, comprometimentos de frontend e de contas como este já lideram os incidentes em DeFi por contagem, mesmo quando cada um drena menos do que uma exploração de contrato de manchete.
Reduza a notícia à sua forma. Um site de verdade no qual você confiava entregou a você uma transação de verdade que causou um dano de verdade.
Nada precisou ser hackeado do jeito que você imagina hackear.
Um dApp não é uma coisa só. São duas.
Uma metade é o smart contract: código publicado numa blockchain, fixo no lugar, igual para todo mundo que o chama, e muitas vezes auditado linha por linha. A outra metade é o frontend: um site, rodando no seu navegador, servido por uma infraestrutura web comum. Essa metade constrói a transação. Você clica num botão, e a página monta a chamada de verdade, a função, o destino, o valor, e entrega isso para a sua carteira assinar.
A sua carteira não conhece a sua intenção. Ela conhece a chamada que recebeu.
"Você acha que está clicando em Apostar", diz a Eunha. "A sua carteira vê uma função, um endereço e um número. Ela vai assinar o que quer que esses três sejam, porque assinar isso é todo o trabalho dela."
O contrato é a metade que não pode mudar entre uma visita e outra. O frontend é a metade que pode mudar a cada carregamento. Ele puxa bibliotecas de terceiros, kits de carteira, analytics, dezenas de dependências mantidas por pessoas que você nunca vai conhecer e não tem como verificar. Uma única página pode carregar código de uma dúzia de origens, e cada uma é um lugar onde o build pode ser envenenado lá em cima, antes mesmo de chegar até você. Comprometa qualquer uma delas e a página que carrega hoje não é a página que carregou ontem, mesmo que o endereço na sua barra seja idêntico até o último caractere.
Essa assimetria é a história inteira. Você conferiu a parte que fica parada. O ataque veio da parte que se mexe.
É o mesmo formato de um malware que entra na sua máquina por uma dependência, só que aqui a dependência envenenada roda dentro do site em vez de no seu computador. A confiança que você dá à marca na página se estende, em silêncio, a cada biblioteca que aquela página carrega.
Passe as suas defesas de sempre na frente da Eunha, uma de cada vez, e veja cada uma passar enquanto o dinheiro continua saindo.
Você confere a URL. Está correta. O domínio real foi comprometido, não imitado, então a barra de endereço diz a verdade, e a verdade não ajuda.
Você confere se o contrato é verificado e auditado. Ele é. O contrato nunca foi o problema. A página trocou a chamada antes mesmo de ela chegar à chain.
Você vê o HTTPS e o cadeado. Isso confirma que a conexão é criptografada. Não diz nada sobre o código que chega por essa conexão ser honesto ou não. A entrega criptografada de um script malicioso continua sendo um script malicioso.
Você recorre à hardware wallet, aquela que mantém as suas chaves offline. Ela assina a calldata que a página construiu. Ela não consegue ler a sua mente e perceber que o destino está errado. O cold storage protege a chave, não a intenção por trás do clique.
Nada disso se anuncia. A chamada maliciosa chega com a mesma cara de toda chamada que você já aprovou, no mesmo popup da carteira, embaixo do mesmo botão Confirmar. Não existe um aviso, porque nada na cadeia de software sabe que algo está errado. O site acredita que está servindo o próprio código. A sua carteira acredita que está assinando a sua intenção.
Site certo. Contrato certo. Chamada errada.
"Cada checagem que você fez responde a uma pergunta diferente da que importa", diz a Eunha. "Todas perguntam: este é o lugar de verdade? A pergunta é: esta é a transação de verdade?"
Proteger a própria carteira é necessário, e não é a cura para isto, porque uma carteira protegida ainda assina o que recebe. As defesas que te ensinaram não estão erradas. Elas miram uma camada abaixo de onde este ataque vive.
Quando um frontend envenenado reescreve a sua transação, ele tende a pedir uma de poucas coisas, porque poucas coisas já bastam.
A mais comum é uma aprovação. Tokens ERC-20 deixam você conceder a um spender permissão para mover os seus tokens no seu lugar, por uma função como approve, uma assinatura permit sem gas, ou setApprovalForAll para uma coleção de NFT. Conceda essa permissão a um endereço que o atacante controla, e ele pode puxar os tokens depois, no ritmo dele, sem nenhuma assinatura nova sua. A página veste a aprovação com a roupa da ação que você veio fazer.
A versão mais traiçoeira é uma assinatura sem gas. Uma aprovação permit ou Permit2 é assinada off-chain, então ela nunca aparece como uma transação pendente e não custa gas, o que faz parecer ainda menos uma ação que você tomou. Uma assinatura, sem taxa, e a allowance está ativa.
A outra é uma transferência direta, disfarçada de depósito ou de resgate.
A Eunha te faz desacelerar na primeira. "Uma aprovação não tem cara de perder dinheiro", ela diz. "Nada sai naquele momento. Você assina, o saldo continua o mesmo, e você fecha a aba. A porta só ficou aberta agora, e fica aberta."
É por isso que uma allowance permanente é o perigo silencioso. Ela fica ali muito depois de você ter esquecido a sessão, e uma única aprovação esquecida para o contrato errado é tudo de que um dreno precisa para funcionar. É a mesma porta aberta que faz valer a pena manter o hábito de revogar aprovações de token, muito depois de a página que pediu já estar fechada.
O formato para guardar: a assinatura perigosa não é a que envia os seus fundos. É a que, em silêncio, permite que outra pessoa os envie.
Existe uma defesa que o ataque não tem como contornar, e você já a tem. A sua carteira mostra a transação antes de você assinar. A disciplina é de fato ler, em vez de clicar direto.
Três campos decidem se uma chamada é segura para assinar.
A função. Isto é um approve ou um setApprovalForAll quando tudo que você queria era trocar uma vez? Um verbo de permissão merece um segundo olhar todas as vezes.
O spender ou destino. É o contrato que você esperava, ou um endereço que você nunca viu? Uma troca que de repente quer enviar para um lugar desconhecido é o sinal.
O valor. É o número que você digitou, ou uma allowance ilimitada escondida atrás de um botão Confirmar simpático? Ilimitada significa todo o seu saldo, por todo o tempo que a aprovação durar.
Se qualquer um dos três não bater com o que você acabou de fazer, recuse. Uma transação recusada não custa nada além de um instante.
"Leia a chamada, não a página", diz a Eunha. "A página é o discurso de venda. A chamada é o contrato que você está de fato assinando."
As carteiras modernas ajudam aqui. Muitas hoje traduzem um pedido para uma linguagem clara e simulam o que ele faria com os seus saldos antes de você aprovar. Apoie-se nessa prévia, e tenha um cuidado redobrado quando uma carteira não consegue traduzir um pedido e te pede para assinar dados crus e ilegíveis. Assinar o que você não consegue ler é como os piores casos terminam.
Dois hábitos reduzem o estrago até no dia em que você escorrega. Mantenha as aprovações no mínimo, para que uma página envenenada encontre menos para levar e uma allowance antiga não possa ser virada contra você. E mantenha uma carteira separada para atividade em dApp, guardando só o que você está disposto a colocar na mesa, para que o resto dos seus fundos nunca fique atrás de uma única assinatura ruim. Um verificador de aprovações de block explorer ou uma ferramenta de revogação torna a auditoria de permissões permanentes uma rotina. A ferramenta que você escolhe importa muito menos do que o hábito de olhar.
Este é o núcleo do Framework de Sobrevivência: suponha que algo vai, em algum momento, comprometer a tela na sua frente, e assine como se já tivesse comprometido.
A Eunha põe as duas metades do app lado a lado.
| A página (frontend) | O contrato (on-chain) |
|---|---|
| Roda no seu navegador | Roda na blockchain |
| Pode mudar a cada visita | Fixo depois de publicado |
| Qualquer um que comprometa o site ou uma dependência pode reescrever | Ninguém pode alterar depois do lançamento |
| A sua carteira nunca confere, ela assina a chamada que a página entrega | A sua carteira só executa o código como está escrito |
| Ler a chamada crua é o que protege você | A auditoria é o que protege você |
Um lado você audita uma vez e confia. O outro você tem que ler toda vez que assina.
Conectar a sua carteira é seguro. Ler é seguro. Uma conexão somente leitura deixa um site ver o seu endereço público e os seus saldos, e ver não move nada do que é seu.
Assinar é onde mora o risco.
Então a resposta honesta não é sim e não é não. É esta: conectar, sim; assinar, só depois de ler. O site de verdade no qual você confia ainda pode te entregar uma chamada ruim, porque a metade dele que constrói a chamada não é a metade que foi auditada. Isso não torna os dApps inutilizáveis. Torna um hábito inegociável. Toda assinatura é lida, em todo site, não importa quantas vezes você já o tenha usado.
A Eunha fecha o ciclo. "Você não consegue obrigar uma página a ser honesta", ela diz. "Você só consegue ler a chamada e decidir. É esse o trabalho inteiro, e ele é seu, não do site."
O contrato aguentou. A página não. A assinatura sempre foi a porta, e os seus próprios olhos são a fechadura.
Pode, se o frontend dele for comprometido. O site não precisa ser falso. Quando um atacante envenena uma dependência de terceiros que o site real carrega, o domínio genuíno pode te entregar uma transação que drena a carteira. A sua defesa não é identificar um site falso. É ler a chamada antes de assinar, mesmo num site em que você confia totalmente.
Ela protege as suas chaves, não a sua intenção. Uma hardware wallet mantém as suas chaves privadas offline e assina a transação que o site construiu. Se a página montou uma aprovação maliciosa, o dispositivo assina essa aprovação com a mesma fidelidade com que assinaria uma legítima. Ela guarda a chave. Ela não consegue julgar a chamada.
Leia três campos no aviso da carteira: a função (é uma aprovação que você não pretendia?), o spender ou destino (é o endereço que você esperava?) e o valor (é o seu número, ou uma allowance ilimitada?). Se qualquer um não bater com o que você acabou de fazer, recuse. Para um passo a passo mais profundo, o guia da MetaMask sobre como saber se um contrato é seguro para interagir detalha como ler um pedido.
Não. Os contratos da Polymarket rodaram como projetados. O comprometimento estava no frontend, um script malicioso injetado por um fornecedor terceirizado, que construiu transações fraudulentas que os usuários então aprovaram. Os fundos se moveram por assinaturas válidas em código que funcionava, que é exatamente por que as checagens de URL e de auditoria não pegaram.
Ele tem como alvo o código de terceiros do qual um site legítimo depende, em vez do site ou da blockchain diretamente. Ao comprometer uma dependência no build, o atacante muda o que a página real faz, neste caso fazendo-a construir transações que drenam a carteira, sem nunca tocar no smart contract nem no domínio que você digitou.
