«Hice pwn a la mitad de las cadenas de comida rápida de Estados Unidos simultáneamente»

Artículo original ↗ Discusión en Hacker News ↗

Un investigador de seguridad descubrió que la plataforma de contratación Chattr.ai tenía mal configurado su backend de Firebase, lo que permitía a cualquiera crear una cuenta, escalar a administrador y acceder a contraseñas en texto plano y datos personales de personal y solicitantes de grandes cadenas de comida rápida de EE. UU. Los comentaristas debaten cuánta culpa recae en las marcas de restaurantes frente a su proveedor SaaS, los riesgos legales y éticos de realizar pentesting de “buen samaritano” sin solicitud bajo leyes como la CFAA, y si la vergüenza pública está justificada cuando las empresas ignoran o recompensan poco las divulgaciones. El hilo también critica a Firebase y a herramientas similares de backend como servicio por ser fáciles de usar mal, argumentando que los valores predeterminados débiles y las reglas complejas hacen que las fugas graves de datos sean casi inevitables para equipos inexpertos.

Alcance del “pwn” y debate sobre el título

  • Muchos sostienen que la publicación en realidad describe el compromiso de Chattr (un SaaS de reclutamiento) a través de Firebase, no de “la mitad de las cadenas de comida rápida de Estados Unidos”.
  • Otros replican que exponer PII de gerentes y solicitantes en grandes cadenas es lo suficientemente impactante como para justificar un título dramático.
  • Algunos sugieren que un título más preciso que nombre a Chattr evitaría mejor la confusión y la reacción exagerada de otros CISOs.

Responsabilidad del proveedor y ley de protección de datos

  • Se debate si las grandes marcas que usan Chattr tendrían responsabilidad legal si se abusara de los datos de los solicitantes.
  • Algunos dicen que la responsabilidad puede extenderse a empresas que no revisan adecuadamente a sus proveedores (p. ej., SOC2, PCI, HIPAA, leyes estatales, GDPR si hay ciudadanos de la UE involucrados).
  • Otros subrayan que a menudo no existe un requisito legal firme de auditorías de terceros; la aplicación de la ley (FTC, SEC, etc.) es irregular y las sanciones suelen ser pequeñas.

Mala configuración de Firebase y seguridad de BaaS

  • Hay consenso en que dar a cualquier usuario autenticado acceso total de lectura/escritura es una negligencia flagrante.
  • Explicación de las reglas de Firebase: los valores predeterminados en producción niegan todo, pero muchos desarrolladores aún escriben reglas inseguras como “auth != null”.
  • Discusión paralela sobre Supabase: más relacional y familiar, pero sus valores predeterminados de RLS y sus trampas también pueden exponer datos si se usan mal.
  • Crítica más amplia a Firebase (y en cierta medida a Supabase): consolas confusas, modelos de seguridad complicados, herramientas poco fiables y la sensación de que “usar solo Postgres + una API simple” suele ser más seguro y sencillo.

Ética, legalidad y divulgación responsable

  • Debate sobre hasta dónde debería llegar un investigador no solicitado:
    • Algunos dicen que hay que parar tras confirmar credenciales expuestas; acceder a datos reales de usuarios o contraseñas arriesga responsabilidad estilo CFAA.
    • Otros argumentan que hay que demostrar impacto (p. ej., llegar a un panel de administración, probar contraseñas en texto plano) para que el informe se tome en serio.
  • Varios comentarios señalan que la ley estadounidense sobre “acceso no autorizado” es difusa; algunos mencionan precedentes que dependen de si se eludió alguna barrera real de control de acceso.
  • Varios advierten que hackers de buena fe aun así terminan allanados o amenazados; otros piden protecciones de “Buen Samaritano”.

Bug bounties, incentivos y falta de agradecimiento

  • Fuerte sentimiento de que las empresas a menudo ignoran o reconocen mínimamente las divulgaciones útiles, incluso cuando corrigen los problemas en silencio.
  • Algunos ven esto como gestión del riesgo legal: cualquier reconocimiento puede tratarse como una admisión.
  • Otros dicen que si hubo tiempo para parchear, también hubo tiempo para enviar un agradecimiento de una línea.
  • Opiniones divididas sobre la monetización:
    • Algunos insisten en que vender exploits o datos es poco ético e ilegal.
    • Otros sostienen que los investigadores mal pagados actúan racionalmente al buscar mercados que sí pagan cuando las empresas no ofrecen programas de recompensas justos.

Vergüenza pública vs colaboración

  • Gran subhilo sobre si la humillación pública es efectiva.
  • Un bando sostiene que avergonzar a las empresas suele ser la única palanca que lleva a cambios reales y que es apropiado para fallos de seguridad groseros (p. ej., contraseñas en texto plano).
  • Otro bando dice que la vergüenza suele conducir a defensividad, encubrimientos e inflación de palabras; los incentivos positivos y el compromiso constructivo son más sostenibles.
  • Varios distinguen entre avergonzar a individuos (a menudo dañino) y avergonzar a corporaciones (visto a veces como regulación necesaria por la vía de la publicidad).

Confianza en sistemas de contratación de terceros

  • Algunos comentaristas dicen que ahora evitan empleadores que subcontratan el reclutamiento a plataformas opacas, especialmente para trabajos mal pagados donde los solicitantes tienen poco margen de negociación.
  • Otros señalan que la mayoría de los solicitantes de trabajos de comida rápida no tienen los medios ni el poder de negociación para exigir prácticas más seguras, por lo que la responsabilidad debe recaer en las empresas y los reguladores.