O que é um ataque à cadeia de fornecimento numa carteira de cripto?
Um ataque à cadeia de fornecimento é o comprometimento de um software que não escreveu, que não executa e provavelmente nunca leu o código-fonte, mas no qual a sua carteira depende. Em vez de atacar diretamente o seu dispositivo ou quebrar a criptografia subjacente a Bitcoin, Ethereum ou Solana, o atacante envenena algo mais acima na cadeia: uma dependência, um plug-in, uma ferramenta de build, um servidor de atualizações ou até o firmware assinado de um fornecedor de carteiras hardware.
No software tradicional, um ataque à cadeia de fornecimento pode roubar palavras-passe, plantar ransomware ou desviar dados de clientes. Em cripto, o risco é maior. O trabalho de uma carteira é pegar numa transação, assiná-la com uma chave privada e transmiti-la. Se algum componente ao longo desse caminho conseguir alterar subtilmente os bytes que estão a ser assinados, o atacante não precisa da sua seed phrase. Só precisa que clique em aprovar em algo que parece rotineiro.
É por isso que os investigadores de segurança consideram as carteiras de cripto um cenário pior para um comprometimento da cadeia de fornecimento. A interface mostra normalmente um resumo limpo e abreviado do que está a ser assinado. A transação real pode ser redirecionada de formas que o utilizador não tem capacidade técnica de detetar. E assim que uma transação assinada entra na rede, não há linha de apoio ao cliente, não há estorno e não há forma de a reverter.
Porque é que as carteiras de cripto estão particularmente expostas a este modelo de ameaça
Para perceber porque é que os atacantes se dão ao trabalho de atacar a cadeia de fornecimento de software, ajuda comparar o modelo de ameaça de uma carteira de cripto com o de, por exemplo, uma app bancária. Uma app bancária comunica com um servidor central. Se o servidor for comprometido, o banco pode reverter transações, congelar contas e reemitir cartões. Uma carteira não custodial comunica com uma blockchain pública. Assim que uma transação é confirmada, é final, muitas vezes em segundos em chains como a Solana, ou em poucos minutos na Ethereum L1.
Esta irreversibilidade estende-se à cadeia de fornecimento. Num projeto de software normal, uma dependência comprometida pode permitir a um atacante exfiltrar dados da máquina de um programador, e esse programador notaria comportamentos estranhos, reverteria alterações e rodaria segredos. Num projeto de carteira, uma dependência comprometida pode ser usada para trocar endereços de destino, aumentar aprovações ou envolver uma interação aparentemente legítima com uma dApp num contrato controlado pelo atacante. A vítima vê uma interface familiar, clica, e os fundos saem antes de o ecrã terminar de atualizar.
Há também um problema estrutural de confiança. A maioria dos utilizadores de carteiras não consegue ler o código-fonte das bibliotecas que a sua carteira importa. Não consegue verificar, byte a byte, que o firmware na sua carteira hardware corresponde ao repositório open source. Confiam no fornecedor da carteira, no responsável por uma dependência transitiva e na integridade de uma cadeia de distribuição de software que pode ter dezenas de organizações separadas. Cada uma delas é um potencial ponto de comprometimento, e o atacante só precisa de encontrar um elo fraco.
Como os atacantes comprometem efetivamente a cadeia de fornecimento
Existem várias técnicas distintas, e incidentes graves no espaço cripto já recorreram a todas elas. Compreender as categorias ajuda a raciocinar sobre quais delas a sua configuração pessoal pode estar exposta.
Dependências maliciosas ou comprometidas em gestores de pacotes
O software moderno é construído sobre dependências, pacotes de código pré-compilados que os programadores incorporam para evitar reinventar funcionalidades comuns. Uma carteira típica de Ethereum ou Solana integra centenas destas, muitas vezes de forma indireta. Se um atacante conseguir publicar um pacote malicioso com um nome que é importado automaticamente, ou assumir a conta de um responsável pela manutenção de um pacote popular, pode enviar código hostil para milhares de projetos a jusante numa única atualização.
O ecossistema cripto já registou vários avisos e pelo menos um impacto direto. Investigadores encontraram repetidamente pacotes com typosquatting (pacotes com nomes quase idênticos aos legítimos, concebidos para serem importados por engano) direcionados a carteiras populares e bibliotecas web3. Em alguns casos, o código malicioso foi desenhado para examinar variáveis de ambiente e ficheiros de configuração à procura de frases-semente e chaves privadas, e para as exfiltrar para servidores controlados pelo atacante no momento em que a máquina de um programador executava uma build.
Extensões de navegador comprometidas e front-ends injetados
As carteiras baseadas em navegador, incluindo opções populares para Ethereum e Solana, funcionam como extensões. As extensões são, elas próprias, parte da cadeia de fornecimento: distribuem atualizações em silêncio, têm acesso ao conteúdo de todas as páginas web que visita e podem injetar JavaScript em páginas que julga estarem controladas por uma dApp confiável. Se uma extensão for comprometida, ou se uma extensão maliciosa se fizer passar por uma carteira legítima, pode reescrever o que o utilizador vê e o que este assina.
Já houve vários casos de extensões de carteira falsas ou sequestradas a aparecer em lojas de extensões de navegador. Algumas imitam carteiras reais com nomes e ícones semelhantes. Outras são extensões legítimas que mais tarde são vendidas a terceiros, que enviam uma atualização maliciosa. O utilizador mantém a extensão instalada, não nota qualquer alteração visual e, a partir desse momento, cada transação que aprova é filtrada por código do atacante.
Firmware contaminado de carteiras de hardware
As carteiras de hardware como Ledger e Trezor são frequentemente descritas como a opção mais segura porque a chave privada nunca sai do dispositivo. Isso é verdade, mas apenas se o próprio firmware for confiável. O firmware é software e é distribuído através de uma cadeia de fornecimento que inclui a infraestrutura de build do fornecedor, as chaves de assinatura usadas para autenticar atualizações e o próprio processo do utilizador de verificar (ou não) se o que instalou corresponde ao código-fonte publicado.
Se a infraestrutura de assinatura de um fornecedor for comprometida, um atacante pode enviar firmware que parece legítimo ao dispositivo, gera chaves que o atacante já conhece ou exfiltra sementes em condições específicas. O utilizador veria um pedido normal de atualização, instalá-la-ia, e o dispositivo continuaria a parecer funcional. É um cenário de probabilidade mais baixa do que os ataques via dependências ou extensões, porque exige invadir fornecedores com defesas reforçadas, mas o impacto é catastrófico e o historial de incidentes de cadeia de fornecimento em indústrias adjacentes mostra que não é teórico.
Dependency confusion em repositórios de carteiras
O dependency confusion explora a forma como muitos sistemas de build dão preferência a pacotes internos com nomes privados em vez dos públicos. Um atacante regista um pacote num registo público (como npm ou crates.io) com o mesmo nome de um pacote interno privado usado por uma equipa de carteiras. Se o sistema de build estiver mal configurado, puxa o pacote público controlado pelo atacante em vez do interno. O pacote malicioso é então executado durante a build, frequentemente com acesso a segredos de produção, chaves de assinatura ou infraestrutura de lançamento.
O dependency confusion já foi demonstrado contra grandes empresas de tecnologia e não é exclusivo do mundo cripto, mas projetos de carteiras são um alvo particularmente atrativo porque o comprometimento de uma máquina de build pode levar diretamente ao comprometimento dos binários de carteiras lançados, que são depois distribuídos a milhões de utilizadores.
Compromissos de CDN e bibliotecas na camada dApp
Mesmo que o software da sua carteira esteja limpo, a aplicação descentralizada à qual a liga carrega JavaScript de redes de distribuição de conteúdo e bibliotecas de terceiros. O incidente do Ledger Connect Kit em 2023 é o exemplo canónico. Uma biblioteca JavaScript amplamente usada, que as dApps incorporam para se ligarem a carteiras de hardware Ledger, foi comprometida. Durante várias horas, qualquer pessoa que utilizasse uma dApp que tivesse integrado a versão afetada dessa biblioteca recebia uma transação concebida para esvaziar a sua carteira. Os utilizadores não tinham feito nada de errado. A sua carteira de hardware era genuína. O código malicioso vivia numa biblioteca de front-end, não na carteira propriamente dita.
Esta categoria esbate a linha entre ataque à cadeia de fornecimento e sequestro de front-end, mas a estrutura é a mesma: confiança numa peça de software que não auditou, distribuída através de um canal que não controla.
Incidentes reais que moldaram o modelo de ameaça atual
Analisar casos concretos é mais útil do que descrições abstratas, porque os padrões repetem-se e as falhas são instrutivas.
Ledger Connect Kit (dezembro de 2023)
O Connect Kit da Ledger é uma biblioteca JavaScript que os sites utilizam para permitir que os visitantes liguem uma carteira de hardware Ledger. No final de 2023, um atacante comprometeu a conta da equipa Ledger numa plataforma de distribuição de código e publicou uma versão maliciosa da biblioteca. Durante cerca de cinco horas, as dApps que carregaram a versão afetada apresentaram um pedido de transação que pedia ao utilizador para "ligar" uma carteira, mas que na verdade acionava um contrato de drenagem de fundos. As estimativas de perdas variaram, com investigadores on-chain a rastrear várias centenas de milhares de dólares em ativos drenados e um pequeno número de perdas na ordem das seis figuras.
O incidente é o exemplo de referência de porquê "uso uma carteira de hardware" não é, por si só, uma defesa completa. A carteira de hardware assinou o que lhe foi pedido para assinar. A lógica maliciosa vivia no front-end da dApp, e o utilizador não tinha forma de saber que os bytes que estava a assinar não correspondiam ao que a interface da dApp descrevia. A análise post-mortem oficial da Ledger e análises subsequentes estão disponíveis publicamente e vale a pena lê-las na íntegra.
Sequestro e imitadores de extensões de navegador
Várias lojas de extensões de navegador albergaram extensões de carteira falsas que imitavam carteiras populares, por vezes aparecendo nos resultados de pesquisa acima da verdadeira. Noutros casos, extensões legítimas mas com menos tráfego foram vendidas a terceiros que depois enviaram atualizações com código de roubo de credenciais ou reescrita de transações. O padrão é consistente: a extensão é a cadeia de fornecimento, e uma vez comprometida, a confiança do utilizador na marca é reaproveitada contra ele.
Contas de programadores comprometidas e pacotes com typosquatting
Empresas de segurança documentaram casos de pacotes maliciosos em npm e Rust (crates.io) direcionados a programadores web3. Alguns eram typosquats, pacotes com nomes a um ou dois caracteres de distância de uma biblioteca popular. Outros dependiam de contas de responsáveis comprometidas, em que um programador que não tinha ativado autenticação multifator forte perdeu o controlo das suas credenciais de publicação e viu uma versão maliciosa do seu próprio pacote ser enviada em seu nome. Em vários casos, o código malicioso procurava frases-semente de carteiras, chaves privadas e variáveis de ambiente nas máquinas dos programadores, e depois exfiltrava-as. O risco a jusante para os utilizadores é significativo: um programador cujo portátil é comprometido durante um lançamento pode enviar uma build de carteira com backdoor para milhões de pessoas.
O que a defesa parece na prática
Não há forma de eliminar completamente o risco da cadeia de fornecimento. A resposta honesta é que está a confiar numa longa cadeia de software, e o atacante só precisa de encontrar um elo fraco. O que pode fazer é reduzir o número de elos, aumentar o custo de cada um e conceber os seus hábitos de modo a que um único comprometimento não se transforme numa perda total.
Reduza a sua superfície de confiança
Menos extensões, menos carteiras baseadas em navegador, menos configurações "sempre ligadas" significam menos peças de software que podem reescrever o que assina. Muitos utilizadores preocupados com a segurança mantêm os seus principais fundos numa carteira de hardware usada apenas para assinar, com o software da carteira a correr num dispositivo dedicado, e interagem com dApps através de uma hot wallet separada e descartável. Isto não é paranoia, é compartimentação, o mesmo princípio que evita que um café derramado destrua um ano de trabalho.
Trate as atualizações com a mesma suspeita que novo software
Uma atualização a uma carteira, extensão ou firmware de carteira de hardware é uma nova peça de código a correr na sua máquina ou dispositivo. Pergunte, antes de instalar: esta atualização era esperada, a origem é verificável e há forma de adiar um dia ou dois para ver se a comunidade nota algo? O incidente do Ledger Connect Kit em 2023 foi detetado em poucas horas em parte porque utilizadores e investigadores estavam atentos, e as dApps que adiaram a implementação da versão afetada evitaram a maior parte do impacto.
Verifique o que está efetivamente a assinar
As carteiras de hardware existem precisamente para lhe dar uma visualização confiável dos detalhes da transação. Leia esses detalhes. Se estiver a aprovar uma aprovação de token, observe o spender, o montante e o contrato. Se estiver a enviar fundos, observe o destino. As carteiras modernas mostram cada vez mais avisos legíveis por humanos, como "esta aprovação concede acesso ilimitado aos seus USDC" ou "está a interagir com um contrato que não foi verificado". Esses avisos existem porque o risco subjacente é real.
Para programadores e equipas de segurança: fixe, atestigue e segregue
Se desenvolve software de carteiras, o ónus é maior. Fixe versões de dependências, use lockfiles, verifique checksums, prefira builds reproduzíveis e trate as credenciais de publicação com a seriedade de uma password de base de dados de produção. Separe as máquinas que compilam artefactos de lançamento das máquinas que os programadores usam no dia a dia. Use módulos de segurança de hardware ou assinatura multi-participada para chaves de lançamento. E parta do princípio de que qualquer conta individual de um responsável pode ser comprometida, concebendo depois o sistema de modo a que um único comprometimento não seja suficiente para enviar código hostil aos utilizadores.
O que isto significa para si como utilizador
Se retirar apenas uma coisa deste modelo de ameaça, que seja esta: uma carteira cripto é um dispositivo de assinatura, e toda a história de segurança depende do que lhe é pedido para assinar. Os ataques à cadeia de fornecimento não partem a criptografia. Mudam a pergunta. Uma biblioteca ou extensão comprometida não precisa da sua frase-semente. Precisa que continue a comportar-se normalmente enquanto ela reescreve silenciosamente a resposta.
As implicações práticas começam pela higiene. Use uma carteira de hardware para saldos relevantes. Mantenha o mínimo possível numa hot wallet. Audite as suas extensões de navegador e remova tudo o que não utiliza ativamente. Seja cético em relação a pedidos de dApps que exigem aprovações amplas de tokens. Quando surgir uma atualização de carteira ou extensão, espere um dia se puder. E lembre-se de que nenhuma interface é confiável só porque reconhece o logótipo, porque o incidente do Ledger Connect Kit em 2023 foi uma biblioteca JavaScript, não um binário de carteira, e as vítimas estavam em dApps legítimas.
Para programadores e equipas de segurança, a implicação prática é que defender a cadeia de fornecimento não é opcional. A ameaça não é hipotética, os incidentes estão documentados e a assimetria favorece o atacante: ele só precisa de ganhar uma vez, enquanto você precisa de ganhar sempre. A boa notícia é que o playbook defensivo é bem conhecido, mesmo que nem sempre seja seguido: fixe dependências, verifique assinaturas, separe ambientes de build, monitorize anomalias e conceba sistemas de modo a que uma única conta comprometida não possa enviar um lançamento hostil a milhões.
Acompanhe incidentes na cadeia de fornecimento de forma inteligente
Os ataques à cadeia de fornecimento de carteiras de cripto acontecem rapidamente, desenrolam-se muitas vezes em poucas horas e raramente fazem sentido sem contexto. Monitorizar manualmente os sinais certos — que bibliotecas foram atualizadas, que extensões foram sinalizadas, que alertas de carteiras físicas foram emitidos — é uma batalha perdida. A Zippfeed destaca notícias de segurança em cripto com pontuação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possas detetar incidentes emergentes na cadeia de fornecimento antes que cheguem à tua carteira.
