O caos aparenta ter se instalado na criptoesfera, não existe assunto mais comentado nas redes sociais do que o hack nas exchanges do Bitcoin Banco.
Quem já sobreviveu à quedas de exchanges como a Mt Gox, BitGrail, BTC-e e mais recentemente a Cryptopia sabe bem do risco que estamos discutindo aqui. A comunidade de criptomoedas está calejada de situações em que grandes corretoras são invadidas e acabam por declarar insolvência, posteriormente desaparecendo e levando junto a esperança dos investidores em reaverem seu suado capital.
Infelizmente eu não tenho como conversar com vocês sobre a solvência deles. Apenas a corretora poderia. E esse será o caso toda vez que você relega a custódia a terceiros.
Uma solução simples
Sendo assim, o máximo que o público geral pode fazer é especular, pois somente o Grupo Bitcoin Banco pode trazer informações a respeito deste assunto. Ainda bem que estamos com a tecnologia ideal para isso em mãos, a blockchain é transparente e foi feita para permitir provas de custódia através de assinatura de mensagens.
Minha proposta, como outras exchanges já fizeram no passado em situações similares, é que eles também podem divulgar seus endereços de carteiras para sepultar esse assunto.
O que aconteceu na NegocieCoins?
Agora falemos sobre o que eu posso trazer hoje: uma análise do ponto de vista técnico sobre o que ocorreu na corretora, debaixo do capô. São poucos os casos em que temos em mãos uma prova de conceito de uma vulnerabilidade ativamente explorada. Squi ela veio na forma de um vídeo que tem circulado pelas redes sociais.
De forma bem simples esse vídeo mostra como a vulnerabilidade poderia ser explorada por alguém, sem necessidade de conhecimento técnico:
- O atacante cria duas sessões, fazendo login na mesma conta em dois computadores diferentes;
- Ele procede a fazer então duas transferências via FortKnox. Em uma sessão solicita a transferência para a TemBTC, a outra para a Bat Exchange, corretora nova do Bitcoin Banco;
- Ao solicitar essas transferências ao mesmo tempo, o saldo na NegocieCoins fica negativo e o sistema credita então o saldo dobrado entre as Exchanges de destino;
A condição de corrida
Em ciência da computação, chamamos esse tipo de bug de condição de corrida. Imagine o Indiana Jones correndo lado a lado com o Vilão Belloq para entrar no templo da Arca Perdida: quando um entra no templo um mecanismo fará com que as portas se fechem imediatamente, de forma que apenas um possa passar.
É fácil imaginar que eles irão correr o mais rápido possível e nosso herói irá passar pela entrada, trancando Belloq do lado de fora. Mas o que acontece se os dois estiverem passando no portão lado a lado? Tão próximos que não tem como a porta fechar só para um?
Esse problema a priori pode parecer bem simples de resolver: vamos fazer um portão mais rápido, vamos colocar um soldado no portão para barrar quem estiver mais atrás, vamos fazer um portão que seja da largura de apenas uma pessoa. Essas são algumas das dicas que muitos estarão soprando para o construtor do templo.
Só que essas dicas quebram quando a gente escala o problema para dezenas de milhares de portões, operando e tendo que fechar todos ao mesmo tempo.
O caso Bitcoin Banco
Essas mesmas dificuldades acontecem em tecnologia de um jeito não muito diferente do explicado acima. O portão da NegocieCoins era a verificação de saldo disponível antes de realizar o saque.
O sistema de qualquer corretora, ao efetuar um saque realiza uma verificação preliminar de saldo. Se esse saldo é suficiente para comportar o saque, ele segue em frente. As duas sessões passavam por essa verificação, só que ao mesmo tempo.
Para ambas o saldo estava ok, uma vez que ainda não havia sido deduzido ainda. O problema aqui ocorria depois dessa verificação, pois o saque seguia sendo processado normalmente, mesmo que os dois saques juntos acabassem por negativar o saldo.
Um bug desses em um trecho sensível à segurança pode trazer consigo consequências catastróficas. A condição de corrida nesses casos é uma vulnerabilidade tão comum de ser encontrada nos sistemas que recebe uma enumeração própria, a CWE-362.
A blockchain de um só computador
É interessante pensar que o Bitcoin veio justamente como uma solução para o fatídico gasto duplo (mais conhecido do inglês double spending).
A ironia do caso chega a ser ainda maior quando pensamos que o problema ocorreu no sistema da FortKnox, uma blockchain própria do Bitcoin Banco, responsável pela transferência de valores entre as corretoras do grupo.
É inconcebível imaginar que uma blockchain tenha um bug exatamente na funcionalidade que ela pretende resolver, mas esse parece ser o caso. O nível de segurança de uma blockchain é diretamente proporcional ao número de mineradores trabalhando nela. Só que neste caso a FortKnox é uma blockchain privada.
Fica a lição de que uma blockchain com apenas um minerador não é muito diferente de um banco de dados SQL com um nome bonito…
Um erro esdrúxulo
É uma questão que paira no ar, se este tipo de erro é tão conhecido, tão comum, já não deveria ser evitado por padrão na hora de desenvolver uma exchange? A resposta simples é sim!
Tanto é que todas as exchanges com as quais conversei tentam implementar proteções contra condição de corrida. É para isso que serve a fila de eventos que os bancos usam por exemplo.
Estamos falando aqui de um Grupo que possui atualmente 3 corretoras, sendo a última lançada agora em março de 2019, que reporta uma movimentação de bilhões de reais diariamente. É impossível uma empresa crescer assim tão rápido sem deixar pontas soltas. O que estamos vendo hoje é a consequência de se tocar uma equipe de desenvolvimento à toque de caixa.
Entramos então em um tópico que tenho batido firmemente no último ano, no Brasil a mentalidade de segurança é completamente sobrepujada pela pressa em se desenvolver o mais rápido possível, o máximo de funcionalidades possível.
O Brasil e a segurança
No Brasil, o desenvolvedor que pensa na arquitetura de cada funcionalidade, que elabora seus sistemas com cuidado e atenção à vulnerabilidades é justamente o profissional menos valorizado no meio. Afinal, neste mercado, segurança não traz dinheiro, volume sim.
A desvalorização da segurança aqui é tão grande que chamou a atenção do Ministério Público, que tem imputado multas milionárias a empresas que tem os dados dos clientes vazados, uma espécie de prévia da regulação estatal que está por vir com a LGPD (Lei Geral de Proteção de Dados).
Casos parecidos e parecidos
Essa não é a primeira vez que vimos saques duplicados ocorrendo em exchanges, nem deverá ser a última, aqui no Brasil mesmo temos exemplos não muito distantes, como o que ocorreu na Foxbit em 2018.
Nesse caso nem era necessário explorar a falha, um simples erro de sincronia no banco de dados do sistema distribuído da BlinkTrade causou o problema. Mas vale dizer que esse não foi o único caso daqui, de acordo com fontes confiáveis, outras exchanges também tiveram problemas recentes com saques duplicados, mas nesse caso optaram por engolir o prejuízo e não divulgar em público a falha.
O grupo de segurança de que faço parte, a aCCESS Security Lab, elaborou ferramentas especificamente para atacar condições de corrida durante os testes de intrusão que temos feito, não só nos saques, como também no livro de ordens das corretoras. Esse tipo de ataque é bastante invasivo e apenas feito com a devida autorização.
Essa não é a primeira vez que venho aqui falar da segurança na exchange Negocie Coins. Ao passado a aCCESS já realizou alertas sobre vulnerabilidades da plataforma. Na ocasião, conforme declaramos houve uma demora excessiva para o recebimento de uma resposta.
A situação foi a tal ponto que tivemos que procurar os parceiros deles para que a devida atenção ao caso fosse dada e as falhas corrigidas. Uma delas, a mais leve, só teve correção quando fizemos a publicação no Portal do Bitcoin.
Como tratar a segurança
Vale a máxima de que prevenir é sempre melhor que remediar. Para garantir um crescimento controlado e seguro em uma empresa, é obrigatório implementar processos de verificação contínua. A segurança vai muito além do código.
- Implementar processos de revisão de código, nada vai para produção sem passar por um segundo par de olhos;
- Provocar uma mudança cultural na organização, a segurança é responsabilidade de todos, não apenas do TI;
- Criação de um planejamento de resposta a incidentes, associado a um grupo responsável por lidar com eles (CSIRT);
- Realizar constantemente testes de intrusão, de forma a garantir uma escala saudável do sistema;
- Dependendo do modelo de negócio criar times red/blue, responsáveis por simular ataques e defendê-los respectivamente;
