Cloudflare, como fazer direito e não revelar seu ip real

Artigo original por Martin Hanic traduzido e adaptado por Leandro Trindade

Olá pessoal, estou trazendo aqui um artigo muito bom e direto que normalmente recomendo aos meus clientes na hora de configurarem seu Cloudflare. Chegou a um ponto em que vi que a utilidade e valor dele mereciam uma tradução digna para o português. Vale a pena a leitura.

• Introdução
• Passos recomendados pela Cloudflare
• Lista branca de endeços IP da Cloudflare
• [Ataque] Identificar o IP de um site usando o Shodan / Censys
• [Ataque] Identificar o IP de um site usando o Project Sonar
• Modo SSL e o certificado do servidor
• [Ataque] Identificar o IP de um website usando o certificado de origem da Cloudflare
• [Ataque] Identificar o IP de um website usando os logs de transparência de Certificado
• Linhas guia gerais sobre segurança de websites
• Remover todos os registros de DNS que não estão sendo usados
• [Ataque] Consultar servidores de DNS antigos
• Rodar o email em um servidor/serviço separado
• [Ataque] Identificar servidores com múltiplos propósitos
• Após mover o site para o Cloudflare, mudar o(s) endereço(s) IP do(s) servidor(es)
• [Ataque] Buscar dados históricos de DNS/HTTP
• Você precisa fazer mais
• Domínios alternativos para seus servidores
• VHOST Padrão
• Vazamento de aplicação web por comunicações externas (OOB)
• [Ataque] OOB via XXE
• [Ataque] OOB via SSRF
• [Ataque] OOB via DNS
• [Ataque] OOB via MAIL
• [Ataque] OOB via APIs públicas
• [Ataque] Erros de Aplicação
• [Ataque] Vazamentos históricos
• [Ataque] Enumeração de domínios
• Conclusão

Introdução

Se você está lendo essa publicação, você provavelmente é ou pretende ser um usuário da plataforma Cloudflare (ou uma CDN similar). Apenas para explicar brevemente a Cloudflare é uma CDN distribuída por todo o globo, o que faz com que suas páginas carreguem mais rápido e oferece proteções complexas de websites na forma de WAF e bloqueio de DDoS (ao esconder seu endereço IP real).

As dicas incluídas neste artigo não são voltadas apenas para usuários da Cloudflare, mas são dicas gerais de OPSEC (segurança de operação) para todas as soluções similares que dependem da confidencialidade de seus endereços de IP reais. Isso pois se um atacante conseguir encontrar seu endereço IP real, ele pode ultrapassar essa proteção e voltar os ataques a seu servidor diretamente.

O objetivo dessa publicação é mostrar o que precisa ser feito para se obter uma configuração segura e funcional, explicar porquê todas as contra-medidas são realmente necessárias através da demonstração dos ataques que elas mitigam de forma a não revelar seu IP de origem.

Passos recomendados pela Cloudflare

Após terminar a configuração de sua conta Cloudflare, você será apresentado ao seguinte guia: Primeiros passos recomendados para todos os usuários da Cloudflare.

A maior parte dele cobre todos os passos necessários para ter uma configuração funcional, mas ele contém dois importantes passos de segurança.

Lista branca de endeços IP da Cloudflare

Esse primeiro é o mais importante:

    Passo 1: Coloque em lista branca os endereços IP da Cloudflare

O título diz tudo. Simples e claro. No entanto, para pessoas que não são focadas em segurança, isso pode ser um pouco confuso, já que podem pensar no seguinte:

Coloque os endereços IP da Cloudflare em uma lista branca, pois se você tiver um firewall isso tornará possível que acessem seu site sem serem bloqueados ou colocados em uma lista negra.

Isso, porém, não é verdade. A verdadeira idéia por trás disso é:

Coloque os endereços IP da Cloudflare em uma lista branca e rejeite qualquer outra coisa!

Isso é para permitir acesso ao seu site apenas pela Cloudflare e evitar que o resto do mundo (Crawlers) acesse ele diretamente e veja que conteúdo é oferecido em um endereço IP específico/host.

E se eu não fizer? Como alguém pode me achar em uma rede mundial gigantesca?

[Ataque] Identificar o IP de um site usando o Shodan / Censys

A primeira coisa que um atacante irá fazer quando estiver buscando um servidor é consultar o Shodan ou o Censys, ambos são motores de busca para dispositivos conectados à internet. Isso usando uma busca simples como:

http.title:"Título do seu site"

Assim ele pode buscar todos os endereços IP de servidores que entreguem um site com esse título específico. Fácil. E ainda tem muito mais para procurar.

[Ataque] Identificar o IP de um site usando o Project Sonar

Imagine se fosse possível procurar a internet inteira por servidores escutando em portas comuns e depois coletar os dados da resposta HTTP (o site oferecido) de todos eles. Bom, é possível sim. E algumas pessoas fazem isso semanalmente e publicam os resultados online. Elas não são tão grandes como você deve pensar, um grupo de dados é de aproximadamente 60Gb comprimidos. Dê uma olhada:
Project Sonar HTTP
Project Sonar HTTPS

Então não apenas o atacante pode pesquisar o conjunto de dados pelo título do seu site para pegar o endereço IP do servidor, mas ele pode também pesquisar todos os dados históricos do período em que seu site ainda estava disponível publicamente.

Modo SSL e o certificado do servidor

Outra boa idéia é habilitar o SSL entre a Cloudflare e seu servidor de “origem”. Já que o LetsEncrypt existe, todos procuram pela opção completa: Full (strict).


Passo 4: Escolha um modo SSL. Uma resposta rápida para essa pergunta é: apenas escolha “Flexível” (Flexible) se o seu servidor web de origem não consegue aceitar conexões seguras (HTTPS). Escolha “completa” (Full) se você tem um certificado SSL auto assinado, e escolha completa rigorosa (Full strict) se você tem um certificado SSL válido emitido por uma autoridade certificadora.

Até mesmo a Cloudflare oferece a você certificados gratuitos para seu servidor de origem.


Use o CA de origem para gerar certificados para seus servidores de origem, usando wildcards para cada zona, de forma a manter os SANs no mínimo possível. Atualize a configuração de SSL de cada zona do modo “Flexível” ou “Completo” para modo “Rigoroso” (Strict), agora você terá um certificado CA de origem ou um CA público instalado protegendo todos os hosts dessa zona.

Mas tem uma pegadinha…

[Ataque] Identificar o IP de um website usando o certificado de origem da Cloudflare

Usar o certificado SSL de origem é uma solução boa e fácil, mas apenas se você fizer todas as outras coisas direito. Em uma situação em que configura seu webserver para servir um site neutro como VHOST padrão (para evitar ser identificado quando acessado via IP) mas seu provedor de hospedagem/ alcance de portas é pequeno e todos os outros servidores estão na mesma hospedagem, não é tão difícil checar o emissor do certificado em todos os IPs daquele alcance de IPs para determinar que hosts usam CloudFlare.

[Ataque] Identificar o IP de um website usando os logs de transparência de Certificado

Tenha em mente que, quando um certificado SSL é emitido, dados sobre ele são publicados nos Logs de Transparência de Certificados, isso é disponibilizado e buscável publicamente. Então se você emite um novo certificado para seu domínio (para ser usado pelo seu host de origem) ele é publicado e pode ser facilmente encontrado e os novos hostnames revelados. Basta dar uma olhada no cert.sh. Uma idéia bem melhor é utilizar um certificado do tipo wildcard.

Linhas guia gerais sobre segurança de websites

Se você leva segurança a sério, você provavelmente irá pesquisar por outros recursos com dicas de segurança, e você vai acabar esbarrando no seguinte blog da Cloudflare: General website security guidelines

Mesmo o título dizendo “linhas-guia gerais”, todas as dicas incluídas são muito importantes.

As seguintes linhas guias de segurança de websites são apropriadas para todos os clientes da Cloudflare.
Não limite a quantidade ou reduza a velocidade de requisições dos endereços IP da Cloudflare.
Certifique-se de que está vendo o endereço IP original de seus visitantes nos logs.
Remova todos os registros de DNS que não estiver usando.
Rode o email em um servidor/serviço separado.
Depois de mover o site para a Cloudflare, mude o endereço IP do servidor.
Use limitação de quantidade de requisições para prevenir ataques de Brute Force e DDoS de camada 7.
Cheque as configurações de firewall de aplicação (WAF) para evitar ataque dinâmicos.

Vamos dar uma olhada mais perto nos mais relacionados a esse tópico.

Remover todos os registros de DNS que não estão sendo usados

Se você está movendo seu domínio para um CDN, tenha em mente que o CDN irá agir como um DNS autoritativo apra o domínio, não há necessidade de manter a zona antiga do servidor (ou até mesmo o servidor/serviço DNS). Assim que a troca for completa, remova o domínio/zona de seu servidor DNS.

Lembre-se de remover os registros PTR (entradas de DNS reverso) para o endereço ip também.

[Ataque] Consultar servidores de DNS antigos

Uma das coisas que um atacante irá fazer durante sua busca pelo endereço IP de origem é procurar em todos os endereços IP conhecidos pelas portas 53/udp e 53/tcp para encontrar um servidor DNS. Se você não removeu os registros DNS antigos do seu servidor DNS e não alterou seu endereço IP de origem depois da troca para o Cloudflare, ou caso as entradas de DNS apontem para o endereço IP novo por conveniência, você acaba de vazar seu endereço IP de origem.

Lembre-se que uma busca similar será feita para buscas de DNS reverso de todos os seus endereços de IP (ou IPs dos seus hosts), apenas para verificar que eles não retornem o nome do seu servidor alvo (ou seus alias).

Rodar o email em um servidor/serviço separado

Não rode o seu servidor de email (ou outro serviço público) no mesmo servidor que seu servidor web. Além dos problemas com performance, e todas as boas práticas de infosec, é uma péssima idéia em temos de OPSEC. Tenha em mente que os registros MX (entradas DNS para entrega de email, apontando para seus servidores de email) não são repassados via proxy pela Cloudflare e estarão apontando para o IP real do seu servidor de email. Então se ele for o seu servidor web também, bom, isso é um problema.

Não se esqueça de revisar seus registros SPF também.

Você pode levar em consideração a possibilidade de mudar seu serviço de email para a nuvem também se possível (e desejável), e usar o Gmail por exemplo.

[Ataque] Identificar servidores com múltiplos propósitos

Como parte do processo de coleta de informações, um atacante irá (em um dos seus primeiros passos) checar o servidor de email relacionado a suas entradas DNS. Isso inclui:
registros MX – nomes / endereços IP dos seus servidores de email
registros TXT – contendo registros SPF com hostnames, endereços de IP ou alcances de IP de servidores de email “autoritativos”

Armado com esse conhecimento um atacante irá realizar um portscan dos endereços de IP e ranges de IP para checar pela presença do servidor web alvo.

Após mover o site para o Cloudflare, mudar o(s) endereço(s) IP do(s) servidor(es)

Essa regra é a mais essencial e deve ser escrita com grandes letras vermelhas on topo de todas as recomendações.

DEPOIS DE MOVER O SEU SITE PARA A CLOUDFLARE, MUDE O(S) ENDEREÇO(S) IP DO SERVIDOR(ES).

Não faz nenhum sentido esconder um endereço de IP se ele é o mesmo IP antigo que você usou por anos e que é publicamente conhecido. Então depois de configurar a proteção do CDN, mude o IP, ou melhor ainda, mude o host também. Se você quer melhorar mais ainda, coloque um balanceador de carga baseado em nuvem (como o Amazon ELB) na frente, apenas para ter mais uma camada de proteção.

[Ataque] Buscar dados históricos de DNS/HTTP

Não é uma grande revelação que todos os dados na internet são arquivados de um jeito ou de outro. Apenas para lembrar o meme É impossível deletar coisas da internet. Isso é válido para entradas DNS também. Além dos serviços online que podem ser usados para buscar dados históricos de DNS, como por exemplo o SecurityTrails, um atacante pode simplesmente baixar todos os conjuntos de dados históricos do Project Sonar e buscar dentro deles.

Você precisa fazer mais

Pode parecer que já são muitas contra-medidas a fazer só para esconder seu endereço de IP, mas você ainda precisa fazer mais. Ainda existem outros métodos (ou canais) pelos quais um IP pode vazar. E ainda tem mais ataques dos quais você precisa estar atento.

Domínios alternativos para seus servidores

É uma boa prática usar um domínio alternativo para seus servidores de testes (isso se você realmente precisa deles públicos), ou apenas para sua conveniência, poder acessar seus servidores de produção de forma direta. Aqui vão algumas dicas que você deve manter em mente:
Escolha um nome de domínio que não seja relacionado a você ou seu domínio principal: Se seu domínio é exemplo.com, não escolha exemplo-dev.com, uma vez que isso pode acabar revelado por uma busca textual em bancos de dados de DNS, ou nos logs de transparência de certificados. Ao invés disso, escolha algo completamente não relacionado como dominiodoido.wtf.
Use um serviço de registro proxy para seu domínio: Não use o nome da sua empresa ou detalhes de contato para ele, uma vez que ele pode ser usado para identificar o domínio principal. Ao invés disso use um serviço de registrador terceirizado (proxy-registrant). Não use uma pequena empresa local como registrador (uma vez que isso torna mais fácil de enumerar todos os registros) para todos os seus domínios.
Use um certificado SSL gratuito: Use o LetsEncrypt, ou um serviço similar, para obter um certificado SSL válido. O objetivo é não ter ele ligado à sua empresa.
Domínio principal não resolvível: não adicione um registro DNS para o domínio em si, apenas para subdomínios/hosts. Isso é apenas para manter a ilusão de que o domínio não está sendo utilizado, ex: dominiodoido.wtf has no A record.

VHOST Padrão

Pelo bem do anonimato, é uma boa prática configurar o VHOST padrão do servidor web para algo que não seja relacionado com sua empresa/site. Uma boa idéia é usar o placeholder genérico, como o It works! do Apache.

O motivo é servir essa página no lugar da sua página protegida, quando acessada via um endereço de IP e não um host válido (cabeçalho host). Desta forma você não acabará indexado por scanners que acessam endereços de IP ao invés de nomes de host, e isso torna as coisas um pouco mais difíceis para atacantes buscando a sua página em um grupo de endereços IP.

Vazamento de aplicação web por comunicações externas (OOB)

Lembre-se que ainda é possível revelar o verdadeiro endereço de IP do seu servidor através de comunicações externas (Out-Of-Band). Esse é o motivo pelo qual um servidor web, e outras partes da aplicação como o BD, não devem ser autorizados a iniciar conexões com a internet. Regras de firewall restritivas (lista branca) deve ser estabelecidas de forma a negar qualquer comunicação externa (que não seja relacionada com requisições HTTP recebidas). Vamos dar uma olhada em alguns exemplos.

[Ataque] OOB via XXE

Se sua aplicação processa requisições XML ou documentos, não realiza a sanitização de entrada bem e o seu parser de XML não está devidamente configurado, um atacante pode usar essa funcionalidade para forçar o servidor a carregar uma entidade externa ( XXE ) ou um DTD remoto. Neste caso, o servidor web realizaria uma requisição para um servidor controlado pelo atacante via HTTP(s)(ou FTP, SMB, GOPHER,..) revelando seu endereço de IP.

Mesmo que conexões de saída sejam proibidas pelo seu firewall, resolver o nome do host a partir da requisição pode ser o suficiente para revelar o IP (como descrito abaixo).

Tenha em mente que alguns parsers de JSON suportam XML também, e podem ser capazes de lidar com requisições XML mesmo que você não as use.

[Ataque] OOB via SSRF

Os mesmos resultados descritos na sessão acima também podem ser obtidos se um atacante conseguir persuadir a aplicação a realizar uma requisição modificando um parâmetro controlado pelo usuário, que seja usado como uma URI ( SSRF ) ou nome de arquivo ( RFI ) pela aplicação.

É bom mencionar que o impacto desses ataques (XXE, SSRF, RFI) é bem mais sério do que a possibilidade de vazar os endereços IP do servidor.

[Ataque] OOB via DNS

Se o servidor web tem a capacidade de realizar queries DNS diretamente (ex: esteja rodando um servidor de cache DNS local), e o atacante seja capaz de forçar o servidor a realizar uma requisição em um servidor DNS sob seu controle, os IPs do servidor serão revelados.

Lembre-se que mesmo que sua aplicação web não tenha nenhuma funcionalidade que possa ser usada de forma maliciosa dessa forma, alguns frameworks de aplicação realizam checagens automaticamente em background. Por exemplo, resolvendo o conteúdo do cabeçalho HTTP X-Forwarded-For.

[Ataque] OOB via MAIL

Se sua aplicação é capaz de enviar e-mails (diretamente ou através de um servidor SMTP externo), o que provavelmente é se ela realiza cadastro de usuários, lembre-se de verificar o conteúdo dos cabeçalhos de email, de forma a se certificar que o endereço de IP real do remetente (servidor) não esteja incluído.

[Ataque] OOB via APIs públicas

Usando o VirusTotal para verificar arquivos enviados para sua aplicação web? Tenha em mente que a URL submetida e nomes de DNS resolvidos são armazenados no banco de dados deles. Você pode consultar no VirusTotal informações sobre um domínio ou IP.

Procurar dentro de serviços públicos por requisições vindas de seu domínio “oculto” pode revelar o verdadeiro IP do seu servidor.

[Ataque] Erros de aplicação

Erros em uma aplicação web e API devem ser apenas genéricos, não revelando nenhuma informação sensível, como os endereços IP do servidor (ou hostname alternativo). Bom, algumas vezes eles não são, e erros como Não foi possível conectar com host/IP. ou Não foi possível processar requisição para o host/IP. podem ser tudo o que um atacante está procurando (no momento).

[Ataque] Vazamentos históricos

Não existe 100% seguro. Esse é o motivo para haverem vazamentos históricos (e parciais) de bancos de dados antigos da Cloudflare. Um deles deu origem ao Crimeflare. Use ele para buscar o seu domínio por vazamentos antigos.

[Ataque] Enumeração de domínios

Essa checklist é simples:

1. Pegue todos os domínios possíveis pertencendo à empresa ou indivíduo alvo
2. Obtenha todos os hostnames existentes e subdomínios em todos os domínios
3. Obtenha todos os endereços IP associados com esses hostnames
4. Pegue registros PTR para os IPs
5. Pegue todos os ASN/ Blocos de IP pertencentes à empresa alvo
6. Pegue a listagem de hospedagens que a empresa alvo está usando
7. Analise
8. Repita

Esses são os primeiros passos que qualquer atacante irá fazer. Não apenas uma vez mas em diversas, diversas iterações incluindo todas as informações obtidas na rodada anterior. O objetivo é obter o máximo de informações possível que possam ajudar em todos os outros ataques.

Nossa, isso parece muito trabalhoso, e chato.

De fato é, mas este é o motivo porquê ferramentas como Sublist3r ou OWASP Amass existem.

Conclusão

Espero que este “pequeno” POST tenha sido útil para você, e possa ter feito notar quais passos devem ser tomados para ter um setup realmente funcional, além de ter explicado alguns ataques que podem levar ao vazamento do seu IP original.

Mas existem tantos! Como posso checar tudo isso?

Não se preocupe, podemos te ajudar com isso 😋: https://citadelo.com

Fonte: https://citadelo.com/en/blog/cloudflare-how-to-do-it-right-and-do-not-reveal-your-real-ip/

Como reduzir o preço do Uber

Como a lista da Atlas pode ter vazado e por que ela é um pote de ouro para um hacker

 (Foto: Shutterstock)

Este artigo foi criado para o portal do bitcoin e foi originalmente publicado em https://portaldobitcoin.com/como-a-lista-da-atlas-pode-ter-vazado-e-por-que-ela-e-um-pote-de-ouro-para-um-hacker/

Dizem que o pior de uma catástrofe não é ela em si, mas a repercussão dos dias seguintes. Nos olhos de um hacker, ou golpista, a lista de nomes da Atlas é um verdadeiro pote de ouro.

A lista contém o saldo em BTC, nome completo, email e telefone de mais de 260 mil clientes da plataforma financeira de arbitragem Atlas Quantum.

Olhando através desses olhos nada amigáveis o que temos na verdade é uma lista de alvos, grandes e rechonchudos, objetivos de roubo, e informações suficientes para começar a trabalhar.

Vejo muitas similaridades entre esse vazamento e o que ocorreu no banco Inter mais cedo esse ano, até mesmo por ambas as fintechs adotarem uma infraestrutura em comum.

Primeiro, quais medidas devo tomar?

Dependendo da sua posição, o vazamento de dados pode ser até mais catastrófico do que dinheiro em si. A lista contém diversas pessoas públicas, aqui estão em risco não só os ativos digitais mas sua integridade física, principalmente se você está nos top 10 mais ricos. O vazamento de saldos dá uma boa idéia de onde mirar. No meio hacker é conhecido que telefone = endereço, nome completo, CPF, etc. Um beijo pro CADSUS.

Você pode verificar se seus dados foram vazados no seguinte site: https://haveibeenpwned.com basta digitar seu e-mail no campo de busca, ele também vai te informar de outros vazamentos que possam conter seus dados, a referência cruzada entre vazamentos é um prato cheio de informações para os hackers.

Caso o resultado dê positivo, a medida a se tomar é não acreditar em nada mais que chegue a seu e-mail vazado, nem mesmo mensagens no seu telefone. A primeira coisa que os golpistas irão tentar é o mais fácil: usar suas informações pessoais para tentar te enganar.

Como se proteger

1ª medida: email

Ok, agora é hora de criar um email novo, você vai passar a ter um email só para exchanges e assuntos relacionados ao Bitcoin, isso é uma boa prática de segurança, neste exemplo vamos chamar ele de emaildosmeusbitcoins@gmail.com. A senha desse email deve ser única, usada SOMENTE nele.

Agora dê uma passada em todas as exchanges que você tem conta e troque seu email de cadastro. A dica no caso do Gmail é que você cadastre ele como sendo emaildosmeusbitcoins+atlasbla@gmail.com para a Atlas, emaildosmeusbitcoins+binancexyz@gmail.com, para a Binance, e assim por diante. O Google ignora tudo depois do + (sinal de mais), experimente enviar um email pro seu endereço + algo e ele chega sem pestanejar.

Reparem que no final eu coloquei 3 letrinhas aleatórias, o texto aleatório ajuda muito a dificultar que hackers encontrem seu login em novos vazamentos, não somente isso, tal medida evita phishing — ao receber email da exchange você tem uma garantia a mais de que veio dela mesmo pois só ela vai saber o que você colocou depois do + -.

Na hora de escolher as letras aleatórias, lembre-se: paranoicos de verdade dão murro em teclado. Não se preocupe de esquecer seu login, para relembrar basta olhar em que endereço chegaram os emails.

É importante que você não possa mais entrar nas plataformas com seu email antigo vazado, isso vai evitar que atacantes tentem resetar ou adivinhar sua senha em todas que tiver conta cadastrada, e acredite, isso vai acontecer muito ainda.

2ª medida: senha

Apesar de o vazamento não incluir as senhas dos cliente, o hacker ainda pode cruzar as informações com outros vazamentos. No comunicado oficial o CEO da Atlas afirma que estavam criptografadas, mas não sabemos exatamente qual cifra e se elas realmente estavam seguras.

Como eu mencionei, é importante manter uma senha diferente para cada serviço que usa, desde email até cada conta de exchange, mas a questão sempre é: como vou lembrar de tantas senhas assim?

É aí que entram gerenciadores de senha como o LastPass, KeePass e 1Password, o último sendo meu favorito por motivos que fogem do escopo aqui. Ao invés de reusar a mesma senha em todos os lugares você pode usar senhas aleatórias, através destes aplicativos você precisa lembrar apenas de uma senha para abrir seu cofre de senhas, ou seja, sua segurança fica concentrada em um ponto, então cuide bem dele.

Aproveite que já está trocando seu email nas exchanges e troque também suas senhas com as geradas por um destes aplicativos, você vai aprender a amá-los em pouco tempo.

3ª medida: telefone de recuperação

No dia 28 de dezembro, o especialista em segurança John McAfee (o do antivirus) teve sua conta no Twitter invadida por um descuido: o hacker sabia seu número de telefone. Sim, hoje em dia nada mais é necessário além de um simples número de telefone.

Existem falhas no protocolo de telecomunicações, além da possibilidade de se corromper funcionários de empresas de telefonia para roubar temporariamente o seu número, recebendo mensagens e ligações em seu lugar durante o período, recentemente esse tem sido o modelo de ataque preferido dos hackers.

O perigo mora na recuperação de senhas do seu email, redes sociais, contas em algumas exchanges, etc. Ou seja, se alguém pegar seu número por alguns segundos ele pode ter acesso a todas as suas contas que possam ser recuperadas por telefone.

A melhor medida a se tomar agora é trocar o telefone de recuperação do seu email e redes sociais, para manter as coisas simples, escolha um parente de muita confiança e troque o telefone de recuperação de suas contas para o dele, isso já irá mitigar o problema. Só não deixe o número vazado cadastrado como seu telefone de recuperação em hipótese alguma. Essa dica vale principalmente para os maiores investidores da lista.

Ative também o 2FA no Email, WhatsApp (Na tela de configurações), no Facebook, Twitter e onde mais tiver, use somente 2FA via aplicativo e negue todo 2FA por SMS, pode não parecer um risco alto mas alguém personificar você pedindo dinheiro aos seus familiares ou para dar golpes em terceiros é algo muito comum.
Adendo

Se você está na lista dos mais ricos todo cuidado é pouco, considere o uso de seguranças particulares para evitar sequestros ou assaltos. Eu ouvi dizer que a Europa está excelente essa época do ano…

Afinal, o que aconteceu?

A pergunta que fica no ar é o que aconteceu para tamanho vazamento? Não dá para ter certeza do motivo exato sem acesso aos logs internos da Atlas, mas olhando de fora da para ter uma ideia, para isso temos que analisar as cartas que estão na mesa.

Para tentar explicar o incidente começamos olhando para as informações em si, os dados vazados são algo que estariam à disposição de qualquer funcionário de suporte da empresa. A Atlas cresceu muito no último ano, a demanda por suporte com certeza estourou sem dar tempo suficiente para ajustar o modelo de confiança da plataforma.

Inside Job?

Então foi um inside job? Não necessariamente… Sabemos que o elo mais fraco de qualquer sistema de segurança são as pessoas, e contra isso não há dúvidas, um funcionário triste e carrancudo é algo muito fácil de se encontrar numa empresa desse porte.

Mas existe ainda o fator engenharia social para se levar em conta, uma empresa grande pode ser difícil de se invadir, a menos que a pessoa trabalhe lá. O vetor mais comum é o reúso de senhas: basta um funcionário leigo não ter prestado a devida atenção a uma senha vazada anteriormente que já se tem um bom caminho para seguir.

Ninguém está protegido contra isso, plataformas financeiras no entanto costumam mitigar esses riscos controlando de perto o círculo de confiança e os acessos. Isto é: um funcionário de suporte precisa mesmo saber tudo sobre todos? Ou só aqueles que pedem ajuda e somente ao longo do ticket?

Eu não descarto também um acesso indevido ao sistema de suporte interno por vias de invasão, o sistema aceitava plenamente o cadastro de scripts no nome do cliente, pode-se até observar um cookie jar em meio aos nomes vazados. Vale lembrar que recentemente a Atlas passou por uma reconstrução de sua plataforma, e com código novo surgem bugs novos.

Por que um vazamento, e não um roubo?

Agora vamos olhar um pouco pelos olhos do invasor, isso sempre ajuda, vamos supor que você tenha obtido acesso ao sistema interno de uma plataforma financeira, qual a primeira coisa que você tenta fazer? Roubar dinheiro.

Vazar informações dos clientes parece algo muito simples para se queimar uma ficha de acesso tão valiosa assim, um atacante só faria essa publicação mesmo caso não tenha obtido acesso a fundos, e apenas após uma boa sessão de extorsão mal sucedida — vide caso do Inter.

Acho difícil a pessoa ter obtido acesso ao banco de dados como muitos predizem, caso contrário os dados vazados poderiam ser bem mais completos e suculentos. Me parece que a real intenção do invasor não foi obtida, e esse vazamento foi, de fato, uma vingança.

Testes de invasão na Plataforma

No último mês, atendendo o desejo da comunidade, realizei testes de penetração não invasivos no sistema da Atlas de forma a dar uma colocação no ranking de segurança brasileiro. Diante destes testes, levantei algumas falhas de segurança e elaborei provas de conceito enviadas diretamente à diretoria tecnológica deles, somente a pessoas de confiança.

As questões levantadas por mim não tinham relação direta com o ocorrido neste vazamento, nenhuma permitia acesso ao sistema de suporte em questão. Foram recebidas pelo setor de tecnologia e algumas falhas já haviam sido corrigidas, outras ainda estavam em processo de correção.

Em virtude deste vazamento de dados, eu irei adiar a publicação das falhas encontradas por tempo indeterminado, primeiro para não fornecer munição ao inimigo, visto que as vítimas já vão receber atenção suficiente agora, segundo para não interferir com as investigações.

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:

Manifesto pela segurança da tecnologia no Brasil (especialmente criptoativos)

Vem surgindo muitos questionamentos a respeito dos meus estudos de segurança no mercado de criptoativos. O mais comum é de que estou trabalhando para algum concorrente em prol de difamar empresas, e esse é exatamente o oposto de minhas intenções.

Decidi escrever um mini-manifesto explicando minha visão de forma resumida, mini pois foi elaborado para ser publicado no facebook (ninguém lê textão). Segue:

O Brasil está no 7o lugar do mundo em crimes cibernéticos, mas é um dos países que menos investem em segurança de dados.

A grande consequência é um movimento natural do mercado em se criar analistas de segurança para o mal (black hats), aplica-se aqui a lei da oferta e procura pois é muito mais rentável roubar do que fazer o bem no Brasil.

Só se torna analista para o bem (white hat) quem possui um forte compasso moral. E mesmo assim, a pessoa ainda sofrerá perseguição das empresas que ajuda, ameaças e processos.

Ao mesmo tempo, programadores são formados para não ligarem para a segurança. O mercado incentiva a criação de profissionais que desenvolvam o máximo de funcionalidades no menor espaço de tempo, a clássica metodologia do "vai cavalo", depois se algo der errado é só botar a culpa no hacker ou no coitado do programador.

Criamos aqui uma receita para o desastre:
1- um país que persegue white hats
2- que não incentiva a preocupação com segurança na hora de desenvolver
3- voltado à filosofia do jeitinho Brasileiro
4- e que tem um ambiente propício para a impunidade dos verdadeiros criminosos

Nós da comunidade de criptomoedas estamos na vanguarda da tecnologia, e temos a OBRIGAÇÃO de reverter esse quadro, não estamos apenas lidando com dinheiro, o que por si só já é motivo suficiente, mas com o dinheiro do futuro.

É importantíssimo nesse momento que nosso mercado se auto-regule de forma a evitar incidentes como os que vimos no último ano, esses incidentes só farão com que os reguladores e juízes atuem cada vez mais na proibição das criptos, e tenham motivos de sobra para isso.


Fontes:
https://www.cbsi.net.br/2018/05/brasil-e-lider-em-cibercrime-mas-pouco.html?m=1
https://webinsider.com.br/seguranca-da-ti-no-brasil-muito-falatorio-pouca-evolucao/


Deixando claro aqui, meu interesse não é financeiro e sim acadêmico, Satoshi Nakamoto não criou o Bitcoin pensando em lucro, até mesmo porquê os Bitcoins dele nunca foram movidos, quem faz software open-source e gratuito prioriza o caráter científico de suas pesquisas.

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