Se você usou uma chave privada gerada no site WalletGenerator.net após 17 de agosto de 2018, transfira seus fundos imediatamente para um endereço seguro.

• Quem é afetado: qualquer pessoa que tenha colocado fundos em uma chave pública/privada gerada por meio do WalletGenerator.net depois de 17 de agosto de 2018.
• Quando: 17 de agosto de 2018 – ???. Embora o comportamento malicioso não seja encontrado atualmente em 24 de maio de 2019, ele pode ser reintroduzido a qualquer momento.
• O que aconteceu: houve alterações no código sendo veiculado por meio do site WalletGenerator.net que resultou na entrega de pares de chaves duplicados aos usuários. Estes keypairs (par de chaves) gerados também foram potencialmente armazenados no lado do servidor.
• O que você deve fazer se for afetado: crie com segurança um novo par de chaves/carteira e transfira seus fundos para esse endereço novo e seguro. Algumas pessoas recomendaram o uso do bitaddress (offline) via https://github.com/pointbiz/bitaddress.org .

Prefácio

Conseguimos entrar em contato com o proprietário atual do site antes de publicar este post e descrevemos algumas de nossas descobertas na esperança de que elas protegessem o servidor e ajudassem na investigação. Eles responderam declarando que não conseguiam confirmar nossas reivindicações e perguntando se talvez estivéssemos em um site de phishing.

Em algum momento entre a última vez em que investigamos e testamos (na noite de 22 de maio de 2019) e o momento em que recebemos uma resposta por e-mail do proprietário do site atual (meio dia, 23 de maio de 2019), o código sendo exibido no site foi modificado para remover o código mal-intencionado adicionado anteriormente.

Nessa estranha reviravolta de eventos, ainda não temos ideia se o proprietário do site atual é a parte maliciosa, se o servidor é inseguro ou ambos.

Ainda estamos considerando esse altamente suspeito e ainda recomendamos usuários que geraram pares de chaves públicas/ privadas após 17 de agosto de 2018 para movimentar seus fundos. Não recomendamos o uso do WalletGenerator.net no futuro, mesmo que o código neste exato momento não seja vulnerável.

A versão longa

As interfaces de carteira de papel são uma ferramenta super útil e conveniente para os usuários gerarem facilmente um par dechaves públicas/ privadas, embora essas interfaces tenham sido suscetíveis a vulnerabilidades na derivação de chave/RNG devido ao comportamento malicioso ou ignorante conduzido internamente pelos proprietários do site ou externamente por maus atores. Se o gerador de números aleatórios for comprometido de alguma forma, pode resultar (e resultou) em segredos adivinhados, o que pode, por sua vez, resultar na perda de fundos do usuário.

Foi o que aconteceu com o WalletGenerator.net.

Detalhes do Comprometimento

O WalletGenerator é um site que gera carteiras de papel para um punhado de criptomoedas diferentes. O código servido para WalletGenerator.net destina-se a ser de código aberto e auditado, e (supostamente) corresponde ao código aqui: https://github.com/walletgeneratornet/WalletGenerator.net .

Este projeto mudou de propriedade há aproximadamente dois anos. Recentemente, foi trazido à nossa atenção que o código que está sendo veiculado por meio do URL do WalletGenerator.net não correspondia ao código no GitHub.

No momento, o código no GitHub não é malicioso nem vulnerável, nem foi malicioso ou vulnerável anteriormente.

Não está claro neste momento se o novo proprietário é responsável por essas alterações de código ou se o servidor foi comprometido por uma parte externa.

O código muda

Nós investigamos as diferenças executando um diff entre o código do GitHub e o código do servidor e notamos (entre outras coisas) que uma solicitação de XHR está sendo executada para capturar a imagem da moeda. Isso é estranho porque a imagem da moeda já está sendo baixada pelo seu navegador quando você carrega a página HTML – não deve ser necessário solicitá-la novamente.

Analisamos o código para ver por que ele está enviando uma solicitação de XHR e o que descobrimos foi bizarro. Está usando os dados da imagem para semear a função do gerador de números aleatórios.

Isso imediatamente levantou nossas suspeitas porque a função SecureRandom deveria estar recebendo informações do navegador do usuário/interações, não de uma imagem ou servidor. A sua propagação com dados do servidor compromete a integridade da aleatoriedade, potencialmente tornando as chaves geradas não aleatórias ou produzíveis.

ELI5: Ao gerar uma chave, você pega um número super-aleatório, transforma-o na chave privada e o transforma na chave pública/endereço. No entanto, se o número “super aleatório” for sempre “5”, a chave privada gerada será sempre a mesma. É por isso que é tão importante que o número super-aleatório seja aleatório … não “5.” 😉

Além disso, uma nova função SecureRandomAdvancedfoi adicionado que modifica (que remove poolCopyOnInitlógica) a funçãoSecureRandompreviamente utilizado em bitaddress.org . A saída desta função SecureRandomAdvanced substitui a função SecureRandom. Embora o usuário ainda seja solicitado a mover o mouse pela tela, esses dados nunca são usados ​​para propagar a geração de chaves.

De volta ao pedido de imagem estranho

Mergulhando mais fundo no próprio arquivo de imagem, notamos que o arquivo era extraordinariamente grande e produzia um diferente sha256sumpara partes diferentes. Neste ponto, parece que a imagem sendo servida pelo servidor foi 1) única para cada usuário (endereço IP?) E 2) sendo usada para propagar a geração da chave.

Nós criamos algumas VPNs e acessamos o domínio de várias localizações geográficas. Abaixo está um dump dos hashes sha256sum do arquivo bitcoin.png:

$ sha256sum bitcoin.png (Reino Unido) 
27cfafd3fe3810a89375a2f3ccc253cd6b2f03b5ff30ec6b41a76f8f2393085d local.png 
$ du -hs bitcoin.png 
156K bitcoin.png

$ sha256sum bitcoin.png (Holanda) 
4798d4167a98b56dc112878aed578f64ff9fb20fc58774a468e9b53f9aa1fc59 nl.png 
$ du -hs bitcoin.png 
16K bitcoin.png

$ sha256sum bitcoin.png (Califórnia) 
4798d4167a98b56dc112878aed578f64ff9fb20fc58774a468e9b53f9aa1fc59 na_cali.png 
$ du-hs bitcoin.png 
16K bitcoin.png

$ sha256sum bitcoin.png (N. Virgínia e Leste-1) 
86b475b38b137e50e317ce4478cc9abf41d33c158e12d2174dc1dd6f786ec45f onvpn.png 
$ du -hs bitcoin.png 
156K bitcoin.png

$ sha256sum bitcoin.png (Espanha) 
4798d4167a98b56dc112878aed578f64ff9fb20fc58774a468e9b53f9aa1fc59 offvpn.png 
$ du -hs bitcoin.png 
16K bitcoin.png

Isso nos levou a uma conclusão de que essas imagens são servidas a uma porcentagem determinística dos visitantes, provavelmente com base no IP.

O bitcoin.png com o hash 479...c59e um tamanho de arquivo de 16K é o ícone bitcoin.png não modificado. Os outros hashes e arquivos com um tamanho de arquivo de 156K são modificados de alguma forma e provavelmente armazenados no servidor, a fim de gerar novamente os pares de chaves em uma data posterior e roubar fundos.

Gere todas as chaves

Aproximando-se de um ângulo diferente, usamos o gerador “Bulk Wallet” para gerar 1.000 chaves. Na versão não maliciosa do GitHub, recebemos 1.000 chaves exclusivas, como esperado.

No entanto, usando o WalletGenerator.net em vários momentos entre 18 de maio de 2019 e 23 de maio de 2019, obteríamos apenas 120 chaves exclusivas por sessão. Atualizar o navegador, alternar locais de VPN ou fazer com que uma outra parte realize o mesmo teste resultaria em um conjunto diferente de 120 chaves sendo geradas.

No vídeo acima, você verá a solicitação XHR. Passamos pelo processo de semeadura e depois geramos 1.000 chaves. Tudo parece estar bem na superfície. No entanto, quando copiamos a saída em um editor de texto, removemos os índices (substituindo \d+,por uma string vazia) e classificamos as linhas, vemos os grupos de chaves duplicadas.

Nós determinamos que todas as chaves geradas são totalmente determinísticas usando a imagem que foi obtida através da nova requisição XHR para semear o RNG. Se você usar a mesma imagem que a semente em uma data posterior, ela gerará as mesmas 120 chaves. Como exatamente a imagem é manipulada no servidor e quando a imagem maliciosa é servida permanece desconhecida.

A carga útil da imagem é visualmente idêntica para todos os visitantes, mas o conteúdo é gerado pelo servidor – o conteúdo binário da imagem – geralmente é diferente para cada usuário, embora às vezes possa ser o mesmo para o mesmo usuário / sessão. Por exemplo, se eu tiver uma imagem com o hash e 27fc...085ddepois voltar mais tarde para gerar mais chaves, terei a mesma carga de imagem maliciosa e, portanto, as mesmas chaves. Isso pode ter a ver com o cache do lado do cliente ou do lado do servidor, já que usar uma VPN ou alternar navegadores resultará em uma nova imagem e um novo conjunto de chaves sendo gerado.

Esteganografia?

Queríamos saber o que estava sendo inserido na imagem, então usamos binwalk e extraímos os dados (veja os dados do Zlib). Esta é uma maneira legítima de construir uma imagem PNG, e nós suspeitamos que há alguma esteganografia acontecendo para tornar a imagem visualmente idêntica, mas com bytes diferentes para cada usuário.

Sabemos que algo está acontecendo para manipular a imagem, mas não conseguimos determinar o que exatamente está acontecendo. A maioria das ferramentas de esteganografia inclui uma funcionalidade de senha, ou seja, descriptografar com êxito os dados “ocultos” é impossível sem saber a senha fornecida no momento da construção da imagem.

Além disso, a manipulação pode ser aleatória, com as imagens simplesmente sendo armazenadas no servidor para reutilização em uma data posterior.

Determinando quando

Observando os snapshots na Wayback Machine, podemos determinar que o comportamento malicioso foi introduzido em algum momento após 2018–08–17 e definitivamente em 2018–08–25 .

Os desconhecidos

• O que determina se você recebe ou não a versão maliciosa do site/imagem?
• Como a imagem maliciosa é gerada e quais dados são adicionados? São dados aleatórios ou conhecidos (endereço IP, registro de data e hora)?
• Quem fez essas mudanças? O proprietário do site atual? Uma parte maliciosa que ganhou acesso ao servidor?

Timeline

• 2019-05-17—2019-05-20: Investigação e confirmação de comportamento malicioso.
• 2019-05-17—2019-05-22: Consultas com especialistas em segurança do setor sobre a melhor forma de lidar com a situação para minimizar a perda de fundos dos usuários.
• 2019-05-22: Proprietário do site atual notificado por email.
• 2019-05-23: Resposta recebida (não útil) do proprietário do site atual.
• 2019-05-24: Divulgação pública.

Agradecimentos especiais

• Obrigado ao PhishFort pelo financiamento de endereços para ver se eles são auto-varridos!
• Obrigado a todos que forneceram insights, conselhos e confirmação de nossas suposições iniciais.
• Obrigado ao MyCrypto por me dar a capacidade de investigar esses tipos de situações e fornecer suporte e recursos necessários.

Atualizações

• Esta postagem será atualizada se/quando novas informações forem esclarecidas. Foi modificado pela última vez em 2019–05–24 @ 5:30 am PT.

Se você tiver alguma dúvida ou puder fornecer mais informações, entre em contato comigo diretamente em [email protected].