Os usuários canadenses representam 25% das perdas decorrentes da vulnerabilidade do Coldcard

Distribuição geográfica das perdas

Os detentores canadenses de bitcoins surgiram como o maior grupo demográfico afetado pela exploração em andamento da carteira de hardware Coldcard, arcando com 25% de todas as perdas atribuíveis. Analistas observam que essa forte concentração regional está alinhada com a sólida presença local da empresa controladora da Coldcard, a Coinkite, cuja sede fica em Toronto.

De acordo com o rastreamento visual da Chainalysis, a Austrália ocupa o segundo lugar entre os países mais severamente afetados, respondendo por 15% a 20% do total dos prejuízos. Enquanto isso, os Estados Unidos e a Tailândia vêm logo em seguida, com perdas na faixa de 10% a 15%. Embora a violação tenha atingido mais fortemente as jurisdições de língua inglesa e as que adotaram o bitcoin desde o início, os dados destacam um amplo impacto global na Europa Ocidental, na América Latina e nos principais centros de criptomoedas da África, como a Nigéria e a África do Sul.

O total de ativos roubados decorrentes do incidente chegou a US$ 116 milhões. Em uma análise da violação, a Galaxy Research identificou uma atualização de firmware de março de 2021 — especificamente a implementação de um novo gerador de números aleatórios — como o único ponto de falha que possibilitou o ataque.

“O problema foi que ele foi configurado incorretamente e, por padrão, passou a usar um gerador mais fraco. A falha ocorreu silenciosamente, sem nenhum aviso. Ninguém sabia que suas chaves privadas estavam sendo geradas com baixa entropia”, afirmou a Galaxy Research. “Cinco anos depois, um invasor roubou US$ 70 milhões de 1.200 carteiras em 41 minutos.”

Ao explicar como as verificações padrão não detectaram o bug por mais de cinco anos, Natalie Newson, investigadora sênior de blockchain da CertiK, revelou que a causa raiz decorreu de um erro específico de configuração: MICROPY_HW_ENABLE_RNG estava definido como zero.

“Para uma verificação estática do #ifndef, uma macro definida como 0 ainda é considerada definida”, explicou Newson. “A verificação de segurança retornou ‘true’, suprimindo a verificação #error e permitindo que o sistema de compilação prosseguisse como se tudo estivesse configurado corretamente.”

Protocolos de resposta a incidentes e correção de emergência

Para evitar recuos silenciosos semelhantes à pseudoaleatoriedade de software, Newson instou os fabricantes a revisarem seus padrões arquitetônicos. “O controle mais eficaz é remover o recurso de fallback da produção e ter exatamente um provedor de RNG aprovado”, enfatizou ela, observando que todo o caminho, desde a aquisição de entropia até a geração da semente, deve estar estritamente dentro de um limite de validação definido pela norma NIST FIPS 140-3.

Ao gerenciar o risco operacional de lançar patches de emergência às pressas enquanto varreduras automatizadas ativas ocorrem, Newson ressaltou que a resposta a incidentes deve priorizar a comunicação com os usuários juntamente com os testes técnicos.

“A prioridade deve ser comunicar imediatamente o escopo da vulnerabilidade, identificar os usuários afetados e fornecer orientações claras de mitigação, ao mesmo tempo em que se valida minuciosamente qualquer correção antes do lançamento”, afirmou Newson, acrescentando que a transparência é tão crítica quanto o próprio patch.

Para usuários sem conhecimentos técnicos que possuam frases-semente comprometidas e temam danificar seus dispositivos durante atualizações de firmware de emergência, Newson recomendou um protocolo de correção rigoroso: primeiro, os usuários devem adquirir uma carteira de hardware confiável, gerar uma nova frase-semente offline e verificar a configuração com uma pequena transação de teste. Em seguida, devem transferir todos os fundos restantes para a configuração recém-verificada antes de tentar qualquer atualização de firmware no dispositivo original.

Newson também instou os usuários a evitar a criação de um único ponto de falha, utilizando carteiras de hardware de diferentes fabricantes para distribuir o risco por várias contas.

Um ponto de inflexão para as narrativas sobre autocustódia

O incidente deixou o setor de autocustódia e seus defensores diante de questões fundamentais sobre os modelos padrão de segurança. Críticos apontam a repentina perda de ativos inativos de longo prazo como evidência de que a execução offline, por si só, não garante proteção absoluta.

Nanak Nihal Khalsa, cofundador da Human.tech, argumentou que o incidente ressalta a realidade persistente do risco de terceiros dentro dos ecossistemas de hardware.

“A frase ‘Não são suas chaves, não são suas moedas’ ignora um fato importante: você está sempre terceirizando a confiança, mesmo com a autocustódia. Isso apenas acrescenta mais um ponto de evidência de que a autocustódia não altera esse fato”, observou Khalsa, alertando que vetores de ameaça emergentes, como explorações assistidas por IA, provavelmente agravarão esses riscos.

Newson, da CertiK, ecoou as preocupações em relação às configurações de assinatura única, observando que a adoção em larga escala requer sistemas construídos com degradação gradual, nos quais um único erro — cometido por um usuário ou por um fornecedor — não destrua as economias de uma vida inteira do usuário.

“A autocustódia com assinatura única não oferece margem para erros”, disse Newson. “Os usuários que dependem de um único dispositivo estão confiando no hardware físico, no código e em todas as suas dependências, bem como nas verificações de controle de qualidade para detectar quaisquer problemas.”

Consequentemente, o consenso do setor está mudando em direção a configurações com múltiplos fornecedores, assinaturas múltiplas ou assinatura por limiar (MPC) como um padrão mínimo obrigatório.

“Sim, esse deve ser o padrão padrão”, concluiu Newson. “O objetivo é passar de ‘confiar em um único dispositivo’ para garantir que nenhum componente ou agente comprometido possa movimentar os fundos. Na prática, as chaves de assinatura ou as partes do limiar devem abranger domínios independentes de falhas organizacionais e tecnológicas, de modo que nenhum provedor possa reconstruir a chave ou autorizar uma transação sozinho.”