Randstorm: vulnerabilidade das carteiras criptográficas da década de 2010

Pesquisadores identificaram diversas vulnerabilidades na biblioteca BitcoinJS, expondo as carteiras Bitcoin criadas online há uma década a possíveis ataques de hackers. O problema principal é que as chaves privadas dessas carteiras criptográficas foram geradas com uma previsibilidade muito maior do que os desenvolvedores da biblioteca esperavam.

Vulnerabilidades e consequências do Randstorm

Vamos começar do início. Pesquisadores da Unciphered, uma empresa especializada em recuperação de acesso a carteiras criptográficas, descobriram e descreveram uma série de vulnerabilidades na biblioteca JavaScript BitcoinJS usada por muitas plataformas de criptomoedas on-line. Entre esses serviços estão alguns muito populares, em particular, o Blockchain.info, agora conhecido como Blockchain.com. Os pesquisadores apelidaram esse conjunto de vulnerabilidades de Randstorm.

Embora as vulnerabilidades na biblioteca BitcoinJS tenham sido corrigidas em 2014, o problema persiste nos resultados do uso dessa biblioteca. Carteiras criptográficas criadas com BitcoinJS no início da década de 2010 podem ser inseguras, pois é consideravelmente mais fácil encontrar as chaves privadas do que a criptografia subjacente do Bitcoin assume.

Os pesquisadores estimam que vários milhões de carteiras, totalizando cerca de 1,4 milhão de BTC, estão potencialmente em risco devido ao Randstorm. Entre as carteiras potencialmente vulneráveis, segundo os pesquisadores, 3 a 5% delas são realmente vulneráveis a ataques de fato. Com base na taxa de câmbio aproximada do Bitcoin de cerca de US$ 36.500 no momento da publicação, isso implica um saque total de US$ 1,5 a 2,5 bilhões para os invasores que venham a explorar com sucesso o Randstorm.

Os pesquisadores afirmam que as vulnerabilidades do Randstorm podem de fato ser usadas para ataques do mundo real em carteiras criptográficas. Além disso, eles exploraram com sucesso essas vulnerabilidades para restaurar o acesso a várias carteiras criptográficas criadas no Blockchain.info antes de março de 2012. Por motivos éticos, eles não publicaram uma prova de conceito do ataque, pois isso teria exposto diretamente dezenas de milhares de carteiras criptográficas ao risco de roubo.

Os pesquisadores já entraram em contato com os serviços de criptomoeda on-line que sabidamente usam versões vulneráveis da biblioteca BitcoinJS. Por sua vez, esses serviços notificaram os clientes que poderiam ser afetados pelo Randstorm.

A natureza das vulnerabilidades do Randstorm

Vamos examinar mais detalhadamente como essas vulnerabilidades realmente funcionam. No coração da segurança da carteira Bitcoin está a chave privada. Como qualquer sistema criptográfico moderno, o Bitcoin depende dessa chave ser secreta e indecifrável. Novamente, como em qualquer sistema criptográfico moderno, isso envolve o uso de números aleatórios muito longos.

E para a segurança de quaisquer dados protegidos pela chave privada, eles devem ser tão aleatórios quanto possível. Se o número usado como chave for altamente previsível, será mais fácil e rápido para um invasor armado com informações sobre o procedimento de geração de chave forçá-lo.

Tenha em mente que gerar um número verdadeiramente aleatório não é tão fácil assim. E os computadores, por sua natureza, são extremamente inadequados para a tarefa, pois são muito previsíveis. Portanto, o que geralmente temos são números pseudoaleatórios e, para aumentar a entropia da geração (termo do criptógrafo para a medida da imprevisibilidade), contamos com funções especiais.

Agora, de volta à biblioteca BitcoinJS. Para obter números pseudoaleatórios de “alta qualidade”, essa biblioteca usa outra biblioteca JavaScript chamada JSBN (JavaScript Big Number), especificamente sua função SecureRandom. Como o próprio nome sugere, essa função foi projetada para gerar números pseudoaleatórios que se qualificam para uso em criptografia. Para aumentar sua entropia, o SecureRandom conta com a função de navegador window.crypto.random.

É aí que reside o problema: embora a função window.crypto.random existisse na família de navegadores Netscape Navigator 4.x, esses navegadores já estavam obsoletos quando os serviços da Web começaram a usar ativamente a biblioteca BitcoinJS. E nos navegadores populares da época — Internet Explorer, Google Chrome, Mozilla Firefox e Apple Safari — a função window.crypto.random simplesmente não foi implementada.

Infelizmente, os desenvolvedores da biblioteca JSBN não anteciparam a inclusão de qualquer forma de verificação ou mensagem de erro correspondente. Como resultado, a função SecureRandom passou pela etapa de incremento de entropia em silêncio, efetivamente transferindo a tarefa de criar chaves privadas para o gerador de números pseudoaleatórios padrão, Math.random.

Isso é péssimo, pois o Math.random não foi desenvolvido para fins criptográficos. Mas a situação é ainda mais complicada pelo fato de que a implementação do Math.random nos navegadores populares de 2011 a 2015, em particular no Google Chrome, continha bugs que resultaram em números ainda menos aleatórios do que deveria ter sido o caso.

Por sua vez, a biblioteca BitcoinJS herdou todos os problemas mencionados acima do JSBN. Assim, as plataformas que a utilizaram para gerar chaves privadas para carteiras criptográficas receberam uma quantidade muito menor de números aleatórios da função SecureRandom do que o previsto pelos desenvolvedores da biblioteca. E, devido à alta previsibilidade na geração dessas chaves, tornam-se mais suscetíveis a violações, facilitando o acesso não autorizado a carteiras de criptomoedas vulneráveis.

Como mencionado, esse não é um perigo teórico, mas bastante prático. A equipe da Unciphered conseguiu explorar essas vulnerabilidades para restaurar o acesso a (em outras palavras, hackear eticamente) várias carteiras criptográficas antigas criadas no Blockchain.info.

Quem corre riscos relacionados ao Randstorm

BitcoinJS utilizou a biblioteca JSBN vulnerável desde sua introdução em 2011 até 2014. Observe, no entanto, que alguns projetos de criptomoeda podem estar usando há algum tempo uma versão desatualizada da biblioteca. Quanto aos problemas encontrados no Math.random em navegadores populares, foram corrigidos em 2016 por meio da alteração dos algoritmos utilizados na geração de números pseudoaleatórios. No geral, temos um intervalo aproximado entre 2011 e 2015 quando as carteiras criptográficas potencialmente vulneráveis foram criadas.

Os pesquisadores enfatizam que a BitcoinJS era muito popular no início da década de 2010, por isso é difícil compilar uma lista completa de serviços que poderiam ter usado uma versão vulnerável dela. O relatório fornece uma lista de plataformas em que foi possível identificar riscos:

• BitAddress — ainda operacional.
• BitCore (BitPay) — ainda operacional.
• Bitgo — ainda operacional.
• info — ainda operacional como Blockchain.com.
• Blocktrail — redireciona para https://btc.com ou https://blockchair.com .
• BrainWallet — inativa.
• CoinKite — agora vende carteiras de hardware.
• CoinPunk — inativa.
• Dark Wallet — redireciona para https://crypto-engine.org .
• DecentralBank — inativa.
• info (Block.io) — ainda operacional.
• EI8HT — inativo.
• GreenAddress — redireciona para https://blockstream.com/green/ .
• QuickCon — inativo.
• Robocoin — inativo.
• Skyhook ATM — redireciona para https://yuan-pay-group.net .

Além das carteiras Bitcoin, as carteiras Litecoin, Zcash e Dogecoin também podem estar em risco, pois também existem bibliotecas baseadas em BitcoinJS para essas criptomoedas. Parece natural supor que essas bibliotecas podem ser usadas para gerar chaves privadas para as respectivas carteiras criptográficas.

O relatório da Unciphered descreve uma série de outras complexidades associadas ao Randstorm. Contudo, em resumo, as carteiras criadas entre 2011 e 2015 usando a biblioteca vulnerável podem ser vulneráveis em graus variados, dependendo das circunstâncias específicas.

Como se proteger do Randstorm

Como os próprios pesquisadores afirmam, a correção da vulnerabilidade no software não seria suficiente: não é possível “corrigir” as chaves privadas dos proprietários da carteira nem as substituir por chaves seguras. Portanto, apesar do fato de os bugs terem sido corrigidos há muito tempo, eles continuam afetando as carteiras criptográficas criadas quando os erros discutidos acima afligiam a biblioteca BitcoinJS. Isso significa que os próprios proprietários de carteiras vulneráveis precisam tomar medidas de proteção.

Como a tarefa de elaborar uma lista completa de plataformas de criptomoedas que usaram a biblioteca vulnerável é difícil, é melhor se precaver e considerar qualquer carteira criptográfica criada on-line entre 2011 e 2015 como potencialmente insegura (a menos que você tenha certeza de que não é). E, naturalmente, quanto mais gorda a carteira, mais tentadora ela é para os criminosos.

A solução óbvia (e única) para o problema é criar carteiras criptográficas novas e mover para elas todos os fundos das carteiras potencialmente vulneráveis.

E como você tem que fazer isso de qualquer maneira, faz sentido proceder com o máximo de cautela desta vez. A proteção criptográfica é um processo de várias etapas, motivo pelo qual montamos uma lista de verificação abrangente para você com muitas informações adicionais acessíveis pelos links:

1. Explore detalhadamente as principais ameaças criptográficas e os métodos de proteção.
2. Entenda as diferenças entre carteiras criptográficas quentes e frias e as formas mais comuns de atacá-las.
3. Use uma carteira (fria) de hardware para armazenamento de longo prazo dos principais ativos criptográficos e uma carteira quente com fundos mínimos para transações diárias.
4. Antes de transferir todos os fundos da carteira antiga para a nova, equipe todos os seus dispositivos com proteção confiável. Isso protegerá seu smartphone ou computador contra cavalos de Troia que procuram roubar senhas e chaves privadas ou clippers que substituem endereços de carteira criptográfica na área de transferência, bem como protegerá seu computador contra mineradores de criptomoedas maliciosos e acesso remoto não autorizado.
5. Nunca armazene uma foto ou captura de tela de sua seed phrase no smartphone, nunca guarde sua seed phrase em nuvens públicas, nunca a envie por mensageiros ou e-mail e não a insira em nenhum lugar, exceto ao recuperar uma chave privada perdida.
6. Armazene com segurança sua chave privada e a seed phrase para sua recuperação. Isso pode ser feito usando a Carteira de Proteção de Identidade no Kaspersky Premium, que criptografa todos os dados armazenados usando AES-256. A senha dela não fica armazenada em lugar nenhum, exceto em sua cabeça (a menos, é claro, que esteja em uma nota adesiva colada ao seu monitor) e é irrecuperável. Portanto, o único com acesso aos seus documentos pessoais é você.
7. Outra opção é usar uma carteira de criptografia fria, que não requer uma seed phrase para fazer backup da chave privada. É assim que, por exemplo, a carteira de hardware Tangem  funciona.