Um ataque à cadeia de abastecimento de uma carteira em extensão de navegador acontece quando um add-on de confiança, ou uma das bibliotecas open-source de que depende, é alterado discretamente para roubar cripto. Os atacantes exploram dependency-confusion, pacotes npm com typosquatting e atualizações maliciosas enviadas através de publicadores com aparência legítima. A defesa passa por auditar o que instala, fixar versões e transferir a assinatura final para uma hardware wallet à qual a extensão não consegue aceder.
Pontos-chave
- A maioria dos comprometimentos de carteiras tem origem numa extensão de navegador maliciosa, numa dependência envenenada ou numa atualização sequestrada, não numa blockchain avariada.
- O selo de "publicador verificado" da Chrome Web Store comprova uma identidade, não que todas as atualizações futuras sejam seguras.
- Dependency-confusion e typosquatting no registo npm permitem que os atacantes se façam passar por pacotes que os programadores usam por reflexo.
- Uma hardware wallet usada para a assinatura final isola as suas chaves privadas de qualquer comprometimento da extensão, do navegador ou do sistema operativo.
O que é um ataque à cadeia de abastecimento de uma extensão de navegador?
Cada extensão de navegador que instala, incluindo carteiras cripto como MetaMask ou Phantom, é um pequeno programa que funciona com permissões amplas dentro do seu navegador. Um ataque à cadeia de abastecimento visa o pipeline de entrega de software, e não a carteira em si. Em vez de quebrar a sua criptografia, o atacante envenena algo em que a sua carteira, ou o programador da sua carteira, confia. Esse algo pode ser uma biblioteca de código, uma atualização de software, um nome de domínio ou a conta de publicador que envia atualizações para a loja.
Quando o elemento envenenado é distribuído, chega à sua máquina como uma atualização de rotina que não tem motivo para questionar. A extensão continua a parecer e a comportar-se normalmente, mas passa a conter uma pequena rotina adicional. Essa rotina pode ler o conteúdo de qualquer página web, reescrever os detalhes da transação antes de chegarem à sua carteira ou trocar discretamente o endereço de destino de uma transação que está prestes a assinar. Para um utilizador de ETH ou SOL, essa única linha de código injetado basta para esvaziar uma hot wallet numa só aprovação.
A expressão "cadeia de abastecimento" vem da forma como o software moderno é construído. A carteira que usa raramente é escrita do zero. Ela integra centenas de pacotes open-source de registos como o npm, e esses pacotes integram ainda mais pacotes. Cada elo dessa cadeia é um possível ponto de comprometimento, e o fornecedor da carteira é apenas um dos muitos intervenientes cuja segurança está implicitamente a confiar quando clica em "Instalar".
Como os atacantes sequestram realmente a cadeia
Existem vários padrões práticos, e a maioria dos roubos de cripto no mundo real combina dois ou três deles. Compreender a mecânica é a única forma de reconhecer os sinais de alerta antes de os seus fundos se moverem, não depois.
Dependency-confusion no registo npm
Dependency-confusion explora uma particularidade na forma como os gestores de pacotes resolvem nomes. Quando um programador escreve internal-wallet-utils no seu script de build, o gestor de pacotes verifica primeiro o registo público npm se já existir um pacote com esse nome, e prefere o número de versão mais alto. Os atacantes monitorizam nomes de pacotes internos que vazam através de repositórios públicos, anúncios de emprego e bundles JavaScript, depois publicam um pacote público com o mesmo nome e uma versão muito mais alta. Na build seguinte, a equipa da carteira importa a cópia pública maliciosa em vez da sua cópia privada.
Isto não é teórico. Incidentes de grande dimensão em empresas como a Mercedes-Benz e no Exército dos EUA mostraram quão generalizada é a exposição. Para uma carteira cripto, o pacote comprometido seria distribuído como parte da próxima atualização legítima, com a assinatura digital do próprio fornecedor da carteira e um changelog familiar. Os utilizadores não teriam forma de saber que havia algo errado.
Typosquatting e colisões de nomes
Typosquatting é mais simples e igualmente eficaz. O atacante publica um pacote com um nome quase idêntico ao de um pacote popular, esperando que um programador se engane ao escrever o import. ethers.js torna-se ethhers, @solana/web3.js torna-se @solannna/web3.js, lodash torna-se lodahs. Se uma equipa de carteira incluir acidentalmente o imitador, o atacante passa a enviar código para a build de produção.
O ecossistema npm tem dezenas de milhões de pacotes e mudança constante. Lockfiles automatizados e builds reproduzíveis reduzem o risco, mas só ajudam se a equipa da carteira os usar corretamente e se um investigador de segurança rever cada dependência. As equipas mais pequenas muitas vezes não têm esse luxo.
Atualizações maliciosas através de contas de publicador comprometidas
Os ataques mais dramáticos vieram de credenciais de publicador roubadas. Num caso bem documentado, os atacantes obtiveram acesso à conta Chrome Web Store de um programador e enviaram uma atualização maliciosa para um gestor de palavras-passe popular que também servia como ferramenta adjacente a carteiras. A atualização parecia idêntica à verdadeira, manteve todas as funcionalidades antigas e adicionou um script oculto que exfiltrava os dados que a extensão conseguia ver.
As extensões de carteiras cripto são um alvo particularmente apelativo porque os seus utilizadores detêm ativos valiosos. Uma única atualização sequestrada de uma carteira com centenas de milhares de instalações pode render aos atacantes milhões em ETH ou SOL antes de alguém reparar. A loja de extensões não tem uma forma real de inspecionar o comportamento em tempo de execução de uma atualização, por isso a versão maliciosa é distribuída no momento em que é carregada.
Imitação em lojas de navegadores
Mesmo sem um comprometimento real do publicador, os atacantes clonam extensões de carteiras legítimas sob nomes parecidos, compram avaliações falsas de cinco estrelas e pagam anúncios de pesquisa para que a sua listagem apareça acima da verdadeira. A vítima instala algo que parece MetaMask ou Phantom, escreve a sua seed phrase numa interface de phishing perfeitamente criada, e isso é o fim da carteira.
O que o selo de "editor verificado" garante realmente
O selo verde ou azul de "verificado" na Chrome Web Store ou no site Firefox Add-ons é um dos sinais de confiança mais mal compreendidos no software. Eis o que ele prova de facto, e o que não prova.
O selo confirma que o editor por trás da extensão verificou a sua identidade junto da loja, normalmente pagando uma pequena taxa e confirmando o controlo de um domínio ou de uma entidade empresarial. Diz-lhe que a extensão listada vem genuinamente da empresa cujo nome aparece na página. Não lhe diz que a empresa tem um histórico de segurança perfeito. Não lhe diz que a atualização de hoje é o mesmo código de ontem. Não lhe diz que as dependências open-source dentro da extensão não foram sequestradas. Não lhe diz nada sobre a integridade das próprias credenciais do programador, que ainda podem ser alvo de phishing, roubadas ou vendidas.
Para utilizadores de cripto, a implicação prática é desconfortável. Mesmo uma wallet de uma equipa conhecida e verificada pode distribuir amanhã uma compilação maliciosa se qualquer elo da cadeia de fornecimento falhar. O selo de verificação é um filtro útil contra esquemas óbvios, mas não é o tipo de garantia que lhe permite saltar o resto desta lista de verificação.
Os riscos realistas que enfrenta de facto
Antes de listar defesas, vale a pena ser honesto sobre os modos de falha. Ataques à cadeia de fornecimento não são casos-limite hipotéticos. São uma categoria ativa e bem financiada de roubo de cripto, e alguns padrões repetem-se nas análises post-mortem.
O maior risco individual é assinar uma transação cujo endereço de destino foi trocado. Uma extensão maliciosa lê a página, deteta que está prestes a enviar 1 ETH para um endereço legítimo e reescreve silenciosamente esse endereço para um controlado pelo atacante. O montante, a taxa de gas e a interface visível parecem exatamente corretos. Clica em confirmar e os fundos são transferidos.
O segundo risco é a captura da seed phrase. Uma extensão envenenada pode ler tudo no DOM da página, incluindo qualquer formulário HTML onde um utilizador descuidado tenha colado ou escrito uma frase de recuperação. Assim que a frase é exfiltrada, a wallet fica comprometida para sempre, independentemente de quaisquer medidas defensivas futuras.
O terceiro risco são aprovações cegas. Novos padrões de tokens, incluindo o mecanismo EIP-7702 que entrou em produção para Ethereum em 2025 e continua a amadurecer ao longo de 2026, permitem que EOAs (externally owned accounts, as wallets normais que utiliza) deleguem temporariamente o controlo em código de smart contract durante uma transação. Uma extensão maliciosa pode abusar disto para agrupar uma aprovação que permite a lógica controlada pelo atacante esvaziar a sua wallet dentro do mesmo bloco. A transação continua a dizer "approve", mas aquilo que está a ser aprovado é a capacidade de mover todos os tokens que detém.
O quarto risco é a atualização "quase legítima". Mesmo depois de uma extensão sequestrada ser removida da loja, o dano persiste para todos os utilizadores que já fizeram auto-update. As remoções pelas lojas são lentas, e as caches dos browsers por vezes continuam a executar a versão má muito depois de esta ter sido sinalizada. Quando o aviso chega até si, o atacante normalmente já moveu os fundos através de um mixer.
Como defender-se: uma lista de verificação prática
Nenhum dos passos abaixo é uma solução milagrosa. O objetivo é sobrepô-los para que um comprometimento numa fase não se transforme numa perda total.
Audite o que está realmente instalado
Abra a lista de extensões do seu browser e olhe para cada entrada. Para cada uma, faça três perguntas: ainda a uso, sei quem a criou e precisa de acesso a todos os sites que visito. Extensões que pedem para "ler e alterar todos os seus dados nos sites que visita" devem ser tratadas como se tivessem, na prática, a sua palavra-passe bancária. Se não consegue responder "sim, confio neste programador com esse nível de acesso", remova a extensão.
Específico para cripto: mantenha a extensão de wallet que utiliza realmente e, no máximo, uma ou duas ferramentas auxiliares com âmbito bem limitado. Cada extensão adicional é outra cadeia de fornecimento que está a herdar.
Fixe extensões críticas e reveja atualizações
A maioria dos browsers permite desativar atualizações automáticas por extensão. Para a sua wallet e qualquer extensão que toque em chaves ou transações, desligue o auto-update e reveja manualmente o changelog antes de instalar uma nova versão. Compare o número da versão com a página oficial de releases no GitHub do projeto, não com o link dentro da loja, que pode ser falsificado.
Se tiver inclinação técnica, instale extensões a partir do respetivo código-fonte em vez da loja, usando um fluxo de carregamento não empacotado. Isto permite-lhe inspecionar a compilação, verificar checksums contra os hashes publicados pela equipa e congelar uma versão conhecida como boa. Ferramentas como Extension Auditor para Chrome podem listar todas as permissões que uma extensão pede realmente em comparação com o que usa visivelmente, o que é um forte detetor de sinais de alerta.
Verifique o editor, o pacote e o caminho
Para cada extensão crítica, identifique a fonte canónica: o repositório oficial no GitHub, o site oficial, a entrada oficial do editor verificado. Guarde esses links nos favoritos e nunca instale a partir de um resultado de pesquisa. Se vir um anúncio para "MetaMask" acima da listagem real da MetaMask, assuma que é um esquema, porque normalmente é.
Para utilizadores de ETH e SOL, isto também significa ser cético em relação a complementos de wallets que prometem "otimização de gas", "proteção MEV" ou "aumentos de airdrop". Muitos são wrappers em torno de wallets reais que adicionam exatamente o tipo de capacidade de leitura e reescrita de páginas que um atacante desejaria.
Use uma hardware wallet para a assinatura final
Esta é a defesa mais eficaz contra qualquer comprometimento ao nível do browser, incluindo um ataque bem-sucedido à cadeia de fornecimento. Uma hardware wallet, como um dispositivo Ledger ou Trezor, mantém as suas chaves privadas num elemento seguro que o browser e todas as extensões nele instaladas não conseguem ler. Quando a liga à MetaMask, Phantom ou Rabby, a extensão monta a transação e envia-a para o dispositivo. O dispositivo apresenta o endereço de destino, o montante e quaisquer chamadas a contratos no seu próprio ecrã de confiança. Confirma fisicamente, premindo um botão, em hardware isolado do seu browser.
Isto quebra todos os ataques comuns por extensão. Mesmo que uma extensão maliciosa troque o endereço de destino no browser, o endereço mostrado na hardware wallet não vai corresponder. Vê a discrepância antes de assinar, e os fundos permanecem no lugar. Mesmo uma extensão que capture seed phrases não aprende nada, porque a frase nunca sai do dispositivo de hardware.
O custo é fricção. As hardware wallets custam dinheiro, acrescentam alguns segundos a cada transação e ocasionalmente exigem atualizações de firmware. Para qualquer saldo suficientemente grande para lhe causar prejuízo, este compromisso vale largamente a pena.
Pratique higiene de aprovações
Independentemente de como a sua wallet é assinada, nunca aprove allowances ilimitadas de tokens. Quando uma dApp pede permissão para gastar os seus USDC ou outros tokens ERC-20, defina um limite personalizado que corresponda ao que realmente pretende transacionar. Revogue periodicamente allowances antigas usando uma ferramenta como o verificador de aprovações da Etherscan ou Revoke.cash para ETH, e exploradores semelhantes para tokens SOL.
Tenha especial cuidado com o novo fluxo de delegação EIP-7702, que passou a fazer parte da experiência mainstream da Ethereum durante 2025 e está a ser implementado nas wallets em 2026. Uma delegação permite que uma EOA aja como uma smart account durante uma transação, o que é conveniente para patrocínio de gas e aprovações em lote, mas também dá ao contrato delegado a capacidade de mover ativos que assina. Leia o resumo legível para humanos que a sua wallet apresenta, confirme o contrato para o qual está a delegar e evite assinar delegações em sites desconhecidos.
Separe fundos quentes, mornos e frios
Não mantenha todo o seu saldo de ETH ou SOL numa wallet de browser. Use uma configuração em camadas: uma pequena hot wallet para negociação ativa e exploração de dApps, uma wallet morna para posições de dimensão média e uma cold wallet protegida por hardware para poupanças de longo prazo. Os fundos só fluem para baixo, nunca para cima, de frio para quente. Se um ataque à cadeia de fornecimento esvaziar a sua hot wallet, a perda fica limitada.
Como antecipar ameaças ao nível das extensões
Os ataques à cadeia de fornecimento de extensões de browser evoluem rapidamente. Novos incidentes npm, novos padrões de personificação e novos padrões de wallets como EIP-7702 alteram a superfície de ameaça todos os trimestres. Acompanhar quais extensões foram comprometidas, quais editores perderam credenciais e quais incidentes de dependências são relevantes para as wallets que realmente usa é um trabalho de investigação a tempo inteiro se o fizer manualmente.
Zippfeed destaca manchetes de segurança cripto com pontuação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa detetar uma extensão sinalizada ou um grande sequestro npm antes de chegar à fila de atualizações do seu browser.