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 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.