900 sitios, 125 millones de cuentas, 1 vulnerabilidad

Primer intento

• Un escáner básico escrito en Python revisó variables de configuración de Firebase.
• Dejó de funcionar en menos de una hora debido a problemas de consumo de memoria.

Segundo intento

• El escáner reescrito en Go no tenía fugas de memoria.
• Escanear más de 5 millones de dominios tomó más tiempo de lo esperado.

Verificación manual de todos los dominios

• Se revisó manualmente cada entrada de un archivo de texto de 550 mil líneas.
• Se confirmaron 136 sitios y 6.2 millones de registros expuestos, pero se reconoció la necesidad de un método automatizado.

Catalizador

• Se revisó una lista de sitios potencialmente afectados con un escáner auxiliar llamado Catalizador.
• Se verificó automáticamente el acceso de lectura a colecciones comunes de Firebase en los sitios o en los bundles de .js.
• Se recopilaron muestras de 100 registros para evaluar el impacto de los datos y confirmar los tipos de información.
• Se eligió Supabase (competidor open source de Firebase) para almacenar los resultados.

Cifras

• Registros totales: 124,605,664
• Nombres: 84,221,169
• Correos electrónicos: 106,260,766
• Números de teléfono: 33,559,863
• Contraseñas: 20,185,831
• Información de pago: 27,487,924
• Ten en cuenta que estas cifras podrían ser mayores que las reales.

Lista de sitios afectados

1. Silid LMS

• Sistema de gestión de aprendizaje para estudiantes y docentes.
• La mayor exposición de registros de usuarios, con 27 millones de personas afectadas.

2. Red de apuestas en línea

• Consta de 9 sitios, todos con diseños diferentes.
• Algunos juegos estaban manipulados para tener una probabilidad de ganar de 0%.
• Cuando se intentó reportar el problema, el soporte al cliente trató de tentar al investigador.
• La mayor exposición de información de cuentas bancarias, con 8 millones.
• La mayor exposición de contraseñas en texto plano, con 10 millones.

3. Lead Carrot

• Generador de prospectos en línea para llamadas en frío.
• Uno de los 3 sitios con más información de usuarios expuesta, con 22 millones de personas afectadas.

4. MyChefTool

• App de gestión empresarial y aplicación de punto de venta para restaurantes.
• La mayor exposición de nombres y la segunda mayor de correos electrónicos, con 14 millones y 13 millones respectivamente.

Resultados

• 842 correos enviados durante 13 días.
• 85% de entrega de correos.
• 9% de rebote de correos.
• 24% de los propietarios de sitios corrigieron el error de configuración.
• 1% de los propietarios de sitios respondió.
• 0.2% (2 sitios) ofreció bug bounty.

Opinión de GN⁺

• Este estudio muestra lo fácil que es cometer errores de configuración en la seguridad de Firebase. Es un caso importante para alertar a los desarrolladores sobre la necesidad de prestar atención a la configuración de seguridad.
• También deja ver que las reacciones de los propietarios de los sitios fueron variadas cuando se descubrió el problema de seguridad. La mayoría corrigió el problema, pero algunos lo ignoraron o no ofrecieron una compensación adecuada.
• Las herramientas de automatización usadas para encontrar estas vulnerabilidades de seguridad también pueden ser útiles para otros investigadores de seguridad. Herramientas con funciones similares incluyen OWASP ZAP y Burp Suite.
• Al usar servicios en la nube como Firebase, es importante entender y aplicar correctamente la configuración de seguridad. Una mala configuración puede llevar a filtraciones masivas de datos.
• Este caso también puede ayudar a comparar funciones de seguridad y facilidad de uso al considerar otros servicios, incluida la alternativa open source Supabase. Supabase está basado en PostgreSQL y ofrece funciones similares a Firebase, pero es open source.

[GN⁺]

Opiniones en Hacker News

• Un usuario que trabajó durante mucho tiempo en Firebase mencionó que los problemas relacionados con las reglas de seguridad siempre acosaron al producto. Probaron varios enfoques, pero aun así descubrieron que muchas bases de datos seguían siendo vulnerables en términos de seguridad. Esto se debe a que las reglas de seguridad de Firebase son un concepto nuevo y complejo, y los desarrolladores tienden a no modificar las reglas de seguridad cuando agregan datos nuevos a los datos existentes. Además, como no hay una implementación de backend personalizada, es fácil hacer escaneos masivos, y escribir reglas de seguridad para la base de datos en tiempo real es difícil y escala mal. Sin embargo, como los escaneos automatizados muchas veces solo encuentran datos abiertos, este problema no ocurre tan seguido como podría pensarse. No hay un problema técnico con el enfoque de Firebase en sí, pero como es uno de los pocos backends que se basa en los datos almacenados y en las reglas de seguridad, es propenso a malentendidos, uso inadecuado y a este tipo de problemas.
• Un usuario mencionó que esta situación le recuerda los casos de hackeo a cadenas de comida rápida en Estados Unidos.
• Otro usuario señaló que, según la última parte de este post, el 75% de los sitios con estas vulnerabilidades sigue esperando un volcado de datos, y dijo que eso es una locura. Añadió que a veces piensa que debería requerirse una certificación para trabajar con computadoras.
• Un usuario señaló que elegir lo barato y rápido es una consecuencia inevitable, y mencionó que algunas preocupaciones de clientes/usuarios quedaron fuera de la conversación, mientras que sus datos personales fueron el precio a pagar. Advirtió que conviene tener cuidado con las empresas listadas aquí en las que no ha cambiado el liderazgo, porque una y otra vez se ha demostrado que muchas compañías no se preocupan lo suficiente por proteger a sus clientes.
• Otro usuario planteó una pregunta básica sobre si la mayoría de las apps mencionadas en este post estaban implementadas completamente con JavaScript del lado del cliente hospedado estáticamente, y si el backend era una configuración de Firebase 100% alojada por Google. Si es así, comentó que no se había dado cuenta de qué tan común es esta arquitectura en sitios con millones de usuarios.
• Un usuario hizo la broma: 900 sitios, 125 millones de cuentas, 1 vulnerabilidad y 0 novias.
• Otro usuario expresó que agradece haber elegido hace mucho tiempo un gestor de contraseñas y tarjetas virtuales por situaciones como esta. Comentó que internet se siente cada vez más aterrador, ya que la mayoría de la gente no sabe qué tan vulnerable es la web ni qué tan vulnerables son ellos mismos.
• Un usuario comentó que descubrió que un programa en Python con unas 500 hebras usa cada vez más memoria con el tiempo, y preguntó si había más información o alguna solución para este problema. Mencionó que su propio scraper en Python también tiene cientos de hebras y parece usar mucha memoria.
• Un usuario elogió el buen trabajo y dijo que le gustaría saber cómo llegaron a la conclusión de que el número de usuarios afectados probablemente sería mayor. Sospecha que algunos de los sitios mencionados (apuestas, Lead Carrot) estarán llenos de datos de cuentas falsas.
• Por último, un usuario agradeció porque la atención al cliente le sacó una risa.