900 sites, 125 milhões de contas, 1 vulnerabilidade

Primeira tentativa

• Um scanner básico escrito em Python verificava variáveis de configuração do Firebase.
• Parava de funcionar em menos de uma hora devido a problemas de consumo de memória.

Segunda tentativa

• O scanner reescrito em Go não tinha vazamento de memória.
• Levaria mais tempo do que o esperado para escanear mais de 5 milhões de domínios.

Verificação manual de todos os domínios

• Cada item de um arquivo de texto com 550 mil linhas foi inspecionado manualmente.
• 136 sites e 6,2 milhões de registros foram confirmados, mas ficou claro que era necessário um método automatizado.

Catalisador

• A lista de sites potencialmente afetados foi analisada com um scanner auxiliar chamado Catalisador.
• Ele verificava automaticamente o acesso de leitura a coleções comuns do Firebase no site ou nos bundles .js.
• Foram coletadas amostras de 100 registros para avaliar o impacto dos dados e identificar os tipos de informação.
• O Supabase (concorrente open source do Firebase) foi escolhido para armazenar os resultados.

Números

• Total de registros: 124.605.664
• Nomes: 84.221.169
• E-mails: 106.260.766
• Números de telefone: 33.559.863
• Senhas: 20.185.831
• Informações de pagamento: 27.487.924
• Observe que esses números podem ser maiores do que o total real.

Lista de sites afetados

1. Silid LMS

• Sistema de gestão de aprendizagem para estudantes e professores.
• Exposição do maior número de registros de usuários, afetando 27 milhões de pessoas.

2. Rede de apostas online

• Composta por 9 sites, todos com designs diferentes.
• Alguns jogos eram manipulados para ter 0% de chance de vitória.
• Ao tentar relatar o problema, o suporte ao cliente tentou seduzir o pesquisador.
• Exposição do maior número de informações de contas bancárias: 8 milhões.
• Exposição do maior número de senhas em texto puro: 10 milhões.

3. Lead Carrot

• Gerador online de leads para cold calling.
• Um dos 3 sites com mais informações de usuários expostas, afetando 22 milhões de pessoas.

4. MyChefTool

• App de gestão comercial e aplicação de ponto de venda para restaurantes.
• Exposição do maior número de nomes e o segundo maior número de e-mails: 14 milhões e 13 milhões, respectivamente.

Resultados

• 842 e-mails enviados ao longo de 13 dias.
• 85% de entrega de e-mails.
• 9% de e-mails retornaram.
• 24% dos donos dos sites corrigiram a configuração incorreta.
• 1% dos donos dos sites responderam.
• 0,2% (2) dos donos dos sites ofereceram bug bounty.

Opinião do GN⁺

• Esta pesquisa mostra como uma configuração incorreta de segurança no Firebase pode acontecer com facilidade. É um caso importante para alertar desenvolvedores sobre a necessidade de atenção às configurações de segurança.
• Também fica claro que a reação dos donos dos sites variou bastante quando problemas de segurança foram encontrados. A maioria corrigiu o problema, mas alguns ignoraram ou não ofereceram recompensa adequada.
• As ferramentas automatizadas usadas para encontrar essas vulnerabilidades de segurança também podem ser úteis para outros pesquisadores de segurança. Ferramentas com funções semelhantes incluem OWASP ZAP e Burp Suite.
• Ao usar serviços em nuvem como o Firebase, é importante entender e aplicar corretamente as configurações de segurança. Uma configuração incorreta pode levar a vazamentos de dados em larga escala.
• Este caso também pode ajudar na comparação entre recursos de segurança e facilidade de uso ao considerar outros serviços, incluindo a alternativa open source Supabase. O Supabase é baseado em PostgreSQL e oferece funcionalidades semelhantes às do Firebase, mas é open source.

[GN⁺]

Opiniões do Hacker News

• Um usuário que trabalhou por muito tempo com Firebase menciona que problemas relacionados às regras de segurança sempre atormentaram o produto. Várias abordagens foram tentadas, mas ainda assim muitos bancos de dados continuaram vulneráveis. Isso acontece porque as regras de segurança do Firebase são um conceito novo e complexo, e os desenvolvedores tendem a não atualizar essas regras ao adicionar novos dados aos dados existentes. Além disso, a ausência de uma implementação de backend personalizada facilita varreduras em massa, e escrever regras de segurança para o banco de dados em tempo real é difícil e pouco escalável. No entanto, como varreduras automatizadas geralmente encontram apenas dados abertos, esse problema não acontece com tanta frequência quanto se imagina. Não há um problema técnico inerente à abordagem do Firebase em si, mas por ser um dos poucos backends baseados apenas nos dados armazenados e nas regras de segurança, ele é vulnerável a mal-entendidos, uso inadequado e a esse tipo de problema.
• Um usuário comenta que essa situação o faz lembrar dos casos de invasão às redes de fast-food dos Estados Unidos.
• Outro usuário aponta que, segundo a parte final do post, 75% dos sites com essa vulnerabilidade ainda estariam esperando o dump de dados, e avalia isso como uma loucura. Acrescenta que às vezes acha que deveria ser preciso ter uma certificação para poder mexer com computadores.
• Um usuário observa que escolher o mais barato e o mais rápido leva inevitavelmente a esse resultado, e menciona que as preocupações de alguns clientes/usuários ficaram ausentes da conversa, enquanto seus dados pessoais viraram o preço a pagar. Alerta que é preciso ter cuidado com as empresas listadas aqui cuja liderança não mudou, porque já foi repetidamente provado que muitas empresas não se importam o suficiente em proteger seus clientes.
• Outro usuário faz uma pergunta básica sobre a maioria dos apps mencionados neste post ter sido implementada inteiramente com JavaScript do lado do cliente hospedado estaticamente, e se o backend seria apenas uma configuração de Firebase 100% hospedada pelo Google. Se for esse o caso, comenta que não percebia o quão comum essa arquitetura era em sites com milhões de usuários.
• Um usuário faz a piada: 900 sites, 125 milhões de contas, 1 vulnerabilidade, 0 namoradas.
• Outro usuário expressa gratidão por ter escolhido há muito tempo um gerenciador de senhas e cartões virtuais por causa desse tipo de situação. Diz que a internet parece cada vez mais assustadora, porque a maioria das pessoas não sabe o quão frágil a web é nem o quão vulneráveis elas próprias são.
• Um usuário diz ter descoberto que um programa em Python com cerca de 500 threads vai usando cada vez mais memória com o passar do tempo, e pergunta se há mais informações ou alguma solução para esse problema. Menciona que seu scraper em Python também tem centenas de threads e parece consumir muita memória.
• Um usuário elogia o bom trabalho e diz que gostaria de saber como se chegou à conclusão de que o número de usuários afetados provavelmente seria ainda maior. Suspeita que alguns dos sites mencionados (apostas, Lead Carrot) devam estar cheios de dados de contas falsas.
• Por fim, um usuário agradece dizendo que o suporte ao cliente o fez rir.