Como reduzir o preço do Uber

Como invadir uma exchange

Parabéns a você que clicou no meu bait, mas fica aí que o assunto é interessante. Apesar desse título chamativo eu não invadi ninguém ok? Afinal isso seria ilegal... Mas eu descobri uma forma como eu poderia tê-lo feito com a, digamos, exchange X, sem muito trabalho, uma das exchanges Brasileiras campeãs em volume, e tudo isso estudando a plataforma por 30 minutinhos. Todas as falhas aqui descritas já foram informadas a eles e corrigidas, mas serve de aprendizado, tanto para quem faz exchange como para quem testa.

Eu só queria fazer um disclamer antes: todas as pesquisas de segurança que faço tem pura e unicamente o objetivo de fortificar a comunidade, tornando exchanges Brasileiras mais seguras e atentas, e usuários mais astutos. Este artigo tem finalidade PURAMENTE ACADÊMICA, aprenda com os erros dos outros para não os cometer; no fundo meu objetivo é formar white hats que possam ajudar esses ideais, agora, se você possui más intenções com essa informação, a porta é serventia da casa.

Se você não estiver acostumado com segurança de dados deve estar pensando nesse momento que invadir uma plataforma financeira deve ser a coisa mais complicada do mundo, afinal eles tem bastante para investir em segurança, e se mexem com dinheiro devem se preocupar bastante com isso. Espero que ao final eu tenha desmistificado isso, a coisa não é bem assim, você ficaria impressionado com o tanto de falhas bobas que acabam deixadas para trás - e essa é um bom exemplo.

Tudo começou quando eu fiz um saque de criptos na referida exchange, estava pensando aqui comigo: Por quê a API deles, dentre todas, é a única que não suporta saques? Isso é um pouco estranho e transparece medo ,implementar saques de forma segura realmente envolve riscos, são necessárias white lists de endereços, uma forma de cadastrar eles bem fechada, e por aí vai..

Apesar de estranho dei uma olhada em como o sistema requisita esses saques internamente - vai que dava pra implementar no meu robô usando esses meios. Primeiro eu olhei com o console do Chrome mesmo, era enviada a solicitação de saque para uma API que retornava um OK, até aí belezinha, seguindo fui olhar meu email:

Bom, achei esse token interessante, normalmente as exchanges usam UUID4 com um RNG criptográfico por trás, traduzindo, eles geram um numero bem grande totalmente aleatório. Esse aí parece um hexadecimal grande, mas por enquanto vamos botar um pino nisso e seguir estudando o motor de saques.

O próximo passo foi olhar a lista com meus saques solicitados para entender como ficam registrados no sistema - o meu saque ainda deve estar lá, não autorizado, afinal eu ainda não cliquei no link... Bom, vamos ver como o site requisita essa lista, e como ela vem pro navegador usando o console do Chrome de novo, guia Network...

Hohoho, papai noel chegou cedo esse ano... O retorno do backend veio com um brinde. Repare que esse aí é o mesmo token de saque que veio no email de confirmação logo acima. O que aconteceu aqui é que, talvez para fins de conveniência, talvez por esquecimento, o endpoint de listagem dos saques está vindo com todas as informações do objeto, e entre elas o link que tenho que clicar pra confirmar o saque.

Repare que aqui eu passei a chamar de objeto, pois já vi essa estrutura de informações no passado, isso aí se trata de um objeto do MongoDB, representado em Json. Note também que o tal "token" está aparecendo num campo chamado Id. Nesse momento me assustei, será mesmo que o token não é aleatório no final das contas?

Para confirmar essa suspeita joguei o "token" num conversor de ObjectId para Timestamp:

Psiu! você com olhar de paisagem! Respira que vou dar uma pausa na programação original para explicar a gravidade disso ok? 9.8 m/s2

Para entender certas coisas ajuda olhar pelos olhos do vilão, se eu fosse um hacker malvadão que acabou de pegar sua senha, ou achou sua máquina logada nessa exchange, o que me impede de sacar todo o seu saldo? O email de confirmação é para isso! Além de invadir sua conta eu precisaria invadir também o seu email, para obter o tão famigerado link que chega lá, só que não.

1- Em primeiro lugar, eu não precisaria mais invadir seu email, já que o site da exchange X me dá o token, que é a única parte que ninguém sabe do link, o trabalho é de simplesmente navegar até ele.

2- Em segundo lugar, e talvez até pior, o token não é aleatório, é determinístico, ou seja, mesmo que o site não me desse ele de mão beijada, eu poderia descobrir qual é seu token pela data e hora que solicitei o saque, mwahaha! Calma que explico a seguir:

A documentação do MongoDB diz o seguinte: "A BSON ObjectID is a 12-byte value consisting of a 4-byte timestamp (seconds since epoch), a 3-byte machine id, a 2-byte process id, and a 3-byte counter" - Fonte: http://www.mongodb.org/display/DOCS/Object+IDs

Bom, o timestamp eu tenho, pois fui eu quem solicitou o saque, caso não lembre ele vem na listagem de saques de toda forma, machine id é só ler em qualquer objeto, process id também, então tudo que resta é o contador sequencial do MongoDb, para resolver isso basta solicitar 2 saques em seguida, o primeiro você usa para extrair os dados, o segundo você confirma, incrementando aos poucos e testando o id, um mini-bruteforce, bobinho de ser feito.

Até o momento você leitor pode até estar decepcionado com o "bypass de email de confirmação", oras, de que serve uma falha que só quem pode explorar é quem já tem a senha do cliente? Apesar de grave, realmente é anticlimático, mas o clímax ainda está por vir...

De posse dessa falha a última peça do quebra cabeças seria uma forma de solicitar o saque no lugar do cliente, eu (o hacker malvadão), posso simplesmente fazer uma página idêntica à exchange X, e daí torcer para você (vítima) entrar nele e digitar sua senha, Laaaaaame...

Para não fazer do jeito mais chato, sobram ainda 2 possíveis metodologias:

1- Forçar o navegador da vítima a solicitar o saque.

2- Capturar o cookie contendo a sessão, e em seguida solicitar o saque.

Vamos de opção número 1, para isso eu trouxe à tona um antigo parceiro, o CSRF, dependendo de como são feitas as solicitações de saque, a nível de formulário, pode ser possível criar um segundo site "infectado" com um javascript simples, este site pode então mandar seu navegador pedir o saque, de forma invisível, basta entrar nele. Bem melhor que phishing né?

Masss nem tudo é perfeito, estudando o que é enviado no momento do saque podemos ver uma hash sendo passada, que também está presente no cookie, ou seja, a hash funciona como um token de CSRF, que a cada pedido de saque é validada novamente para garantir que esse pedido veio mesmo da exchange X. Além disso, não observamos o cabeçalho Access-Control-Allow-Origin, e de acordo com a política dos navegadores atuais, quando ele não está presente por padrão só são permitidas requisições vindas do mesmo domínio.

Com o CSRF fora da jogada, comecei a caçar um XSS Injection, o XSS (Refletido) é quando a gente consegue, através de um link, injetar javascript malicioso na página da exchange. Esse script pode fazer algumas tarefas para o atacante: enviar o cookie do cliente para algum lugar ou solicitar o saque e confirmar ele mesmo.

A idéia de injetar algo que pudesse sacar os valores e já confirmar, direto da máquina do cliente, seria excelente para um roubo em massa de Bitcoins. Os ataques, nesse caso, ficariam difíceis de detectar, afinal os saques viriam do mesmo ip do cliente; até que fosse possível encontrar o ponto de injeção (e que tinha uma injeção ocorrendo em primeiro lugar) muito dinheiro já teria sumido.

Comecei a escavar os endpoints do site, notei que o endpoint do extrato, que mostrava as operações realizadas com determinada cripto, permitia que se colocasse mais do que só o nome da moeda na url, por exemplo: /exchange/detail.php?cur=teste, e ele mostra o texto "teste" no site. Deste ponto em diante seria apenas confeccionar um script e colocar no lugar da moeda certo?

Ainda não tão simples, agora sim a parte difícil, normalmente os navegadores possuem detectores internos, para evitar que você se torne vítima de um XSS Injection, então ainda teria que bolar um script que além de efetivo pudesse enganar esse detector.

No Chrome a detecção basicamente procura por um fechamento de tag </script>, sabendo disso foi possível ultrapassar com o seguinte script: /exchange/detail.php?cur=<script>alert(1);

Isso deveria exibir uma mensagem de alerta, mas tem um problema ainda, como o site deixa o nome da cripto em maiúscula o script todo ficava em maiúsculas. No Javascript as maiúsculas influenciam no nome da função.

Esse endpoint não seria o ideal, a mensagem de alerta não surgiu pois o ALERT acabou todo em maiúsculas, foi então que decidi procurar outro endpoint melhor. Vamos atrás de um velho parceiro meu, o sistema de suporte.

Aqui foi bem fácil encontrar o Injection, no endpoint /exchange/interacao_add10.php o id do ticket provavelmente está sendo usado em algum momento para solicitar do backend as informações necessárias sobre ele, coloquei teste no lugar da hash mandei aquele CTRL+F para ver onde ele aparecia na página.

Jackpot! não só encontrei um Injection melhor, como encontrei um Injection que já está dentro de uma tag <script>!!!, isso é ótimo para ultrapassar o XSS Auditor, eu não preciso mais iniciar um <script> e finalizar com </script>, assim o bypass fica beeeem mais fácil.

Elaborei um script simples para teste, ele não faz nada malicioso, apenas uma mostra uma popup de mensagem no navegador, mas se a popup aparece então as possibilidades são infinitas...

Embuti o script na url da seguinte forma: /exchange/interacao_add10.php?h1='});alert(<texto aqui>);$.ajax({method:%27GET%27,url:%20%27json_interacoes.php

Voilá, conseguimos injetar com sucesso uma mensagem de alerta no site, qualquer um que acessar esse link também irá ver ela, mas não estamos muito interessados em espalhar mensagens de alerta por aí não é mesmo? É aqui que o hacker malvadão tem todas as ferramentas necessárias para um roubo massivo de criptomoedas.

Só um detalhe: ao clicar nesse link, aparece uma tela do Cloudfare, pedindo para eu clicar numa caixa de “eu não sou robô”. Ficou faltando preparar um script de bypass desse filtro também, mas no estado atual já está perfeitamente utilizável para um ataque, as pessoas tendem a clicar nessa caixa sem nem piscar, principalmente quando é contada uma boa história por trás.

Neste ponto a falha passou a ser crítica, acabei de descobrir que é possível criar um link que se as pessoas clicarem perdem todos os seus BTCs!

Corri para avisar a exchange e a resposta deles foi relativamente rápida, em poucos dias tudo se resolveu e o token também passou a ser aleatório de verdade. Que bom! Em troca ganhei só um muito obrigado deles, eles não gostaram muito da minha idéia de tornar as falhas públicas, mas esconder isso foge de todo o meu propósito de tornar o ambiente de criptomoedas brasileiro mais seguro.

Para o ataque em si já está quase tudo pronto, ele pode ser feito da seguinte forma: Criamos um script que solicita um saque pelo cliente e já confirma ele, com isso teremos o link bomba, podemos encurtar ele com o goo.gl ou outro serviço de diminuição de url.

Deste ponto em diante, o hacker malvadão passa a postar esse link em grupos, listas de email, sites sobre criptomoedas, comentários, uma verdadeira campanha de roubos instantâneos, todo mundo que clicar no link vai perder seu dinheiro.

Nem preciso dizer que esses últimos passos não foram tomados, evitando assim questionamentos legais, para mim basta ter encontrado a vulnerabilidade e avisado, ajudando assim na proteção dos clientes e ensinando que se você não investe em segurança, alguém investe por você, e isso nem sempre acaba com o final feliz de hoje.

[disclosure] Braziliex - listagem do BD de suporte

Esse é um pouco antigo, mas para complementar melhor no blog irei publicá-la aqui também, onde ficarão todos os disclosures.

Começo de março detectei uma falha de segurança na Braziliex quando haviam requisições para o sistema de suporte sem hash identificadora do ticket, a seguinte requisição https://braziliex.com/exchange/interacao_add10.php?h1= acabava por retornar todas as mensagens de suporte dos usuário.

Esse erro ocorre pela forma em que são tratadas as requisições no MongoDB, caso haja a passagem de um id vazio no objeto ele acaba por retornar todos objetos que obedecem os critérios solicitados.

Dia 02/03/2018 realizei o aviso para que arrumassem o problema e fiquei impressionado com a velocidade que fizeram: em apenas 10 minutos!

Braziliex está de parabéns pela celeridade. Separei apenas tickets que não permitirão identificação de clientes como prova da falha; também removi toda informação que pudesse dar problema, publicados abaixo:

[disclosure] Foxbit - falha na implementação do 2FA + reuso de token + vulnerabilidade nos saques

Este artigo é parte integrante de uma série de três artigos que serão publicados aqui, trata a respeito de uma investigação independente que fiz no mercado de criptomoedas como um todo, com foco em roubos recentes por Phishing que estavam ocorrendo na época de Março/2016 a Abril/2018 na Foxbit, bolsa brasileira de criptomoedas.

Para ler a primeira parte acesse: http://thinkhacker.blogspot.com.br/2018/04/como-os-hackers-roubam-criptomoedas.html

Para a segunda parte: http://thinkhacker.blogspot.com.br/2018/04/como-as-bolsas-de-criptomoedas-protegem.html

Endereços para doações:
BTC: 1FSzwTdndhtbjGtRTKiu2vQHHrVAPUGSZG
DCR: DsnWSf8qCZD85KR5mpidae5FEpJtuaARHir

Para baixar o relatório completo em PDF clique aqui: https://goo.gl/46oWm1

Video Explicativo:

Noticia no Portal do Bitcoin: https://portaldobitcoin.com/falha-seguranca-foxbit-prejuizo-clientes/

1. Resumo

Uma implementação insuficiente na autenticação de dois fatores da Foxbit inutilizou tal modelo de segurança e abriu as portas para que hackers retirassem dinheiro das contas sem necessidade de confirmação da vítima.
Hackers de posse desse conhecimento criaram páginas falsas, simulando a da bolsa em questão e usaram o sistema de propagandas da Google para que essas páginas aparecessem no topo dos resultados (Exemplo na Imagem 2).
Uma vez capturada a senha das vítimas o sistema desenvolvido pelo hacker atuava de forma automática ou manual, explorando a falha para trocar a autenticação de dois fatores e subtraindo os seus saldos na forma de bitcoins, para uma carteira irrastreável.
As falhas no sistema da Foxbit aqui mencionadas permaneceram abertas e sendo exploradas por pelo menos 2 anos, desde Março/2016 até o final de Abril/2018.

2. Falhas de segurança observadas na Foxbit

Até o presente momento discutimos os ataques mais utilizados por hackers em todas as plataformas financeiras, de forma a comprometer contas individuais de clientes e roubá-los. Discutimos também quais são as implementações de segurança padrão no mercado de forma a proteger os clientes contra esses ataques.

O motivo em particular que me levou a essa investigação foi ter notado um aumento crescente de clientes da Foxbit reclamando de furtos a suas contas, é natural esperar que algumas pessoas tenham suas contas comprometidas em um sistema desse porte, mas a quantidade de pessoas sofrendo esses furtos passou do normal e continuava a crescer. Com a subida exponencial do preço do bitcoin, os ataques também cresceram exponencialmente.

Essa explosão de ataques me levou a desconfiar de que poderia haver algum erro com a implementação de segurança desta bolsa, até porque todas as pessoas encontradas reclamando afirmavam possuir a autenticação de dois fatores (2FA - Art2.2) ativada, o que significaria que suas contas deveriam ser as mais seguras.

De posse do conhecimento acima exposto comecei uma investigação independente do ocorrido, primeiramente conversando com pessoas roubadas e posteriormente fazendo perícia em suas máquinas para identificar porquê, quando, e como esses ataques ocorreram.

Ao estudar melhor os fatos, pude descobrir uma série de falhas de implementação na segurança da Foxbit que trouxeram à luz o ocorrido bem como a forma que os hackers se aproveitaram de todas ou algumas delas.

O código fonte da blinktrade é aberto ao público, se provando muito útil para descobrir regras de negócio e como elas afetam a segurança do cliente. Apesar de o código publicado ser antigo as regras de negócio não evoluíram muito, este encontra-se no seguinte endereço: https://github.com/blinktrade/

Adiante irei esclarecer algumas das falhas descobertas por mim, e ao final minhas conclusões sobre possíveis cenários de ataque em que ocorreram os furtos.

2.1. Reaproveitamento de 2FA

Para entender como funciona essa falha é necessário compreender o princípio da implementação do 2FA, discutido no artigo 2.2. Tal princípio é de que apenas o beneficiário e o serviço detém posse do segredo gerador de chaves, então um hacker de posse de uma chave gerada não seria capaz de fazer nada com o saldo pois não tem como prever a próxima chave e realizar a transação.

Para seguir isso é importante que a plataforma não permita o uso mais de uma vez da mesma chave, caso contrário o 2FA perde o propósito e se torna o mesmo que uma senha, uma vez o agente malicioso tendo uma chave ele pode usá-la para tudo dentro do prazo.

A plataforma da Foxbit porém, não pratica a invalidação de uma chave uma vez que é usada, permitindo que um hacker de posse apenas de uma chave tenha uma janela de 30 segundos para fazer saques ou quaisquer modificações que desejar na conta da vítima.

Note que 30 segundos é um prazo bastante curto, um humano utilizar-se desta falha torna-se bastante difícil, portanto essa falha deveria ser explorada por robôs. O ataque consiste em um hacker desenvolver um programa robô automatizado para realizar o saque da conta da vítima de forma praticamente instantânea quando esta digitar suas credenciais, seja em página de phishing ou por outros meios aqui discutidos.

2.2. Vulnerabilidade nos saques de Bitcoins

A regra de negócio da Blinktrade/Foxbit é extremamente vulnerável a qualquer ataque ao 2FA, isso acontece pois quando o cliente possui o 2FA ativo não é solicitada qualquer confirmação por e-mail ou outros meios de forma a realizar a transação, ela ocorre instantaneamente, o cliente recebe apenas um aviso pelo e-mail, e este pode acabar sendo visto tarde demais.

A confiança que a Foxbit colocou na implementação do sistema 2FA torna o peso sobre ele muito maior, se esse pilar cai, a segurança do cliente cai como um todo. Foi exatamente isso que ocorreu nos furtos como iremos demonstrar a seguir neste documento.

Imagem 19 - E-mail de aviso de saque de bitcoins da Foxbit, repare que não há confirmação (Art2.3) nem forma de cancelamento instantâneo (Art2.4)

A seguir demonstro o trecho de código responsável por essa regra de negócio, encontrado em: https://github.com/blinktrade/bitex/blob/a4896e7faef9c4aa0ca5325f18b77db67003764e/apps/trade/models.py

Linha 1971:

@staticmethod   def create(session, user, broker,  currency, amount, method, data, client_order_id, email_lang,              percent_fee, fixed_fee):     import uuid     confirmation_token = uuid.uuid4().hex     if not user.has_instant_withdrawal:       new_data = json.loads(data)       new_data["Instant"] = 'NO'       data = json.dumps(new_data)     withdraw_record = Withdraw(user_id            = user.id,                                account_id         = user.id,                                username           = user.username,                                broker_id          = user.broker_id,                                broker_username    = user.broker_username,                                method             = method,                                currency           = currency,                                amount             = amount,                                email_lang         = email_lang,                                confirmation_token = confirmation_token,                                percent_fee        = percent_fee,                                fixed_fee          = fixed_fee,                                client_order_id    = client_order_id,                                data               = data )     is_crypto_currency = Currency.get_currency(session, currency).is_crypto     if is_crypto_currency and \         user.withdraw_email_validation and \         not WithdrawTrustedRecipients.is_trusted(session, withdraw_record):       if not user.two_factor_enabled:              formatted_amount = Currency.format_number( session, withdraw_record.currency, withdraw_record.amount / 1.e8 )         template_name       = 'withdraw-confirmation'         template_parameters = withdraw_record.as_dict()         template_parameters['amount'] = formatted_amount         template_parameters['created'] = get_datetime_now()         UserEmail.create( session  = session,                           user_id  = user.id,                           broker_id = user.broker_id,                           subject  = "CW",                           template = template_name,                           language = email_lang,                           params   = json.dumps(template_parameters, cls=JsonEncoder))     else:       if user.withdraw_email_validation:         WithdrawTrustedRecipients.add(session, withdraw_record)       withdraw_record.status = '1'     session.add(withdraw_record)     session.flush()     return withdraw_record

2.3. Falha de revalidação do 2FA

Esta é a falha de segurança principal explorada nos casos de phishing estudados, de forma resumida além dela tornar o sistema de 2FA inútil, a falha facilita o trabalho do hacker, pois pode ser usada tanto para trancar o cliente fora de sua conta como permitir realização de saques sem e-mail de confirmação (Art2.3 e 2).

Estimo que ela vem sendo explorada livremente por hackers desde Julho/2017, porém o momento exato de início é difícil de estimar, logo podem haver casos anteriores a esses fora do meu conhecimento.

Imagem 20 - Explicação de como o 2FA deveria funcionar quando corretamente implementado, extraído do site da Foxbit.

O exemplo a seguir mostra o passo-a-passo de como essa falha pode ser explorada por um agente malicioso:

01 - De posse do e-mail e senha roubados pela página de phishing (ex: Imagem 3) entre com eles na página original da Foxbit

02 - Entre também com o código 2FA digitado pela vítima

03 - O atacante se encontra agora logado na conta da vítima, deste ponto ele pode seguir para sacar os bitcoins usando a falha 1 ou dar continuidade.

04 - Acesse a seção “Meu Perfil”

05 - Clique em desabilitar 2FA

05 - Vá em qualquer outra seção e volte em “Meu Perfil” para que o botão de habilitar 2FA apareça, clique nele.

06 - O hacker agora cadastra o 2FA em seu celular, preenche os dados e clica em “habilitar”, efetivamente sequestrando a conta da vítima.

07 - O ataque está completo, a vítima não conseguirá mais acessar a conta pois o 2FA está de posse do hacker, agora ele apenas precisa aguardar 24 horas e sacar todo o valor da conta, sem e-mail de confirmação (Art2.3 e 2)

Note que este ataque possui múltiplos usos, é importante que o hacker tranque a vítima fora de sua conta, assim ela não pode mais cancelar a transação. É igualmente importante que o hacker mantenha o 2FA ativado pois pode realizar o saque após 24 horas.

Se a vítima digitar o 2FA mais de uma vez na página de phishing o saque poderá ser feito na hora e essa falha é usada para impedir o cancelamento da transação(Art2.2); se o atacante criar um robô de ataque automatizado (1) o saque poderá ser feito na hora também; se o atacante não conseguir outro 2FA e não queira criar um robô de ataque automatizado ele só precisa esperar 24 horas para o saque, dificilmente o cliente irá notar que está trancado fora da conta e se notar, dificilmente o suporte da foxbit poderá responder em tempo hábil.

A seguir detalharei mais a fundo como essa falha afeta a segurança dos usuários.

2.4. Supressão do e-mail de confirmação

Conforme vimos na seção 2 a vítima não precisa confirmar através de e-mail nenhum saque que seja realizado enquanto o 2FA estiver ativo. Ao manter o 2FA ativo o hacker consegue pular esse passo na validação da transação.

Tal supressão é importantíssima, principalmente para phishing, pois a menos que o cliente reuse a senha do e-mail na bolsa em questão, o atacante não terá como invadir o e-mail da pessoa o que seria um impeditivo para o ataque.

2.5. Evitando o cancelamento da transação indevida

Esse ataque possibilita que o hacker tome posse da conta da vítima, efetivamente trancando ela de qualquer acesso à plataforma da Foxbit.

Como pudemos observar na Imagem 19, a Foxbit não fornece a funcionalidade de cancelamento instantâneo (Art2.2). A única forma de cancelar a transação que a vítima tem é acessando a plataforma e realizando o cancelamento manual, como o hacker trancou a vítima fora da conta isso fica impossível de ser feito em tempo hábil.

Os saques na Foxbit ocorrem de 5 em 5 minutos, o cliente precisaria acessar a plataforma digitando login senha e 2FA, ir em saques e cancelar o saque indevido nesse espaço de tempo. Somente é possível cancelar o saque, não é possível realizar bloqueio total da conta, então mesmo que a vítima o consiga, o hacker ainda pode solicitar mais saques.

3. Aviso de falha feito à Foxbit

Uma vez descoberta a falha 3 realizei a informação para a Foxbit, à luz do processo de responsible disclosure usado por pesquisadores de segurança. No dia 29/04/2018 enviei 2 e-mails, 1 mensagem no sistema de suporte e 1 mensagem via facebook.

As informações foram idênticas entre os 4 avisos e tiveram a forma seguinte:

Imagem 21 - Email com relatório da falha de segurança, enviado para a Foxbit em 29/03/2018.

O prazo que estimei para correção da falha foi em torno de 10 dias, porém após longo silêncio, no dia 12/04, fui contactado pela Foxbit e Blinktrade, a última sendo a responsável pelo desenvolvimento do sistema da Foxbit, esta solicitou um aumento no prazo de mais 7 dias.
 A solução por mim proposta foi a seguinte:

1. Solicitar a confirmação por e-mail para todos os saques, independente do 2FA ativo (4.2). 
2. Invalidar a chave 2FA depois de usada, fazendo com que somente a próxima chave seja aceita (4.1). 
3. Realizar a confirmação por e-mail também para ativar o 2FA (4.3).

 A correção no entanto foi posta em produção pela Foxbit no dia 23/04, 25 dias após o aviso, atualmente o sistema passou a solicitar e-mail de confirmação em todas as transações (3.3) bem como confirmação por e-mail para realizar o login em um navegador novo (3.5).

4. Conclusão

Imagem 22 - Pagina de phishing foxbits.exchange em ação, layout idêntico à original.

Imagem 23 - Ao digitar o 2FA a página retorna um erro para convencer a vítima a digitar os próximos códigos, mesmo que ela não digite, o hacker tem recursos suficientes para furtá-la.

Segundo os casos estudados e as falhas de segurança da Foxbit elucidadas acima pudemos chegar a uma conclusão de como devem ter sido realizados os phishings, nos levando aos seguintes cenários:

Cenário 1:

1. Hacker cria uma página idêntica a da Foxbit e registra um domínio de nome parecido (Imagem 3 - Art.1).
2. Contrata o serviço de propagandas da Google, AdWords, para aparecer no topo dos resultados em pesquisas (Imagem 2 - Art1).
3. Vítima cai na página falsa, acreditando estar lidando com a Foxbit digita suas credenciais e apenas um código 2FA.
4. Hacker explora a falha exposta em 2.3 e tranca a vítima fora de sua conta.
5. Após 24 horas o hacker troca todos os reais por bitcoins e retira todo o dinheiro da vítima para uma carteira irrastreável.

Cenário 2:

1. Hacker cria uma página idêntica a da Foxbit com um sistema automatizado de furto, registra um domínio de nome parecido (Imagem 3 - Art.1).
2. Contrata o serviço de propagandas da Google, AdWords, para aparecer no topo dos resultados em pesquisas (Imagem 2 - Art-1).
3. Vítima cai na página falsa, acreditando estar lidando com a Foxbit digita suas credenciais e apenas um código 2FA.
4. Sistema automático de furto explora a falha exposta em 1 e realiza o saque do saldo da vítima.
5. Sistema automático explora a falha exposta em 2.3 de forma a trancar a vítima fora de sua conta e impedir o cancelamento.

Cenário 3:

1. Hacker cria uma página idêntica a da Foxbit e registra um domínio de nome parecido (Imagem 3 - Art.1).
2. Contrata o serviço de propagandas da Google, AdWords, para aparecer no topo dos resultados em pesquisas (Imagem 2 Art.1).
3. Vítima cai na página falsa, acreditando estar lidando com a Foxbit digita suas credenciais e mais de um código 2FA.
4. Hacker utiliza os códigos 2FA posteriores para realizar o saque da conta da vítima sem e-mail de confirmação (2.2).
5. Hacker explora a falha exposta em 2.3 de forma a trancar a vítima fora de sua conta e impedir o cancelamento.

Os casos de furto por mim estudados todos apresentam características do cenário 1 e 3, não encontrei casos que explorem o cenário 2 até o momento apesar de ser uma possibilidade.

É importante frisar que o modelo de segurança 2FA na implementação atual da Foxbit tornava as contas dos clientes mais inseguras, deixando as vítimas indefesas mesmo se houvesse tempo hábil para reagir e cancelar as transações indevidas. Algo que foge ao propósito do 2FA elucidado na Imagem 18 pela bolsa. Os Hackers na realidade usaram ele como um mecanismo para facilitar os furtos.

É necessário que, para fins de auditoria, uma plataforma com características financeiras mantenha registros (logs) de todas as ações que são feitas pelos clientes dentro delas. Uma pessoa de fora do círculo não tem como saber se eles são de fato mantidos, mas supondo-se que tenham, significaria que ao longo de pelo menos 10 meses a Foxbit/Blinktrade tiveram conhecimento de como eram feitas essas invasões ou possuíam recursos suficientes para ter esse conhecimento.

5. Agradecimentos

Este relatório não seria possível sem a ajuda da comunidade, foram diversas pessoas entrevistadas e algumas dessas permitiram a realização de perícia por mim em suas máquinas.

Agradeço aqui pela solicitude de:

• Evando de Oliveira
• Mariano Portela
• Cézar Ribeiro
• Demais pessoas que não quiseram ser identificadas

Agradeço também o apoio jurídico dos advogados:

• Dr. Boaz Bezerra
• Dr. Bruno Cardoso

Muitas das informações constantes aqui foram obtidas em:

• Grupo Bitcoin Brasil no Facebook: https://www.facebook.com/groups/480508125292694
• ReclameAqui: https://www.reclameaqui.com.br/

6. Resposta oficial da Foxbit e Blinktrade

BlinkTrade: https://youtu.be/4vvXDdYYnjw
Foxbit: http://cryptowatch.com.br/foxbitrespostapublicavulnerabilidades/