- Una sola regla de seguridad de Firebase mal configurada terminó exponiendo datos de usuarios en cientos de sitios, con una escala confirmada de alrededor de 124.6 millones de registros
- La investigación comenzó buscando variables de configuración de Firebase en sitios web y en bundles de JavaScript cargados; por problemas de memoria del scanner en Python, se reescribió en Go
- El scanner auxiliar Catalyst verifica automáticamente si las colecciones de Firebase son legibles y, a partir de datos de muestra, estima el tipo y la escala de la información expuesta
- Entre los elementos expuestos agregados se incluyen 84,221,169 nombres, 106,266,766 correos electrónicos, 33,559,863 números de teléfono, contraseñas en texto plano 20,185,831 y 27,487,924 datos de pago
- Durante 13 días, los investigadores enviaron 842 correos de reporte, pero solo el 24% de los dueños de sitios corrigió la configuración, el 1% respondió y apenas 2 sitios ofrecieron bug bounty
Escaneo de exposiciones de Firebase a escala de Internet
- Después del caso de intrusión de Chattr.ai, comenzó un escaneo de todo Internet para encontrar PII expuesta mediante instancias de Firebase mal configuradas
- El primer scanner en Python revisaba variables de configuración de Firebase en sitios web o en bundles
.jscargados, pero al operar con unos 500 threads aumentó el uso de memoria y produjo un OOM en menos de 1 hora - Luego, el scanner reescrito en Go se ejecutó sobre 5.5 millones de dominios y tardó 2 a 3 semanas, más que los aproximadamente 11 días previstos al inicio
- Solo con la revisión manual inicial se encontraron 136 sitios y 6.2 millones de registros, pero al crecer tanto la lista de candidatos se volvió necesaria la automatización completa
Catalyst y estimación de la escala de exposición
- Catalyst recibe como entrada sitios candidatos o bundles de JavaScript, y verifica automáticamente si hay acceso de lectura a colecciones comunes de Firebase y a colecciones mencionadas directamente en JavaScript
- Cuando encuentra una colección legible, recopila una muestra de 100 registros para identificar los tipos de información incluidos y multiplica eso por el tamaño total de la colección para estimar el impacto
- Como repositorio de resultados se eligió Supabase, un competidor open source de Firebase basado en PostgreSQL, y los datos depurados se subieron a tablas privadas de base de datos
- Las cifras agregadas son las siguientes, aunque sigue siendo posible que la escala real de exposición sea mayor que la indicada
- Registros totales: 124,605,664
- Nombres: 84,221,169
- Correos electrónicos: 106,266,766
- Números de teléfono: 33,559,863
- Contraseñas: 20,185,831
- Información de pago: información bancaria, facturas, etc., 27,487,924
Sitios con mayor impacto
-
Silid LMS
- Sistema de gestión de aprendizaje para estudiantes y docentes
- Se expusieron 27 millones de registros de usuarios, incluyendo nombres, correos electrónicos y números de teléfono, lo que lo convirtió en el caso de mayor escala
-
Red de apuestas en línea
- Está compuesta por 9 sitios que son reskins entre sí
- Algunos giros estaban manipulados para que la probabilidad de ganar fuera de 0%
- Fue el caso con más exposición de datos de inicio de sesión detallados de cuentas bancarias, con 8 millones
- También fue el de mayor escala entre los sitios afectados en contraseñas en texto plano, con 10 millones
- Durante el proceso de intentar reportar el problema, soporte al cliente coqueteó durante la conversación
-
Lead Carrot
- Servicio en línea de generación de leads para cold calling
- Ocupa el top 3 en volumen de información de usuarios expuesta, con impacto en 22 millones de personas
-
MyChefTool
- App de gestión de negocios y aplicación POS para restaurantes
- Ocupó el primer lugar en cantidad de nombres expuestos y el segundo en correos electrónicos, con 14 millones y 13 millones, respectivamente
Respuestas después del reporte
- Los investigadores enviaron 842 correos durante 13 días
- 85% fueron entregados y 9% rebotaron
- 24% de los dueños de sitios corrigió la configuración errónea
- Solo 1% de los dueños de sitios respondió
- 2 dueños de sitios, equivalentes al 0.2%, ofrecieron bug bounty
1 comentarios
Opiniones de Hacker News
Trabajé mucho tiempo en Firebase, y los problemas con las reglas de seguridad han seguido afectando al producto.
Probamos varios enfoques, como reglas predeterminadas que vencen automáticamente y más capacitación, pero al final seguimos viendo muchas bases de datos inseguras.
Las razones son complejas: las reglas de seguridad al estilo Firebase todavía son un concepto poco familiar, y muchas veces un desarrollador nuevo que agrega datos en una ubicación existente no modifica también las reglas para ajustarlas a los cambios en los requisitos de privacidad de esos datos.
Además, desaparece la “seguridad por oscuridad” que ofrecía un backend propio de cada quien, lo que facilita los escaneos a gran escala.
En especial, las reglas de Realtime Database son difíciles de escribir y no escalan bien, pero los escaneos automáticos normalmente solo buscan datos abiertos, así que bastaba con estar apenas un poco mejor que
read write truepara bloquearlos.Técnicamente, el enfoque de Firebase en sí no es incorrecto, pero como es prácticamente el único backend que usa un modelo centrado en los datos almacenados y las reglas de seguridad, es fácil que quede expuesto a malentendidos, usos incorrectos y accidentes como este.
En un backend, la validación y las reglas de seguridad se ven como parte de la especificación, pero las reglas de seguridad de Firebase son un proceso aparte, por lo que se olvidan fácilmente y hay que volver a evaluarlas cada vez que se crea una nueva función.
Parece que habría sido necesario escalar bastante alto dentro de Firebase para llamar la atención de alguien que pudiera notificar a los propietarios de los proyectos.
Por ejemplo, me pregunto si plantillas como “solo el propietario del contenido puede acceder” o “acceso basado en atributos/roles” del artículo podrían cubrir los patrones de la mayoría de las apps, o si de verdad se necesitan muchas reglas personalizadas.
Un gran problema al escribir reglas de seguridad es que casi cualquier error se convierte en un problema de seguridad, así que si no es necesario, uno preferiría no tocarlas.
Si las reglas están demasiado cerradas, la app no funciona y se nota de inmediato; pero si están demasiado abiertas, no queda tan claro hasta que alguien pruebe explícitamente accesos excesivos.
Relacionado con esto, también valdría la pena considerar obligar a los desarrolladores a escribir casos de prueba de ejemplo de acceso denegado para cada regla de seguridad.
fireplanagrega por defecto la regla"$other": {".read": false, ".write": false}a todas las propiedades.Gracias a eso, los campos nuevos deben agregarse explícitamente, por lo que es casi imposible que un valor nuevo “herede” reglas existentes sin que uno se dé cuenta.
Llevo más de 10 años usando Firebase, así que no sé si las herramientas modernas de reglas ya hacen esto.
Lo que realmente ayudaría sería soporte predeterminado para cambiar nombres de campos o modificar estructuras de datos cuando hay varias versiones de clientes difíciles de controlar, una forma liviana de probar reglas sin levantar una base de datos, y mejor información de depuración cuando una regla falla en producción.
Cada vez que falle, deberían registrarse todos los valores a los que accedió la regla, para poder depurar fallas transitorias causadas por datos cambiantes.
Este es un modelo conceptual que no se explica lo suficiente.
En los proyectos, decimos que cada colección debería tener un perfil de seguridad —pública, datos de usuario, pública solo para usuarios autenticados, solo administradores— y abordamos el tema haciendo que estas categorías se impongan mediante funciones de reglas de seguridad, en vez de escribir condiciones personalizadas para cada colección.
Pensar la seguridad a nivel de colección, y no de campo, reduce la mezcla de intenciones de seguridad distintas dentro de un mismo documento.
Si una colección es pública, no debería contener campos que no sean públicos; si hace falta, se pueden duplicar datos desde un contexto sensible hacia uno público con triggers de Firestore, pero no en la dirección contraria.
El problema es que hay que documentar la intención de las reglas fuera de las reglas mismas, por lo que es fácil aplicarlas mal; antes escribir pruebas también era doloroso, aunque ahora ha mejorado mucho.
Me recuerda a “How I pwned half of America’s fast food chains, simultaneously.”: https://mrbruh.com/chattr/
HN: https://news.ycombinator.com/item?id=38933999
After the initial buzz of [pwning Chattr.ai] had settled down, […]Si no estoy viendo mal, ¿eso significa que, al final del artículo, el 75% de los sitios con esta vulnerabilidad siguen abiertos y se pueden dumpear?
Es una locura.
Hay días en los que pienso que debería hacer falta una licencia para tocar una computadora.
Externalizan el sitio web con una agencia, y la agencia va cambiando desarrolladores: al principio pone a uno bueno y luego, mientras la empresa no se queje, deja el contrato en manos de alguien menos experimentado.
Es muy probable que el correo sobre la vulnerabilidad se haya ignorado como spam, se haya reenviado y quedado abandonado, o haya terminado en la cola de reuniones de un PM como algo que intentarán arreglar cobrándole lo máximo posible al cliente.
Incluso en campos donde se exige licencia profesional hay muchos licenciados incompetentes.
Los médicos también tienen requisitos enormes de formación y licencia, pero no faltan médicos charlatanes ni practicantes licenciados de medicina alternativa.
Hice lo mejor posible enviando correos personalizados a cada sitio con qué estaba afectado, cómo corregirlo y cómo ponerse en contacto.
Esta es la consecuencia inevitable de haber elegido la opción barata y rápida en el triángulo barato-rápido-bueno de un PM
Lamentablemente, las preocupaciones de algunos clientes y usuarios quedaron fuera de la discusión, y sus datos personales terminaron siendo el costo
Tendría cuidado con cualquiera de las empresas listadas aquí que haya tomado una decisión así y aun así no haya cambiado su liderazgo
Ya se ha demostrado muchas veces que a muchas empresas no les importa lo suficiente proteger a sus clientes, y la historia se repite
Tengo una pregunta muy básica sobre Firebase: ¿la mayoría de las apps de este artículo fueron implementadas solo con JavaScript del lado del cliente alojado estáticamente, sin código de servidor personalizado?
Me pregunto si eso significa que el backend es una configuración de Firebase hospedada 100% por Google
Si es así, no sabía que una arquitectura así se había vuelto tan común en sitios con millones de usuarios
Si pones un modelo de seguridad de permitir por defecto en la API, inevitablemente termina pasando esto
Lamentablemente, en las bibliotecas dirigidas a desarrolladores JavaScript son comunes los valores predeterminados inseguros, y GraphQL también parece un área donde podría aparecer este tipo de problema
Firebase también tiene Firebase Functions, funciones invocables en la nube, y ese código no es público
Pero tanto Firestore como Firebase Realtime Database requieren que el usuario configure reglas de seguridad; si no, cualquiera puede leer todos los datos
Lo importante es hacer que sea fácil escribir reglas de autorización adecuadas en el backend
Ver cosas así me hace sentir afortunado de haber elegido hace mucho un administrador de contraseñas y tarjetas virtuales
Aun así, internet se vuelve cada vez más aterrador
La mayoría no tiene ni idea de lo frágil que es la web ni de lo expuestos que están
Como los agentes de IA serán mucho más eficientes que los bots para encontrar vulnerabilidades, siento que nos espera un futuro extraño
Hay que usar una dirección de correo única para cada servicio en el que te registras
Eso limita el daño cuando ocurre un incidente y también evita que te hagan recolección de información pública cruzándola con otros servicios
A veces, si llegan correos maliciosos a esa dirección única, incluso puedes darte cuenta de la intrusión antes que el operador del sitio
¿Alguien sabe más sobre la parte de que “un programa Python con unos 500 hilos empieza a consumir memoria con el tiempo”?
Yo también tengo un scraper en Python con cientos de hilos y parece consumir mucha memoria
Me pregunto si hay alguna solución alternativa o si la única salida es reescribirlo en otro lenguaje
Personalmente prefiero procesos antes que hilos, y uso pools de workers y un bus de mensajes en lugar de memoria compartida
Esa solución también tiene desventajas y algo de sobrecarga, pero te permite preocuparte mucho menos por los problemas de memoria
Para un crawler, como la cantidad de procesos es relativamente constante y el trabajo de cada proceso es independiente, el modelo de procesos parece encajar mejor
import multiprocessing as threadingReescribirlo es prácticamente la única solución realista
Es un caso de uso que le queda muy bien
Buen trabajo
Me da curiosidad cómo llegaron a la conclusión de que la cantidad de usuarios afectados probablemente sea mayor en realidad
A simple vista, parece que algunos sitios, como los de apuestas o Lead Carrot, podrían tener muchos datos de cuentas falsas mezclados
Es un método que solo funciona bien en sitios en inglés
La razón para decir que eran más es que otros servicios que no estaban en la lista escaneada también podrían ser vulnerables