Se ha detectado un fallo en un sistema personalizado de cookies de sesión que permitía a atacantes no autenticados suplantar la identidad de empleados y administradores en una plataforma de gestión de patios. Es importante destacar que el problema no radicaba en Microsoft Entra ID, sino en una capa de sesión débil de la aplicación que aceptaba identidades falsificadas tras evadir los controles normales de inicio de sesión.

Un fallo en un sistema personalizado de cookies de sesión permitió que un atacante no autenticado se hiciera pasar por empleados y administradores en una plataforma de gestión de patios.

El problema no rompió Microsoft Entra ID en sí mismo. En su lugar, permitió que una capa de sesión débil en el lado de la aplicación aceptara una identidad falsificada después de que los controles normales de inicio de sesión hubieran sido eludidos.

La plataforma afectada utilizaba el inicio de sesión único (SSO) y la autenticación multifactor de Entra ID, pero también dependía de una cookie firmada para mantener las sesiones de la aplicación.

Ese diseño creó el mismo riesgo visto en los ataques de toma de control de cuentas basados en cookies, donde el control de una sesión confiable puede ser más importante que una contraseña.

Resecurity señaló en un informe que su evaluación autorizada descubrió la debilidad mientras revisaban un sistema de gestión de patios de la cadena de suministro.

Los investigadores afirmaron que no se probaron sistemas de producción, se restauraron los registros de prueba y las identidades referenciadas en la prueba de concepto fueron anonimizadas.

Los investigadores lograron suplantar 95 cuentas de empleados de 241 IDs de usuario probados, incluyendo cuentas con derechos elevados. Una sesión de administrador falsificada fue capaz de realizar una solicitud de API que cambiaba el estado, lo que significa que el fallo podría exponer datos operativos y permitir que un intruso actúe bajo la identidad de un empleado legítimo.

Vulnerabilidad de la Cookie de Sesión

La elusión provino de dos errores de diseño vinculados. La aplicación firmaba una cookie con un secreto hard-coded (codificado rígidamente) que coincidía con el nombre de la cookie, mientras que el valor firmado era el identificador de la base de datos del usuario, expuesto públicamente. Ninguno de los dos valores debería haber sido suficiente para establecer una sesión autenticada.

Normalmente, una cookie firmada detecta cambios aplicando un secreto criptográfico mantenido por el servidor a una referencia de sesión aleatoria. En este caso, el CUID objetivo podía obtenerse de las respuestas de la API, incluyendo el endpoint del usuario autenticado y las respuestas del directorio.

Con un secreto predecible, un atacante podía crear una cookie que el servidor trataba como si perteneciera a otro usuario. Esa distinción es importante porque la solicitud resultante nunca necesitó la contraseña de la víctima, una aprobación de MFA reciente o un token de acceso de Entra ID.

Fue un fallo en el modelo de confianza de la aplicación, no una prueba de que la criptografía de Entra ID estuviera comprometida. Informes recientes sobre el robo de tokens de refresco de Entra muestran similarmente por qué las defensas de identidad deben proteger los artefactos emitidos después del inicio de sesión.

Los controles más amplios de la plataforma parecían sólidos durante las pruebas: utilizaba tokens de acceso firmados con RS256, validación de esquemas y acceso a la base de datos parametrizado.

Sin embargo, la cookie de sesión separada se convirtió en una ruta alternativa hacia la aplicación. Los investigadores también encontraron una interfaz Swagger no autenticada que exponía la superficie completa de la API de 251 rutas, lo que dio una visibilidad adicional a la evaluación.

Conteniendo el Riesgo de la Capa de Sesión

La prioridad es rotar el secreto de firma de sesión comprometido e invalidar las sesiones existentes. Esto corta las cookies producidas con esa clave.

Luego, los equipos deben revisar los registros de autenticación y de la aplicación en busca de creaciones de sesión inusuales, cambios de cuenta, acciones administrativas o actividad que no coincida con el usuario o dispositivo esperado.

Los desarrolladores deben reemplazar los valores de sesión controlados por el cliente que contienen identidad por identificadores de sesión generados aleatoriamente, almacenados y verificados en el servidor.

Se deben mantener secretos separados y de alta entropía de forma segura para desarrollo, staging y producción, sin reutilizarlos nunca entre entornos. Un flag de cookie segura por sí solo no puede proteger un diseño de sesión que confía en un valor predecible.

Las organizaciones también deberían evaluar cada capa personalizada añadida alrededor de un proveedor de identidad en la nube. Un SSO y MFA fuertes en el upstream no pueden compensar cuando una aplicación acepta una credencial separada como prueba decisiva de identidad.

Puedes aplicar las lecciones de la técnica de secuestro de sesión Cookie-Bite, incluyendo el monitoreo de inicios de sesión sospechosos, la restricción de extensiones de navegador no aprobadas, la aplicación de acceso mediante dispositivos conformes y la aplicación de protecciones de tokens.

Si los tokens sin estado siguen siendo necesarios, Resecurity recomienda claves criptográficas fuertes, límites de expiración y protecciones contra la repetición. Los equipos deben asegurarse de que la revocación de la sesión cubra cada host que acepte la cookie.

En este caso, la misma cookie falsificada funcionó tanto en la API como en los hosts de la aplicación administrativa. Informes sobre el robo de sesiones de Microsoft 365 han subrayado igualmente que los restablecimientos de contraseña por sí solos pueden no terminar las sesiones autenticadas.

Este caso es un recordatorio de que el MFA verifica un evento de inicio de sesión, mientras que la gestión de la sesión decide qué sucede después. Una referencia de sesión aleatoria en el lado del servidor, secretos rotados y un monitoreo significativo reducen la probabilidad de que un atacante pueda convertir un identificador expuesto en una suplantación de cuenta.

Fuentes:
https://cybersecuritynews.com/session-cookie-vulnerability/