⚡ Tecnología
16 años, un token vacío y 17 billones de registros de Microsoft al descubierto
Un chaval de 16 años se pasó una noche probando un servicio interno de Microsoft que nadie debería ver. A las 2 de la mañana del 5 de septiembre, su consulta SQL le devolvió «17 billones». No había hackeado una base de datos: había meses de trabajo previo, un bot de IA y, sobre todo, un token que no tenía firma ninguna.
La historia la acaba de publicar el propio investigador, un chico que se hace llamar Faav, y en 72 horas la han recogido Tom's Hardware, Help Net Security, iTnews y The Economic Times. El número es tan absurdo que parece un error de tecleo. No lo es.
¿Qué estaba mirando exactamente?
El servicio se llama Titan: una plataforma interna de analíticas sobre Apache Superset, protegida por una VPN y una página de "VPN REQUIRED" para empleados de Microsoft. Su API pública estaba en un host de Azure Cloud Services, y su fichero Swagger listaba cuatro rutas.
Tres exigían autenticación Azure AD. La cuarta, la que aceptaba SQL crudo, no. Y en esa puerta trasera Faav estuvo trabajando diez días.
El fallo: nadie miraba la foto del carné
Aquí está el corazón del asunto. Titan validaba el contenido del token (tenant, audience, ID de aplicación, usuario) pero nunca verificaba la firma, que es justamente la parte que demuestra quién lo emitió.
La metáfora que usa Faav es perfecta: "los controles de acceso se sentían como un hotel donde cada puerta tiene un lector de tarjetas funcionando, pero cualquier tarjeta abre cualquier habitación".
El momento decisivo llegó cuando sustituyó el token entero por uno sintético cuya tercera sección —la firma— quedaba vacía. Titan lo aceptó sin pestañear.
El error que lo destapó: un campo mal nombrado
Su bot de IA, Antares, llevaba días probando identidades con formato de [email protected] y ninguna funcionaba. La IA no lo resolvió: se quedó en un bucle. Lo que lo rompió fue la intuición humana, a la 1 de la madrugada.
Faav se preguntó qué estaría haciendo el backend con ese campo. La respuesta: no buscaba un UPN, buscaba un "login". Cambió la identidad por un valor que no se parece en nada a un correo válido y, de pronto, resolvió al usuario ID 1, con el rol de administrador.
El SQL corrió. Titan ejecutó la consulta.
17 billones: cómo salió la cuenta
Aquí no hay un gran total cómodo, sino una suma reconstruida con cuidado. De los 56 valores de enrutamiento de la configuración archivada de Superset, 30 seguían activos. Apuntaban a 24 configuraciones y, en último lugar, a 17 bases de datos de analíticas con 9.863 tablas únicas.
Faav sumó los metadatos por dos rutas independientes y le salió el mismo número. Eran las 2 de la mañana. "Mi primer instinto fue que estaba contando las réplicas dos veces", escribió. Las contó dos veces. No se había equivocado.
El propio investigador es honesto: es una estimación de almacenamiento que probablemente incluye datos históricos, duplicados y derivados. Aun así, la cifra es brutal.
Qué había dentro de verdad
Lo que el investigador llegó a tocar de forma concreta fue esto:
- 25.000 cuentas de usuario activas con nombres, correos e historial de login
- 15.001 registros de organización de empleados
- 20.979 definiciones SQL de conjuntos de datos virtuales
- 24.569 dashboards, 425.891 gráficos y 27.347 definiciones de datasets
- Directorio de personal: puestos, departamentos y jerarquía de los empleados asociados a Titan
- Analíticas de Bing, desde donde se podía leer actividad de búsqueda con identificadores MUID
El campo de password de esas cuentas contenía un hash de relleno del modelo local de Superset, no una credencial real de Microsoft. Eso es lo único que lo salvó de ser unafiltración completa de credenciales.
La parte incómoda: el lado humano
Aquí hay una lectura que las cabeceras no van a developing: el directorio de empleados con puestos, departamentos y jerarquía es material puro para ingeniería social. Sabes a quién reportan, sabes quiénes tienen autoridad, sabes a quién llamar. Faav admite que nunca lo probó — pero no lo probó porque iba a crédito que no lo había hecho, no porque fuera imposible.
Y luego está Bing. Los MUID aparecían en más de un conjunto de datos. Correlacionar actividad entre servicios no era una teoría: era trabajo de unas horas.
Mi opinión: el dato de Bing es el que debería quitarle el sueño a Microsoft. 25.000 cuentas, está claro, es ruido administrativo. Cruzar búsquedas de usuarios con tu perfil corporativo es otra categoría.
La respuesta de Microsoft y el epílogo
Microsoft confirmó que "el hallazgo reportado y la divulgación coordinada nos ayudaron a proteger mejor a nuestros clientes reforzando nuestros servicios", y que valora la investigación segura bajo los términos del Bug Bounty Program. La empresa tuvo control editorial sobre la publicación.
La cronología es igual de reveladora: el 5 de septiembre confirmó el acceso y reportó; el 6 y el 7 MSRC le pidió parar de probar y solicitó su IP; el 9 de septiembre, cuatro días después, el endpoint quedó bloqueado. Caso 144051 abierto el mismo día del reporte. Rápido, pero rápido porque alguien lo miró.
Qué te llevas de esto
Tres cosas, y ninguna requiere ser un atacante:
1. La firma del token no es un trámite. Es todo. Validar el payload sin verificar la firma es como leer el carné sin mirar la foto.
2. Un campo mal nombrado es una vulnerabilidad. Aquí el bug vivía en un backend que usaba "login" donde decía "upn". La IA no lo encontró; un humano a la 1 AM, sí.
3. El hallazgo no fue un 0day secreto. Fue un Swagger público y una Wayback Machine con la configuración de 2023. Tu propia configuración archivada puede ser el mapa del atacante.
Y un apunte final que da frío: Faav tenía 15 años cuando escribió su primer informe para Microsoft. Este es su segundo. Si estás empezando en seguridad, la lección real no es "usa IA": es que la IA te da la persistencia de diez días, pero el golpe de gracia sigue siendo tuyo.
¿Crees que un token sin firma debería haberlo pillado el análisis estático de código, o que esto es solo un fallo de implementación que el code review tiene que atrapar?
Comparte esto con el dev que despliega su API "solo para internos" sin revisar nunca cómo valida los tokens.