Languages

Monday, April 23, 2018

[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:



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:

6. Resposta oficial da Foxbit e Blinktrade

No comments:

Post a Comment