Escrito por: imToken
Uma carteira de hardware com chips originais intactos, firmware genuíno e até mesmo a capacidade de passar com sucesso na Verificação de Autenticidade oficial — os ativos dentro dela ainda poderiam ser roubados por hackers?
O recente incidente de segurança da Ledger expôs precisamente esse risco aparentemente impossível.
De acordo com os resultados da investigação posteriormente divulgados pela equipe de segurança da Ledger, o atacante implantou um circuito malicioso adicional dentro do dispositivo afetado, que era capaz de interceptar a frase mnemônica exibida na tela e enviá-la ao atacante por meio de redes de comunicação móvel.
Em outras palavras, o chip de segurança original não foi comprometido, mas a frase mnemônica pode já ter caído nas mãos do hacker na primeira vez em que foi exibida na tela.
Além disso, este não é o único incidente de segurança que merece atenção recentemente.
Desde setembro, desde a Bitget enfrentando a exploração de uma vulnerabilidade em um produto de segurança de terceiros, até o provedor de serviços de e-mail da Trezor, Brevo, sendo invadido, até problemas de segurança aparecendo em parte da infraestrutura da MetaMask, uma série de incidentes está nos lembrando de que à medida que os produtos Crypto se tornam cada vez mais complexos, a segurança não se trata mais apenas de proteger chaves privadas e evitar vulnerabilidades de contratos inteligentes.
Os riscos ocultos na circulação de dispositivos, serviços de terceiros, permissões internas e comunicações com usuários podem igualmente se tornar pontos de entrada que os atacantes buscam.
I. O novo alarme de "Segurança da Cadeia de Suprimentos" soado pela Ledger
Vamos primeiro detalhar o que aconteceu com a Ledger desta vez.
Ao comprar uma carteira de hardware, as pessoas geralmente ficam em guarda contra duas coisas: comprar uma falsa, ou receber um dispositivo que foi pré-inicializado por outra pessoa.
O truque mais comum nos primeiros anos era que intermediários maliciosos primeiro gerassem uma frase mnemônica, imprimissem-na em um cartão raspadinha e a colocassem de volta na embalagem, apostando que usuários novatos não entenderiam as regras e depositariam fundos diretamente nela.
Embora esse golpe seja perigoso, a lógica de defesa é muito clara — use canais legítimos, verifique o estado do dispositivo, observe o dispositivo gerar uma nova frase mnemônica por conta própria e nunca use uma frase mnemônica pronta da caixa.
Mas este ataque contra a Ledger claramente elevou o nível dos métodos. O hacker colocou um módulo eletrônico adicional com um microcontrolador, eSIM e capacidades de comunicação celular dentro do invólucro. Quando os usuários inicializam a carteira pela primeira vez, eles ultimately precisarão ler a frase mnemônica na tela e anotá-la.
Em outras palavras, o circuito malicioso implantado não interfere de forma alguma no processo de geração da frase mnemônica; ele apenas monitora a frase mnemônica e a transmite diretamente para fora. É também por isso que "a chave privada não foi extraída diretamente do chip de segurança" não significa que as informações de recuperação da carteira do usuário ainda estejam seguras.
O que é mais problemático é que, mesmo que o dispositivo passe na Verificação de Autenticidade oficial, ele pode não ser capaz de identificar esse hardware adicional, porque a verificação genuína confirma principalmente a identidade do chip de segurança e a confiabilidade do firmware.
Portanto, este incidente de fato expôs um sério "risco de cadeia de suprimentos" que é facilmente negligenciado no dia a dia: a segurança de uma carteira de hardware depende não apenas do chip e do firmware, mas também de todo o processo de entrega desde a fábrica original até as mãos do usuário.
Afinal, um dispositivo pode precisar passar por vários elos, como distribuidores regionais, armazéns de terceiros, logística e varejistas. Qualquer participante com a oportunidade de acessar fisicamente o dispositivo pode se tornar um ponto de risco que exige avaliação adicional.
II. Da Trezor à Bitget: Como os atacantes contornam as principais defesas de segurança?
Tendo entendido o problema da Ledger, se olharmos em seguida para os incidentes de segurança que a Bitget e a Trezor enfrentaram um após o outro recentemente, descobriremos que a lógica subjacente é impressionantemente semelhante: os atacantes igualmente evitaram a linha de defesa frontal mais forte e, em vez disso, entraram pelos "serviços de terceiros" periféricos.
Primeiro, vejamos a Trezor.
No início de setembro, alguns usuários da Trezor receberam um e-mail com o assunto "Alerta Crítico de Segurança: Vulnerabilidade de Entropia STM32", alegando que a carteira de hardware tinha uma grave vulnerabilidade de segurança e que era necessária ação imediata.
E-mails como esse facilmente deixam os usuários nervosos. Afinal, quando envolve carteiras de hardware e vulnerabilidades de segurança, ninguém quer que seus ativos sofram perdas por causa disso.
Foi exatamente o que aconteceu: o atacante explorou a Brevo, a plataforma de marketing por e-mail de terceiros usada pela Trezor, para fazer com que conteúdo malicioso chegasse às caixas de entrada dos usuários por meio da infraestrutura normal de envio de e-mails.
De acordo com o relatório de incidente subsequente da Brevo, o atacante explorou falhas de limite de permissão em seu sistema de logon único para obter acesso não autorizado a outras contas de clientes, envolvendo, em última análise, 138 contas de clientes, algumas das quais foram usadas para enviar e-mails de phishing ou exportar dados de contato.
A Trezor confirmou posteriormente que 347.149 endereços de contato de e-mail de marketing foram exportados no incidente, e os e-mails de ataque tentaram induzir os usuários a baixar aplicativos maliciosos e inserir informações de backup da carteira.
Deve-se notar que não há evidências neste incidente de que as carteiras de hardware da Trezor ou os sistemas de proteção de chave privada tenham sido comprometidos. O que o atacante obteve primeiro foram informações do usuário e a capacidade de abusar dos canais de comunicação oficiais.
Mas, para os usuários comuns que receberam os e-mails, identificar o risco tornou-se ainda mais difícil, porque os e-mails podem ter vindo de um domínio oficial familiar e também podiam passar pelas verificações normais de autenticação de e-mail, enquanto o conteúdo já havia sido substituído pelo atacante por informações de phishing.
Se os usuários inserirem voluntariamente sua frase mnemônica por causa disso, o que originalmente era apenas um problema do serviço de e-mail de terceiros pode evoluir ainda mais para perdas reais de ativos.
Agora vejamos a Bitget.
Em 24 de setembro, ocorreram transferências não autorizadas de ativos em algumas das carteiras quentes e carteiras mornas da Bitget, verificando-se, em última análise, um envolvimento de aproximadamente US$ 388 milhões.
De acordo com os resultados da investigação anunciados oficialmente pela Bitget, o atacante explorou uma vulnerabilidade em um produto de segurança de terceiros para obter credenciais de alto privilégio dentro da exchange, depois invadiu sistemas de backend relacionados às carteiras, forjou instruções de saque, contornou as verificações originais de controle de risco e fez com que transferências anormais entrassem no processo normal de execução.
A Bitget declarou que nenhum vazamento de chave privada foi encontrado neste incidente, e as carteiras frias não foram afetadas. Isso soa um tanto contraditório: se as chaves privadas não foram roubadas, por que o dinheiro ainda pôde ser transferido?
Na verdade, não é difícil de entender.
Para plataformas custodiais como as exchanges, depois que um usuário inicia um saque, não é o caso de uma pessoa assinar manualmente cada transação com uma chave privada a cada vez. Em vez disso, é preciso passar por todo um conjunto de processos internos, como verificação de conta, revisão de controle de risco, geração de transação e assinatura de carteira.
Isso é como um cofre de banco. Mesmo que a chave do cofre seja guardada com muito rigor, se alguém puder se passar por uma identidade interna de alto privilégio e forjar uma instrução de transferência que passe pela aprovação, os fundos no cofre ainda poderão ser transferidos por engano.
O que a Bitget expôs desta vez é exatamente como o risco se propaga ainda mais para o sistema de execução de ativos depois que as permissões upstream e a verificação de instruções falham. Portanto, "a chave privada não vazou" e "os fundos não serão transferidos ilegalmente" são, na verdade, duas coisas diferentes.
Quanto ao incidente de segurança de infraestrutura divulgado pela MetaMask no final de setembro, ele apresentou outra dimensão de risco operacional.
Naquela ocasião, a MetaMask tomou medidas preventivas e saiu proativamente de alguns validadores de staking afetados. De acordo com a atualização oficial da investigação em 1º de outubro, não foram encontrados sinais de que as carteiras MetaMask ou os fundos dos clientes tenham sido afetados, e o negócio de staking relevante não gerencia chaves de saque em nome dos clientes.
No entanto, isso não significa que problemas de infraestrutura não terão outros impactos. Soluções não custodiais tratam principalmente da questão do controle de ativos, mas não podem eliminar automaticamente os riscos operacionais de infraestruturas externas.
Juntando esses eventos, o fio condutor é na verdade muito claro:
- O que a Ledger expôs é o risco de adulteração física no processo de circulação do hardware, que pode, em última análise, levar ao roubo de frases mnemônicas;
- O que a Trezor / Brevo expôs é o risco de vazamento de informações do usuário e uso indevido de canais oficiais de comunicação, o que não significa que a carteira em si foi comprometida;
- O que a Bitget expôs é o risco de vulnerabilidades em produtos de terceiros serem transmitidas para sistemas internos de alto privilégio, o que pode afetar diretamente a execução de fundos;
- A MetaMask, por sua vez, nos lembra que controle de ativos e risco operacional do serviço não são o mesmo conceito.
No geral, os produtos Crypto de hoje não são mais ilhas isoladas.
As carteiras dependem de nós RPC externos para ler dados on-chain e de interfaces de agregação para obter cotações de mercado; as exchanges não podem prescindir de monitoramento de segurança externo, verificação KYC e componentes de controle de risco; estendendo-se mais para fora, há também operadores de nós, provedores de nuvem, tickets de atendimento ao cliente e sistemas de e-mail como o Brevo.
Esses serviços externos fazem os produtos funcionarem com mais eficiência e também melhoram a experiência do usuário, mas, ao mesmo tempo, cada vez que uma nova dependência externa é introduzida, o produto ganha mais uma camada de relações de confiança que precisam ser gerenciadas:
O que terceiros podem acessar, quanta autoridade eles têm e, se forem comprometidos, o risco continuará a ser transmitido para outros sistemas centrais?
III. Como produtos e usuários devem se defender?
Diante de riscos de dependência de terceiros cada vez mais complexos e relações de dependência interligadas, esperar que as equipes de produto recuem ao estado primitivo de "não depender de nenhum serviço externo" é obviamente irrealista e não está em conformidade com as regras de mercado.
O que realmente testa a habilidade de uma arquitetura de segurança é minimizar cada exposição de risco possível.
Por exemplo, por que um provedor de SaaS que apenas lida com e-mails de marketing deveria reter os dados de contato de todos os usuários a longo prazo? Por que ferramentas de monitoramento de segurança de terceiros podem acessar o ambiente de produção central sem multi-autorização independente? Especialmente para ações sensíveis envolvendo transferências de fundos, os sistemas internos nunca devem adotar a "confiança padrão" e devem implementar isolamento rigoroso de permissões e verificação cruzada independente.
Isso também é o que costuma ser chamado de "privilégio mínimo" e "separação de funções" na arquitetura de segurança: uma plataforma de envio de e-mails deve ter apenas as permissões necessárias para enviar e-mails, ferramentas de monitoramento de segurança não devem poder executar transferências de fundos à vontade, e um grande saque não deve ser aprovado diretamente com base apenas em uma instrução transmitida por algum sistema interno.
O incidente da Ledger lembra ainda mais os fabricantes de carteiras hardware de que a gestão de segurança precisa até se estender ao processo de circulação física do produto.
Do envio na fábrica, armazenamento, logística, até a entrega ao revendedor, como estabelecer um processo de gestão rastreável, como detectar desmontagem ou substituição anormal de dispositivos e como localizar lotes e usuários afetados após um problema ocorrer não devem ser considerados mero trabalho de gestão de canais.
Porque, para um dispositivo de hardware que protege chaves privadas, o processo de entrega em si é parte do sistema de segurança.
É claro que, para usuários comuns, não podemos auditar a cadeia de suprimentos de software de uma carteira nem investigar um a um cada elo de armazenamento e logística de uma carteira hardware.
Mas isso não significa que só podemos suportar o risco passivamente. Pelo menos há várias coisas que vale a pena transformar em hábitos no uso diário.
Primeiro, minimize os intermediários desnecessários no processo de compra da carteira hardware.
Se as condições permitirem, priorize fazer o pedido no site oficial da marca e recebê-la enviada diretamente da fábrica original ou do armazém oficial, o que geralmente reduz a chance de o dispositivo ser contatado, desmontado ou trocado por terceiros após sair do controle da fábrica original.
Do ponto de vista da gestão de riscos, quanto mais partes independentes entrarem em contato com o dispositivo, mais elos exigirão confiança adicional; além disso, após receber o dispositivo, você ainda deve verificar se há anormalidades na embalagem e na aparência, usar o software oficial para concluir a verificação e seguir rigorosamente o processo de inicialização.
Segundo, é necessário reentender se as "mensagens oficiais" são confiáveis.
O incidente da Trezor já mostrou que, mesmo que um e-mail seja de fato enviado pela plataforma de serviço oficialmente utilizada, isso não significa que os links e as exigências de operação nele contidos sejam necessariamente seguros.
Especialmente quando envolve operações sensíveis, como atualizações de carteira, congelamento de contas, migração de ativos e correções de vulnerabilidades, é melhor não clicar diretamente nos links da mensagem, mas verificar proativamente por meio do endereço do site oficial que você salvou ou do App oficial que você já instalou.
Para carteiras não custodiais como a imToken, os usuários também precisam identificar os canais oficiais, usar token.im como base para download e instalação e, ao encontrar informações anormais, priorizar a verificação por meio de entradas oficiais, como "Ajuda e Feedback" no App.
Independentemente de a outra parte afirmar ser atendimento oficial, equipe de segurança ou fornecer uma explicação de vulnerabilidade aparentemente muito profissional, você nunca deve revelar a ela sua frase mnemônica ou chave privada.
Por fim, é necessário distinguir o impacto real de diferentes incidentes de segurança sobre você.
O vazamento de um endereço de e-mail significa principalmente que você pode enfrentar mais phishing direcionado no futuro; clicar em um link suspeito exige confirmação adicional sobre se programas maliciosos foram baixados ou executados; se uma frase mnemônica já foi inserida, isso deve ser tratado imediatamente como um vazamento do controle da carteira.
Se transações ou autorizações suspeitas já foram assinadas, também é necessário combinar as operações específicas on-chain para determinar se há risco contínuo de autorização de contrato.
Quanto a falhas de serviços de terceiros ou anormalidades de infraestrutura, é ainda mais necessário consultar o escopo de impacto divulgado oficialmente para determinar se envolve seus ativos, a disponibilidade do serviço ou retornos.
Você não pode presumir a conclusão de que a chave privada foi comprometida apenas porque ouviu falar de um "incidente de segurança de carteira", e certamente não deve transferir ativos precipitadamente para endereços desconhecidos por causa de supostas notificações urgentes de segurança.
Afinal, em muitos casos, o que os atacantes realmente esperam não é romper a linha de defesa técnica mais forte, mas fazer os usuários concluírem voluntariamente o último passo em pânico (Leitura adicional: "A IA "desafia" a criptografia? O Web3 deve se preparar para os dias de chuva, mas nunca deve se apressar em migrar").
Considerações Finais
No passado, a frase mais frequentemente enfatizada no setor de Crypto era "Not your keys, not your coins" (Não são suas chaves, não são suas moedas).
Essa frase continua importante, porque o controle da chave privada determina se os usuários podem realmente controlar seus ativos de forma independente.
Mas, à medida que carteiras, exchanges e produtos financeiros on-chain amadurecem gradualmente, também precisamos perceber que a proteção da chave privada é apenas parte de todo o sistema de segurança.
Uma carteira hardware genuína ainda pode ser fisicamente adulterada durante a entrega; uma notificação realmente enviada de um sistema de e-mail oficial também pode ser explorada por atacantes; e um conjunto de ferramentas de terceiros originalmente usado para reforçar a segurança pode até se tornar uma porta de entrada para o sistema central de fundos.
Esses casos não significam que devemos perder a confiança em todas as carteiras e serviços externos. Pelo contrário, eles lembram toda a indústria de que a segurança precisa ser estendida de dentro de um único produto para todo o processo de cadeia de suprimentos, gerenciamento de permissões, comunicação com o usuário e resposta a emergências.
Afinal, um sistema de segurança Crypto verdadeiramente maduro não deve apenas garantir que as chaves privadas não sejam facilmente vazadas, mas também garantir, na medida do possível, que mesmo se um determinado elo externo falhar, todo o mecanismo ainda possa deter firmemente o risco no meio do caminho e impedir que ele cruze a linha vermelha final de proteção dos ativos do usuário.
