Eu comprometi metade das redes de fast food dos Estados Unidos ao mesmo tempo

Artigo original ↗ Discussão no Hacker News ↗

Um pesquisador de segurança descobriu que a plataforma de contratação Chattr.ai havia configurado incorretamente seu backend Firebase, permitindo que qualquer pessoa criasse uma conta, escalasse para administrador e acessasse senhas em texto plano e dados pessoais de funcionários e candidatos de grandes redes de fast food dos EUA. Os comentaristas debatem quanto da culpa recai sobre as marcas de restaurantes versus o fornecedor SaaS, os riscos legais e éticos de pentesting de “bom samaritano” não solicitado sob leis como a CFAA, e se a vergonha pública é justificável quando as empresas ignoram ou recompensam mal as divulgações. O fio também critica o Firebase e ferramentas semelhantes de backend-as-a-service como fáceis de usar de forma incorreta, argumentando que padrões fracos e regras complexas tornam vazamentos graves de dados quase inevitáveis para equipes inexperientes.

Escopo do debate sobre “pwn” e o título

  • Muitos argumentam que a postagem realmente descreve a compromissão da Chattr (uma SaaS de recrutamento) via Firebase, e não “metade das redes de fast food dos Estados Unidos”.
  • Outros contrapõem que expor PII de gerentes e candidatos em grandes redes é suficientemente impactante para justificar um título dramático.
  • Alguns sugerem que um título mais preciso nomeando a Chattr evitaria melhor a confusão e a reação exagerada de outros CISOs.

Responsabilidade do fornecedor e lei de proteção de dados

  • Discussão sobre se grandes marcas que usam a Chattr seriam legalmente responsáveis caso os dados dos candidatos fossem abusados.
  • Alguns dizem que a responsabilidade pode se estender a empresas que deixam de avaliar fornecedores (por exemplo, SOC2, PCI, HIPAA, leis estaduais, GDPR se houver cidadãos da UE envolvidos).
  • Outros enfatizam que muitas vezes não há exigência legal rígida de auditorias de terceiros; a fiscalização (FTC, SEC, etc.) é irregular e as penalidades costumam ser pequenas.

Má configuração do Firebase e segurança de BaaS

  • Há consenso de que dar a qualquer usuário autenticado acesso total de leitura e escrita é negligência flagrante.
  • Explicação das regras do Firebase: os padrões de produção são negar tudo, mas muitos desenvolvedores ainda escrevem regras inseguras como “auth != null”.
  • Discussão paralela sobre o Supabase: mais relacional e familiar, mas seus padrões de RLS e armadilhas também podem expor dados se usados de forma incorreta.
  • Crítica mais ampla ao Firebase (e em certa medida ao Supabase): consoles confusos, modelos de segurança complicados, ferramentas instáveis e a sensação de que “usar apenas Postgres + uma API simples” muitas vezes é mais seguro e simples.

Ética, legalidade e divulgação responsável

  • Debate sobre até onde um pesquisador sem solicitação deveria ir:
    • Alguns dizem para parar após confirmar credenciais expostas; acessar dados reais de usuários ou senhas arrisca responsabilidade no estilo CFAA.
    • Outros argumentam que é preciso demonstrar impacto (por exemplo, alcançar um painel de administrador, provar senhas em texto plano) para que o relatório seja levado a sério.
  • Vários comentários observam que a lei dos EUA sobre “acesso não autorizado” é nebulosa; alguns citam precedentes que dependem de alguma barreira real de controle de acesso ter sido contornada.
  • Diversos alertam que hackers de boa-fé ainda sofrem batidas policiais ou ameaças; outros pedem proteções de “Bom Samaritano”.

Bug bounties, incentivos e falta de agradecimento

  • Forte sentimento de que as empresas frequentemente ignoram ou reconhecem minimamente divulgações úteis, mesmo quando corrigem os problemas discretamente.
  • Alguns veem isso como gestão de risco jurídico: qualquer reconhecimento pode ser tratado como admissão.
  • Outros dizem que, se houve tempo para corrigir, houve tempo para enviar um agradecimento de uma linha.
  • Visões mistas sobre monetização:
    • Alguns insistem que vender exploits ou dados é antiético e ilegal.
    • Outros argumentam que pesquisadores mal pagos são racionais ao buscar mercados pagantes quando as empresas não executam programas de bounty justos.

Vergonha pública vs colaboração

  • Grande subthread sobre se a vergonha pública é eficaz.
  • Um lado argumenta que envergonhar empresas costuma ser a única alavanca que leva a mudanças reais e é apropriado para falhas de segurança graves (por exemplo, senhas em texto plano).
  • Outro lado diz que a vergonha geralmente leva à defensividade, acobertamento e inflação de palavras; incentivos positivos e engajamento construtivo são mais sustentáveis.
  • Vários distinguem entre envergonhar indivíduos (muitas vezes prejudicial) e envergonhar corporações (visto como às vezes regulação necessária pela publicidade).

Confiança em sistemas de contratação de terceiros

  • Alguns comentaristas dizem que agora evitam empregadores que terceirizam recrutamento para plataformas opacas, especialmente para empregos de baixa remuneração em que os candidatos têm pouca margem de manobra.
  • Outros observam que a maioria dos candidatos a empregos em fast food não tem meios nem poder de negociação para exigir práticas mais seguras, então a responsabilidade deve recair sobre empresas e reguladores.