Nos últimos anos, as carteiras de hardware têm sido vistas como uma das formas de armazenamento de chaves privadas relativamente seguras na indústria de blockchain. Após a geração da chave privada, ela é armazenada no chip de segurança (Secure Element) da carteira de hardware, sendo utilizada apenas para assinar informações que entram externamente. Este design de hardware fechado, que não pode se conectar à internet, aliado a um mecanismo de software que proíbe a exportação da chave privada, constrói uma poderosa barreira de proteção.
No entanto, essa arquitetura de segurança também tem seu "calcanhar de Aquiles" — — as carteiras de hardware dependem fortemente de software e canais de comunicação externos. Assim que esses componentes periféricos forem adulterados, os atacantes podem realizar um "ataque de intermediário" (MITM), substituindo informações sem que o usuário perceba, resultando em perdas de ativos.
O que é um ataque de intermediário
Um ataque de intermediário refere-se a um atacante que intervém secretamente entre as duas partes da comunicação, interceptando, alterando ou falsificando o conteúdo da comunicação entre ambas, enquanto as partes acreditam que estão a interagir diretamente.
Este tipo de ataque é comum em cenários de escuta de rede, falsificação de dados, roubo de identidade e substituição de endereço. É especialmente perigoso no campo dos ativos criptográficos, pois o atacante só precisa substituir um endereço para causar grandes perdas de ativos.
Um exemplo da vida cotidiana: você envia uma carta importante para um amigo. Um "mau carteiro" intercepta a carta durante o trajeto, substitui o conteúdo e a reenvia. Quando o amigo recebe a carta, as informações obtidas já não são precisas porque foram substituídas pelo carteiro.
Neste exemplo, o carteiro desempenhou o papel de intermediário, realizando um ataque de intermediário ao substituir o conteúdo da carta.
No sistema blockchain, como a maioria das transferências em cadeias públicas só requerem o endereço do destinatário, sem a necessidade de validações adicionais como o nome. Neste cenário, o ataque de intermediário é mais fácil de ser realizado, e as perdas geralmente são maiores e mais difíceis de recuperar.
Processo de comunicação da carteira de hardware: o carteiro invisível
Os principais carteiras de hardware no mercado utilizam basicamente quatro tipos de comunicação:
USB: o mais comum e estável, permitindo a transmissão bidirecional através de um cabo de dados
Bluetooth: Bluetooth de baixo consumo de energia BLE, comumente usado em dispositivos móveis
Código QR: airgap, uma forma relativamente nova, isolamento físico, alcançando a comunicação através da leitura mútua de códigos QR.
NFC: comunicação por proximidade, atualmente pouco utilizada
Entre eles, USB e Bluetooth são os mais comuns. Independentemente do método utilizado, o processo de comunicação é aproximadamente o mesmo:
O "cliente de carteira" inicia a conexão, como uma carteira de extensão de navegador ou uma carteira de aplicativo móvel.
Enviar uma solicitação para a "carteira de hardware", como obter o endereço interno do hardware, iniciar a assinatura, etc.
Solicitar que a entrega ao dispositivo de hardware seja feita através do "canal de comunicação" mencionado acima.
O dispositivo completou o processamento e retornou a resposta
O "cliente de carteira" recebe e exibe os resultados
Embora as carteiras de hardware sejam um "cofre" seguro, o processo de comunicação depende do cliente e do canal de comunicação, que funcionam como uma "cadeia de correios". Uma vez que o "carteiro" seja sequestrado ou aja de forma maliciosa, as informações de dados transmitidas podem já ter sido trocadas.
Esta é a ameaça secreta "Espada de Dâmocles" pairando sobre a carteira de hardware — ataque do intermediário.
Caso Prático: Ataque de Homem no Meio Baseado em Scripts Maliciosos
Declaração
Todo o código e operações ocorreram em setembro de 2023, mais de 20 meses após a data de publicação deste artigo (junho de 2025).
Todas as demonstrações são baseadas na versão oficial do software disponível na altura, e as informações específicas sobre a versão estão indicadas no texto.
Os métodos de ataque envolvidos foram divulgados e confirmados à equipe relevante na época.
Todo o conteúdo deste artigo é apenas para fins de aprendizado e pesquisa de segurança, e as opiniões representam apenas o autor.
Este artigo não se responsabiliza por quaisquer ações ou consequências resultantes disso.
O fluxo básico de comunicação do Trezor
A Trezor pode se comunicar através do Trezor Bridge ao conectar a carteira do navegador Metamask via USB, o fluxo básico do Trezor Bridge.
Após a instalação do software, será iniciado um servidor HTTP na porta local 21325 do computador do usuário.
Ao conectar a Metamask à carteira de hardware Trezor, uma página da web será exibida para carregar o SDK JS.
O SDK da Trezor tentará enviar dados serializados baseados em protobuf para este servidor local.
Após o Trezor Bridge receber os dados, ele procura dispositivos Trezor locais que atendem aos critérios de PID e VID através da biblioteca lib-usb e transfere os dados.
Quando o Trezor Bridge instalado localmente é detectado, todos os dados serializados através da web, ou seja, do Trezor SDK, serão encaminhados para o dispositivo através do servidor Trezor Bridge local, sem usar o Web USB.
Informações básicas sobre a Trezor Bridge
Trezor Bridge é desenvolvido em Golang, e a versão atual para usuários é v2.0.27.
A partir do repositório de código aberto do GitHub, pode-se ver que a v2.0.27 utiliza o xgo para compilar de forma cruzada, gerando pacotes de instalação para MacOS, Windows e Linux.
Por exemplo, no MacOS, durante a instalação, será criado o arquivo binário do servidor trezord no diretório /Applications/Utilities/TREZOR\ Bridge/trezord, e um arquivo com.bitcointrezor.trezorBridge.trezord.plist será criado localmente no usuário, permitindo que o KeepAlive implemente a inicialização automática e a proteção do processo.
Fluxo básico de ataque
Ao conectar o dispositivo Trezor ao Metamask, a chave pública ETH interna do dispositivo é lida imediatamente, e então, com base no número da sequência do endereço derivado, são calculados endereços de diferentes caminhos no software Metamask.
Durante este processo, não há qualquer confirmação ou aviso de hardware, o que fornece um caminho viável para um ataque de intermediário simples.
Uma vez que o Trezor Bridge esteja sob o controle de malware local, surgirá um "mau carteiro" em toda a cadeia de comunicação. O atacante poderá transformá-lo em um servidor de retransmissão, sequestrando todos os dados de comunicação com a carteira de hardware. Assim, os dados enviados para o hardware e os dados retornados do hardware podem ser alterados, causando uma inconsistência entre as informações exibidas na interface e as informações reais do hardware. Uma vez que haja uma vulnerabilidade no fluxo de software ou que as informações no hardware não sejam cuidadosamente verificadas, um ataque de homem no meio pode ser bem-sucedido.
Teste de Ataque
Primeiro, instale o Trezor Suite v23.8.1, o Trezor Bridge v2.0.27 e o Metamask v11.0.0
Prepare duas Trezor Model T: uma para operar normalmente e a outra para teste de ataque de intermediário.
Primeiro, mostre o fluxo normal: dois dispositivos podem ler corretamente o endereço tanto no Trezor Suite quanto no Metamask.
Executar scripts maliciosos para substituir o processo trezord
O primeiro dispositivo ainda consegue ler o endereço corretamente no Metamask, o processo está normal.
O endereço lido pelo segundo dispositivo no Metamask foi substituído por um intermediário, não coincidindo com o endereço exibido no Trezor Suite e no hardware.
Análise de Código
Adicionar marcadores de log em pontos críticos na Trezor Bridge para registrar os dados do corpo da solicitação e da resposta durante o processo de comunicação do dispositivo:
Na fase de leitura da chave pública do SDK, o hexbodyStr e o hexres são completamente iguais em parâmetros de operação e resultados retornados em momentos diferentes para o mesmo dispositivo em múltiplas chamadas. Através da filtragem dos logs, foi descoberto que os dados da chamada da função call quando o Metamask lê o endereço ETH são os seguintes:
De acordo com a comparação dos registos,
003700000000 e 000b0000001f08ac8080800808bc80808008088080808008080008002207426974636f696e são todos resultados da serialização de mensagens de envio e recepção.
Após os testes de replay, não existem parâmetros como timestamps no processo de construção das informações, o que permite simular métodos de ataque de forma muito simples, ou seja, visando partes das mensagens enviadas, codificando os resultados retornados e realizando a substituição dos resultados:
Neste exemplo, substituímos os dados de forma direcionada. Quando recebemos um pedido do SDK para obter a chave pública ETH, não usamos mais o resultado retornado pelo hardware, mas sim o resultado codificado diretamente no código acima. Compilamos novamente o documento para criar o arquivo binário, ao mesmo tempo que criamos componentes necessários para ataques, como o daemon.
Após a conclusão do trabalho preparatório, quando o usuário instala e executa acidentalmente o malware. Sempre que o usuário usa o Metamask para se conectar ao Trezor e enviar dados, os dados comunicados através da bridge não são mais as informações lidas do hardware, mas sim os dados serializados codificados no código acima. Com base na desserialização do SDK de negócios, as informações do endereço são lidas e substituídas com sucesso. O ataque completo é mostrado no vídeo acima.
Comunicação com a equipe
Depois de organizar as questões e operações, comuniquei-me imediatamente com as equipas da Metamask e Trezor. Abaixo estão todas as informações de comunicação e emails.
Registros de comunicação da Metamask:
Informações de comunicação por e-mail da Trezor:
O núcleo da questão e sugestões
Metamask lê o endereço completo, sem necessidade de confirmação de hardware
O hardware pode ser considerado um ambiente seguro e fechado, portanto, todas as informações devem ser baseadas no hardware. No entanto, no processo de design do produto Metamask, a informação em texto claro do endereço completo é lida e exibida diretamente, sem qualquer exibição do hardware.
O método ethereumGetAddress do Trezor SDK fornece o parâmetro showOnTrezor, cuja função é ler o endereço do hardware e exibi-lo no hardware para que o usuário possa confirmar novamente.
Esta é uma questão de compromisso no design de produtos. Se for necessário que o usuário confirme a leitura do endereço a cada vez, então, em cenários de adição em massa de endereços, o usuário terá muita dor. Assim, em aplicativos de suporte a carteiras de hardware, é suportada a leitura silenciosa de endereços, mas se o usuário quiser receber ativos, é necessário realizar primeiro a confirmação do endereço por hardware, a fim de prevenir a ocorrência do cenário de ataque mencionado.
Depois de ler silenciosamente o endereço do Metamask, ele exibiu o endereço completo sem pedir confirmação do usuário, o que pode facilmente levar os usuários que o usam pela primeira vez a serem atacados.
A ameaça da assinatura cega pode ser maior do que imaginamos
De acordo com este método e forma de ataque, podemos concluir que todas as informações de hardware não determinísticas são, teoricamente, inseguras.
Todos os signatures em modo cego seguem o mesmo princípio; embora o hardware de assinatura cega tenha uma confirmação, essa informação de confirmação não é legível para o usuário, portanto, também atende à informação de não determinístico do hardware, incapaz de garantir que não será atacado por intermediários.
O caso da carteira multi-assinatura segura é um exemplo típico, onde as informações de assinatura da estrutura da carteira foram substituídas por código javascript malicioso no servidor. Além disso, como a carteira Ledger utiliza assinatura cega, isso levou à ocorrência deste ataque.
Ataques de intermediários em canais de comunicação, com várias formas.
Além de o usuário local ter malware, alguns processos de comunicação e construção de carteiras podem envolver servidores (por exemplo, algumas carteiras precisam construir encodeTx através do servidor). Estes são potenciais alvos de ataque e pontos de ataque.
Os canais de comunicação incluem também a camada de hardware, como webcams não seguras, cabos USB inseguros, entre outros. Desde a camada física até à camada de aplicação, em termos de comunicação, todas as etapas estão suscetíveis a ataques.
Aumentar proativamente a consciência de segurança, a tarefa é árdua e longa
A comunicação completa do cliente para a carteira de hardware, em teoria, não precisa de estar conectada à rede. Portanto, mesmo com comunicação criptografada de ponta a ponta, não é possível garantir 100% a segurança do processo.
Após a adição de criptografia de ponta a ponta, para um verdadeiro hacker, o que aumenta é apenas o custo de reverter o cliente e quebrar o canal de comunicação. E quanto ao ataque em si, nunca se tratou de uma questão de dificuldade, mas sim da consideração dos custos que o hacker terá que suportar e das consequências legais.
Ao mesmo tempo, a maioria das equipes de produtos de blockchain geralmente coloca essa otimização em uma baixa prioridade durante toda a iteração quando enfrentam ameaças de ataques de intermediários, o que equivale a permitir que um certo nível de risco de ataque de intermediários ocorra. Como no e-mail de comunicação da equipe acima, a interface de bug bounty do Metamask exclui ataques de intermediários MITM:
Portanto, para os usuários, é ainda mais necessário que aumentemos proativamente nossa própria conscientização sobre prevenção. Para ativos importantes, mesmo ao usar carteiras de hardware, é melhor isolar o computador, não se conectar a redes não confiáveis, não acessar páginas da web não confiáveis, etc.
Escrito no final
O "mito da segurança" das carteiras de hardware não vem de um único dispositivo em si, mas é construído sobre a segurança colaborativa de todo o ecossistema.
Quando ignoramos a confiabilidade do cliente e relaxamos a proteção dos canais de comunicação, a "Espada de Dâmocles" fica silenciosamente pendurada sobre os nossos ativos.
A verdadeira segurança não se resume apenas ao hardware, mas está em cada um dos detalhes que você considera "irrelevantes".
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
A espada de Dâmocles na carteira de hardware: a ameaça secreta do intermediário
Autor: Revan Zhang Fonte: Medium
Nos últimos anos, as carteiras de hardware têm sido vistas como uma das formas de armazenamento de chaves privadas relativamente seguras na indústria de blockchain. Após a geração da chave privada, ela é armazenada no chip de segurança (Secure Element) da carteira de hardware, sendo utilizada apenas para assinar informações que entram externamente. Este design de hardware fechado, que não pode se conectar à internet, aliado a um mecanismo de software que proíbe a exportação da chave privada, constrói uma poderosa barreira de proteção.
No entanto, essa arquitetura de segurança também tem seu "calcanhar de Aquiles" — — as carteiras de hardware dependem fortemente de software e canais de comunicação externos. Assim que esses componentes periféricos forem adulterados, os atacantes podem realizar um "ataque de intermediário" (MITM), substituindo informações sem que o usuário perceba, resultando em perdas de ativos.
O que é um ataque de intermediário
Um ataque de intermediário refere-se a um atacante que intervém secretamente entre as duas partes da comunicação, interceptando, alterando ou falsificando o conteúdo da comunicação entre ambas, enquanto as partes acreditam que estão a interagir diretamente.
Este tipo de ataque é comum em cenários de escuta de rede, falsificação de dados, roubo de identidade e substituição de endereço. É especialmente perigoso no campo dos ativos criptográficos, pois o atacante só precisa substituir um endereço para causar grandes perdas de ativos.
Um exemplo da vida cotidiana: você envia uma carta importante para um amigo. Um "mau carteiro" intercepta a carta durante o trajeto, substitui o conteúdo e a reenvia. Quando o amigo recebe a carta, as informações obtidas já não são precisas porque foram substituídas pelo carteiro.
Neste exemplo, o carteiro desempenhou o papel de intermediário, realizando um ataque de intermediário ao substituir o conteúdo da carta.
No sistema blockchain, como a maioria das transferências em cadeias públicas só requerem o endereço do destinatário, sem a necessidade de validações adicionais como o nome. Neste cenário, o ataque de intermediário é mais fácil de ser realizado, e as perdas geralmente são maiores e mais difíceis de recuperar.
Processo de comunicação da carteira de hardware: o carteiro invisível
Os principais carteiras de hardware no mercado utilizam basicamente quatro tipos de comunicação:
Entre eles, USB e Bluetooth são os mais comuns. Independentemente do método utilizado, o processo de comunicação é aproximadamente o mesmo:
Embora as carteiras de hardware sejam um "cofre" seguro, o processo de comunicação depende do cliente e do canal de comunicação, que funcionam como uma "cadeia de correios". Uma vez que o "carteiro" seja sequestrado ou aja de forma maliciosa, as informações de dados transmitidas podem já ter sido trocadas.
Caso Prático: Ataque de Homem no Meio Baseado em Scripts Maliciosos
Declaração
O fluxo básico de comunicação do Trezor
A Trezor pode se comunicar através do Trezor Bridge ao conectar a carteira do navegador Metamask via USB, o fluxo básico do Trezor Bridge.
Quando o Trezor Bridge instalado localmente é detectado, todos os dados serializados através da web, ou seja, do Trezor SDK, serão encaminhados para o dispositivo através do servidor Trezor Bridge local, sem usar o Web USB.
Informações básicas sobre a Trezor Bridge
Trezor Bridge é desenvolvido em Golang, e a versão atual para usuários é v2.0.27.
A partir do repositório de código aberto do GitHub, pode-se ver que a v2.0.27 utiliza o xgo para compilar de forma cruzada, gerando pacotes de instalação para MacOS, Windows e Linux.
Por exemplo, no MacOS, durante a instalação, será criado o arquivo binário do servidor trezord no diretório /Applications/Utilities/TREZOR\ Bridge/trezord, e um arquivo com.bitcointrezor.trezorBridge.trezord.plist será criado localmente no usuário, permitindo que o KeepAlive implemente a inicialização automática e a proteção do processo.
Fluxo básico de ataque
Ao conectar o dispositivo Trezor ao Metamask, a chave pública ETH interna do dispositivo é lida imediatamente, e então, com base no número da sequência do endereço derivado, são calculados endereços de diferentes caminhos no software Metamask.
Durante este processo, não há qualquer confirmação ou aviso de hardware, o que fornece um caminho viável para um ataque de intermediário simples.
Uma vez que o Trezor Bridge esteja sob o controle de malware local, surgirá um "mau carteiro" em toda a cadeia de comunicação. O atacante poderá transformá-lo em um servidor de retransmissão, sequestrando todos os dados de comunicação com a carteira de hardware. Assim, os dados enviados para o hardware e os dados retornados do hardware podem ser alterados, causando uma inconsistência entre as informações exibidas na interface e as informações reais do hardware. Uma vez que haja uma vulnerabilidade no fluxo de software ou que as informações no hardware não sejam cuidadosamente verificadas, um ataque de homem no meio pode ser bem-sucedido.
Teste de Ataque
Análise de Código
Adicionar marcadores de log em pontos críticos na Trezor Bridge para registrar os dados do corpo da solicitação e da resposta durante o processo de comunicação do dispositivo:
Na fase de leitura da chave pública do SDK, o hexbodyStr e o hexres são completamente iguais em parâmetros de operação e resultados retornados em momentos diferentes para o mesmo dispositivo em múltiplas chamadas. Através da filtragem dos logs, foi descoberto que os dados da chamada da função call quando o Metamask lê o endereço ETH são os seguintes:
De acordo com a comparação dos registos,
003700000000 e 000b0000001f08ac8080800808bc80808008088080808008080008002207426974636f696e são todos resultados da serialização de mensagens de envio e recepção.
Após os testes de replay, não existem parâmetros como timestamps no processo de construção das informações, o que permite simular métodos de ataque de forma muito simples, ou seja, visando partes das mensagens enviadas, codificando os resultados retornados e realizando a substituição dos resultados:
Neste exemplo, substituímos os dados de forma direcionada. Quando recebemos um pedido do SDK para obter a chave pública ETH, não usamos mais o resultado retornado pelo hardware, mas sim o resultado codificado diretamente no código acima. Compilamos novamente o documento para criar o arquivo binário, ao mesmo tempo que criamos componentes necessários para ataques, como o daemon.
Após a conclusão do trabalho preparatório, quando o usuário instala e executa acidentalmente o malware. Sempre que o usuário usa o Metamask para se conectar ao Trezor e enviar dados, os dados comunicados através da bridge não são mais as informações lidas do hardware, mas sim os dados serializados codificados no código acima. Com base na desserialização do SDK de negócios, as informações do endereço são lidas e substituídas com sucesso. O ataque completo é mostrado no vídeo acima.
Comunicação com a equipe
Depois de organizar as questões e operações, comuniquei-me imediatamente com as equipas da Metamask e Trezor. Abaixo estão todas as informações de comunicação e emails.
O núcleo da questão e sugestões
Metamask lê o endereço completo, sem necessidade de confirmação de hardware
O hardware pode ser considerado um ambiente seguro e fechado, portanto, todas as informações devem ser baseadas no hardware. No entanto, no processo de design do produto Metamask, a informação em texto claro do endereço completo é lida e exibida diretamente, sem qualquer exibição do hardware.
O método ethereumGetAddress do Trezor SDK fornece o parâmetro showOnTrezor, cuja função é ler o endereço do hardware e exibi-lo no hardware para que o usuário possa confirmar novamente.
Esta é uma questão de compromisso no design de produtos. Se for necessário que o usuário confirme a leitura do endereço a cada vez, então, em cenários de adição em massa de endereços, o usuário terá muita dor. Assim, em aplicativos de suporte a carteiras de hardware, é suportada a leitura silenciosa de endereços, mas se o usuário quiser receber ativos, é necessário realizar primeiro a confirmação do endereço por hardware, a fim de prevenir a ocorrência do cenário de ataque mencionado.
Depois de ler silenciosamente o endereço do Metamask, ele exibiu o endereço completo sem pedir confirmação do usuário, o que pode facilmente levar os usuários que o usam pela primeira vez a serem atacados.
A ameaça da assinatura cega pode ser maior do que imaginamos
De acordo com este método e forma de ataque, podemos concluir que todas as informações de hardware não determinísticas são, teoricamente, inseguras.
Todos os signatures em modo cego seguem o mesmo princípio; embora o hardware de assinatura cega tenha uma confirmação, essa informação de confirmação não é legível para o usuário, portanto, também atende à informação de não determinístico do hardware, incapaz de garantir que não será atacado por intermediários.
O caso da carteira multi-assinatura segura é um exemplo típico, onde as informações de assinatura da estrutura da carteira foram substituídas por código javascript malicioso no servidor. Além disso, como a carteira Ledger utiliza assinatura cega, isso levou à ocorrência deste ataque.
Ataques de intermediários em canais de comunicação, com várias formas.
Além de o usuário local ter malware, alguns processos de comunicação e construção de carteiras podem envolver servidores (por exemplo, algumas carteiras precisam construir encodeTx através do servidor). Estes são potenciais alvos de ataque e pontos de ataque.
Os canais de comunicação incluem também a camada de hardware, como webcams não seguras, cabos USB inseguros, entre outros. Desde a camada física até à camada de aplicação, em termos de comunicação, todas as etapas estão suscetíveis a ataques.
Aumentar proativamente a consciência de segurança, a tarefa é árdua e longa
A comunicação completa do cliente para a carteira de hardware, em teoria, não precisa de estar conectada à rede. Portanto, mesmo com comunicação criptografada de ponta a ponta, não é possível garantir 100% a segurança do processo.
Após a adição de criptografia de ponta a ponta, para um verdadeiro hacker, o que aumenta é apenas o custo de reverter o cliente e quebrar o canal de comunicação. E quanto ao ataque em si, nunca se tratou de uma questão de dificuldade, mas sim da consideração dos custos que o hacker terá que suportar e das consequências legais.
Ao mesmo tempo, a maioria das equipes de produtos de blockchain geralmente coloca essa otimização em uma baixa prioridade durante toda a iteração quando enfrentam ameaças de ataques de intermediários, o que equivale a permitir que um certo nível de risco de ataque de intermediários ocorra. Como no e-mail de comunicação da equipe acima, a interface de bug bounty do Metamask exclui ataques de intermediários MITM:
Portanto, para os usuários, é ainda mais necessário que aumentemos proativamente nossa própria conscientização sobre prevenção. Para ativos importantes, mesmo ao usar carteiras de hardware, é melhor isolar o computador, não se conectar a redes não confiáveis, não acessar páginas da web não confiáveis, etc.
Escrito no final
O "mito da segurança" das carteiras de hardware não vem de um único dispositivo em si, mas é construído sobre a segurança colaborativa de todo o ecossistema.
Quando ignoramos a confiabilidade do cliente e relaxamos a proteção dos canais de comunicação, a "Espada de Dâmocles" fica silenciosamente pendurada sobre os nossos ativos.
A verdadeira segurança não se resume apenas ao hardware, mas está em cada um dos detalhes que você considera "irrelevantes".