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

 (env.fail)
3 pontos por GN⁺ 2024-03-19 | 1 comentários | Compartilhar no WhatsApp
  • Uma única regra de segurança do Firebase mal configurada levou à exposição de dados de usuários em centenas de sites, com um volume confirmado de cerca de 124,6 milhões de registros
  • A investigação começou procurando variáveis de configuração do Firebase em sites e nos bundles JavaScript carregados, e foi reescrita em Go por causa de problemas de memória no scanner em Python
  • O scanner auxiliar Catalyst verifica automaticamente se coleções do Firebase podem ser lidas e, com base em dados de amostra, estima o tipo e a escala das informações expostas
  • Entre os itens expostos agregados estão 84.221.169 nomes, 106.266.766 e-mails, 33.559.863 números de telefone, 20.185.831 senhas em texto puro e 27.487.924 registros de informações de pagamento
  • Os pesquisadores enviaram 842 e-mails de notificação ao longo de 13 dias, mas apenas 24% dos proprietários corrigiram a configuração, 1% respondeu e só 2 sites ofereceram bug bounty

Varredura de exposições do Firebase em escala de internet

  • Após o caso de violação da Chattr.ai, foi iniciada uma varredura em toda a internet para encontrar PII exposta por instâncias do Firebase mal configuradas
  • O primeiro scanner em Python verificava variáveis de configuração do Firebase em sites ou bundles .js carregados, mas ao operar com cerca de 500 threads o uso de memória aumentava e ocorria OOM em menos de 1 hora
  • Depois, o scanner foi reescrito em Go e executado contra 5,5 milhões de domínios, levando 2 a 3 semanas, mais do que a estimativa inicial de cerca de 11 dias
  • Só a revisão manual inicial já encontrou 136 sites e 6,2 milhões de registros, mas conforme a lista de candidatos cresceu, a automação completa se tornou necessária

Catalyst e estimativa da escala da exposição

  • O Catalyst recebe como entrada sites candidatos ou bundles JavaScript e verifica automaticamente se há acesso de leitura a coleções comuns do Firebase e a coleções mencionadas diretamente no JavaScript
  • Ao encontrar coleções legíveis, ele coleta uma amostra de 100 registros para identificar os tipos de informação presentes e multiplica isso pelo tamanho total da coleção para estimar o impacto
  • Como repositório de resultados, foi escolhido o Supabase, concorrente open source do Firebase baseado em PostgreSQL, e os dados organizados foram enviados para tabelas de banco de dados privadas
  • Os números agregados são os seguintes, e a escala real da exposição pode ser maior do que a mostrada
    • Total de registros: 124.605.664
    • Nomes: 84.221.169
    • E-mails: 106.266.766
    • Telefones: 33.559.863
    • Senhas: 20.185.831
    • Informações de pagamento: 27.487.924, incluindo dados bancários, faturas etc.

Sites com maior impacto

  • Silid LMS

    • Sistema de gestão de aprendizado para estudantes e professores
    • A exposição de 27 milhões de registros de usuários, incluindo nome, e-mail e telefone, foi a maior do levantamento

  • Rede de apostas online

    • Composta por 9 sites reestilizados entre si
    • Alguns giros foram manipulados para que a chance de vitória fosse 0%
    • Os detalhes de login de contas bancárias foram os mais expostos, com 8 milhões de registros
    • As senhas em texto puro também atingiram 10 milhões, o maior volume entre os sites afetados
    • Ao tentar reportar o problema, o suporte ao cliente fez insinuações durante a conversa

  • Lead Carrot

    • Serviço online de geração de leads para cold call
    • Ficou entre os 3 maiores volumes de dados expostos, afetando 22 milhões de pessoas

  • MyChefTool

    • Aplicativo de gestão empresarial e POS para restaurantes
    • Ficou em 1º lugar em nomes expostos e 2º em e-mails expostos, com 14 milhões e 13 milhões, respectivamente

Reações após a notificação

  • Os pesquisadores enviaram 842 e-mails ao longo de 13 dias
    • 85% foram entregues e 9% retornaram
    • 24% dos proprietários dos sites corrigiram a configuração incorreta
    • Apenas 1% dos proprietários respondeu
    • 2 proprietários de sites, equivalentes a 0,2%, ofereceram bug bounty

Leituras relacionadas

1 comentários

 
GN⁺ 2024-03-19
Opiniões no Hacker News

  • Trabalhei por muito tempo no Firebase, e o problema das regras de segurança continuou atormentando o produto
    Tentamos várias abordagens, como regras padrão que expiram automaticamente e mais educação, mas no fim ainda vemos muitos bancos de dados inseguros
    Os motivos são complexos: as regras de segurança no estilo Firebase ainda são um conceito pouco familiar, e muitas vezes um novo desenvolvedor que adiciona dados a um local existente não atualiza também as regras para acompanhar a mudança nos requisitos de privacidade desses dados
    Além disso, a “segurança por obscuridade” que backends próprios ofereciam desaparece, facilitando varreduras em larga escala
    Em especial, as regras do Realtime Database são difíceis de escrever e não escalam bem, mas as varreduras automáticas normalmente só procuram dados abertos, então qualquer coisa um pouco melhor que read write true já conseguia barrá-las
    Tecnicamente, a abordagem do Firebase em si não está errada, mas, por ser praticamente o único backend que usa um modelo centrado em dados armazenados e regras de segurança, fica mais sujeito a mal-entendidos, uso incorreto e incidentes como este

    • Para ser sincero, o modelo em que o frontend pode gravar dados diretamente no banco de dados sempre me pareceu suspeito, mesmo com regras de segurança
      No backend, validações e regras de segurança parecem parte da especificação, mas as regras de segurança do Firebase são um processo separado, então são fáceis de esquecer e precisam ser reavaliadas a cada novo recurso
    • Entrei em contato pelos canais de suporte do Google pedindo que ajudassem ou permitissem avisar os sites sobre o problema, mas só recebi como resposta que, se eu quisesse, eles poderiam criar uma solicitação de recurso em meu nome
      Acho que seria preciso escalar bastante dentro do Firebase para chamar a atenção de alguém capaz de avisar os proprietários dos projetos
    • Vendo https://firebase.google.com/docs/rules/basics, fico me perguntando se um modo de segurança simples, em que se escolhem apenas modelos predefinidos de regras de segurança, seria prático
      Por exemplo, será que modelos como “acesso apenas pelo proprietário do conteúdo” ou “acesso baseado em atributos/papéis” mencionados no texto conseguem cobrir os padrões da maioria dos apps, ou realmente são necessárias muitas regras personalizadas?
      O grande problema de escrever regras de segurança é que quase todo erro vira um problema de segurança, então, se não for necessário, você não quer mexer nisso
      Se as regras estiverem restritas demais, o app não funciona e isso aparece imediatamente; se estiverem abertas demais, o problema não fica evidente até alguém testar explicitamente o acesso excessivo
      Nesse contexto, também vale pensar em obrigar os desenvolvedores a escreverem casos de teste de exemplo de acesso negado para cada regra de segurança
    • Para nós, uma dica simples ajudou muito: um transpilador de regras chamado fireplan adiciona a todos os atributos a regra padrão "$other": {".read": false, ".write": false}
      Graças a isso, novos campos precisam ser adicionados explicitamente, tornando quase impossível que um novo valor “herde” sem querer uma regra existente
      Uso Firebase há mais de 10 anos, então não sei se as ferramentas de regras mais recentes já fazem isso
      O que realmente ajudaria seria suporte nativo para renomear campos ou alterar a estrutura de dados em cenários com várias versões de clientes difíceis de controlar, uma forma leve de testar regras sem subir o banco de dados e melhores informações de depuração quando regras falham em produção
      Sempre que houver uma falha, seria preciso registrar junto todos os valores acessados pela regra, para depurar falhas temporárias causadas por dados que mudam
    • Tenho defendido bastante o Firebase e o Firestore, mas concordo com tudo acima
      Este é um modelo conceitual que não foi explicado suficientemente
      Nos projetos, dizemos que cada coleção deve ter um perfil de segurança, como pública, dados de usuário, pública apenas para usuários autenticados ou somente administradores, e abordamos isso impondo essas categorias por meio de funções nas regras de segurança, em vez de escrever condições personalizadas para cada coleção
      Pensar em segurança no nível da coleção, e não do campo, reduz a mistura de intenções de segurança diferentes dentro de um mesmo documento
      Se uma coleção é pública, ela não deve conter campos que não sejam públicos; se necessário, dá para replicar dados de um contexto sensível para um contexto público com gatilhos do Firestore, mas não no sentido inverso
      O problema é que a intenção das regras precisa ser documentada fora das próprias regras, o que facilita aplicações incorretas; no passado, escrever testes também era doloroso, mas isso melhorou bastante agora

  • Lembra “How I pwned half of America’s fast food chains, simultaneously.”: https://mrbruh.com/chattr/
    HN: https://news.ycombinator.com/item?id=38933999

    • Escrevi os dois textos, e este é a continuação daquele post do blog
    • Normal. A sexta palavra do post do blog é um link para aquele texto
      After the initial buzz of [pwning Chattr.ai] had settled down, […]

  • Se não entendi errado, isso quer dizer que, até o fim do texto, 75% dos sites com essa vulnerabilidade ainda estavam abertos e com os dados passíveis de dump?
    Insano
    Alguns dias penso que deveria ser preciso ter licença para mexer em computadores

    • Muitas empresas não têm desenvolvedores em tempo integral
      Elas terceirizam para agências que criam sites; as agências continuam trocando desenvolvedores, colocam bons desenvolvedores no começo e depois entregam o contrato a desenvolvedores menos experientes, desde que a empresa não reclame
      O e-mail sobre a vulnerabilidade provavelmente foi ignorado como spam, encaminhado e abandonado, ou entrou na fila de reuniões de um PM como um item a ser corrigido enquanto se cobra o máximo possível do cliente
      Mesmo em áreas em que uma licença profissional é obrigatória, há muita gente incompetente licenciada
      Médicos também têm enormes exigências de formação e licença, mas não faltam médicos charlatões e praticantes licenciados de medicina alternativa
    • Triste, mas é verdade, e provavelmente o número é muito maior
      Fiz o melhor possível enviando e-mails personalizados para cada site, com o que foi afetado, como corrigir e como entrar em contato
    • Isso mesmo. Por isso não pude divulgar a lista de sites afetados, para impedir que agentes maliciosos explorassem imediatamente
    • Enquanto uma empresa não quebrar por causa de um vazamento de dados pessoais, para ela isso é custo de negócio, e esse custo é repassado aos usuários

  • Isso é a consequência inevitável de, no triângulo cheap-fast-good do PM, escolher barato e rápido
    Infelizmente, as preocupações de alguns clientes e usuários ficaram fora da discussão, e os dados pessoais deles viraram o custo
    Eu teria cautela com qualquer empresa listada aqui que tomou esse tipo de decisão e mesmo assim não trocou a liderança
    Já foi provado muitas vezes que muitas empresas não se importam o suficiente para proteger os clientes, e a história se repete

    • Concordo em geral, mas houve também alguns bons casos, embora raríssimos, de empresas que agradeceram e corrigiram rapidamente

  • Tenho uma pergunta bem básica sobre o Firebase: a maioria dos apps deste texto foi implementada sem código de servidor customizado, apenas com JavaScript do lado do cliente hospedado estaticamente?
    Quero dizer: o backend é uma configuração do Firebase 100% hospedada pelo Google?
    Se for isso, eu não sabia que essa arquitetura tinha ficado tão comum em sites com milhões de usuários

    • Sim. Ou é totalmente do lado do cliente, ou passa por um servidor que simplesmente repassa tudo de forma ingênua
      Quando uma API tem um modelo de segurança de permitir por padrão, inevitavelmente isso acontece
      Infelizmente, bibliotecas voltadas a desenvolvedores JavaScript costumam ter padrões inseguros, e GraphQL também parece ser uma área onde esse tipo de problema pode surgir
    • Pode ser uma mistura
      O Firebase também tem Firebase Functions, funções chamáveis na nuvem, e esse código não é público
      Mas tanto o Firestore quanto o Firebase Realtime Database exigem que o usuário configure regras de segurança; caso contrário, qualquer pessoa pode ler todos os dados
    • Parece uma configuração bem radical, mas pode funcionar se você codificar regras de autorização adequadas no esquema SQL do backend
      O importante é facilitar a escrita de regras de autorização corretas no backend

  • Quando vejo coisas assim, fico feliz por ter adotado há muito tempo um gerenciador de senhas e cartões virtuais
    Mesmo assim, a internet está ficando mais assustadora
    A maioria das pessoas não faz ideia de quão vulnerável a web é nem de quanto elas estão expostas

    • Acho que vai piorar daqui para frente
      Agentes de IA vão encontrar vulnerabilidades com muito mais eficiência do que bots, então parece que nos espera um futuro estranho
    • Com o tempo, os serviços tornam mais fácil criar sites e abstraem cada vez mais coisas, então os desenvolvedores deixam de saber o que precisam configurar
    • Só um gerenciador de senhas não basta
      É preciso usar um endereço de e-mail único para cada serviço em que você se cadastra
      Isso limita o dano quando ocorre um incidente e também impede que coletem informações públicas cruzando dados com outros serviços
      Às vezes, se chegar um e-mail malicioso nesse endereço único, você pode perceber a invasão antes mesmo do operador do site

  • Alguém sabe mais sobre a parte que diz que “um programa Python com cerca de 500 threads começa a consumir memória com o tempo”?
    Eu também tenho um scraper em Python com centenas de threads e ele parece consumir bastante memória
    Queria saber se há alguma solução de contorno ou se reescrever em outra linguagem é a única saída

    • Dá para fazer em Python, mas é preciso se aprofundar em como a contagem de referências do Python interage com threads
      Pessoalmente, prefiro processos a threads, e uso pools de workers e barramentos de mensagens em vez de memória compartilhada
      Essa solução também tem desvantagens e um pouco de overhead, mas reduz muito a preocupação com problemas de memória
      Para crawlers, como o número de processos é relativamente constante e o trabalho de cada processo é independente, o modelo de processos parece se encaixar melhor
    • import multiprocessing as threading
    • Não sei qual é exatamente o problema, mas, sinceramente, Python não é a linguagem certa para esse tipo de tarefa
      Reescrever é praticamente a única solução realista
    • Para esse uso, o certo é usar asyncio
      É um caso de uso que se encaixa muito bem

  • Bom trabalho
    Fiquei curioso sobre como chegaram à conclusão de que o número de usuários afetados provavelmente é maior na prática
    Pelo que parece, alguns sites, como os de apostas ou o Lead Carrot, podem ter muitos dados de contas falsas misturados

    • Ao revisar manualmente vários sites, vimos que o scanner automático verificava tipos de dados conhecidos, como números de telefone, pelos nomes das variáveis, então não identificava bem dados pessoais que não estavam em inglês
      É uma abordagem que funciona bem só em sites em inglês
    • Confirmei que os dados dos sites de apostas não eram falsos, mas não sei sobre o Lead
      O motivo de eu dizer que pode ser mais é que outros serviços que não estavam na lista varrida também podem estar vulneráveis