Microsoft ha resuelto una grave vulnerabilidad de seguridad en la autenticación de Azure Active Directory (Azure AD). La falla, conocida como”nOAuth”, que fue revelada por el equipo de seguridad de Descope esta semana, podría permitir que los actores malintencionados aumenten sus privilegios e incluso obtengan el control completo de una cuenta específica. Esta configuración incorrecta en la autorización de las aplicaciones OAuth de Azure AD que usan el correo electrónico la reclamación de tokens de acceso podría dar lugar a peligrosos ataques de aumento de privilegios y cuentas. Es crucial que los usuarios tomen medidas inmediatas para garantizar que sus cuentas estén seguras.
Riesgo de apropiación de cuentas
Como explicó el equipo de Descope, la falla radica en la implementación de autenticación de Microsoft Azure AD multi-inquilino de aplicaciones OAuth. Señalaron que un actor malicioso podría manipular el atributo de correo electrónico en”Información de contacto”en la cuenta de Azure AD, y así obtener control sobre el reclamo de”correo electrónico”en el JWT de identidad devuelto. El equipo explicó además que si un atacante crea su inquilino de Azure AD y usa’Iniciar sesión con Microsoft’con una aplicación vulnerable y un usuario’víctima’especialmente diseñado, podría resultar en una apropiación completa de la cuenta.
Descope encontró varias organizaciones grandes vulnerables a esto tipo de ataque, incluida una aplicación de diseño con millones de usuarios mensuales, una empresa de experiencia del cliente que cotiza en bolsa y una multinube proveedor de consultoría. Se notificó a estas organizaciones y se les proporcionó orientación sobre cómo modificar sus aplicaciones.
Cómo funciona Azure Ad OAuth
OAuth es un protocolo de autorización que utiliza Azure Active Directory (Azure AD). Permite a un usuario, que suele ser el propietario del recurso, otorgar acceso limitado a sus recursos protegidos. Este protocolo está diseñado para funcionar específicamente con el Protocolo de transferencia de hipertexto (HTTP) y separa el rol del cliente del propietario del recurso.
El proceso funciona de la siguiente manera:
El cliente solicita acceso a los recursos controlados por el propietario del recurso y alojados por el servidor de recursos. El servidor de recursos emite tokens de acceso con la aprobación del propietario del recurso. El cliente usa los tokens de acceso para acceder a los recursos protegidos alojados por el servidor de recursos.
OAuth 2.0 está directamente relacionado con OpenID Connect (OIDC), una capa de autenticación y autorización construida sobre OAuth 2.0. Sin embargo, es importante tener en cuenta que OIDC no es compatible con versiones anteriores de OAuth 1.0. Azure AD es compatible con todos los flujos de OAuth 2.0.
El procedimiento de ataque nOAuth
Descope proporcionó una explicación detallada del flujo de ataque nOAuth. Explicaron que un atacante podría simplemente cambiar el correo electrónico en su cuenta de administrador de Azure AD a la dirección de correo electrónico de la víctima y usar la función”Iniciar sesión con Microsoft”para obtener autorización en la aplicación o sitio web vulnerable. Descope advirtió que si la aplicación fusiona cuentas de usuario sin validación, el atacante podría obtener control total sobre la cuenta de la víctima, incluso si la víctima no tiene una cuenta de Microsoft.
Respuesta de Microsoft
La explotación de esta falla podría permitir a los actores de amenazas escalar los privilegios y potencialmente tomar el control de la cuenta del objetivo por completo.El equipo de Descope destacó que esta configuración incorrecta podría usarse en ataques de escalada de cuentas y privilegios contra las aplicaciones OAuth de Azure AD que están configuradas para usar el reclamo de correo electrónico. de tokens de acceso para autorización.
En respuesta al descubrimiento, Microsoft tomó medidas para rectificar la falla de autenticación de Azure AD. La empresa reconoció el problema y afirmó que ha desarrollado mitigaciones para el antipatrón inseguro que se usa en las aplicaciones de Azure AD. Descope destacó inicialmente este problema y lo informó a Microsoft. La empresa enfatizó además que el uso del reclamo de correo electrónico de los tokens de acceso para la autorización podría conducir a una escalada de privilegios.
Pasos para mitigar el problema
En respuesta a la configuración de nOAuth, Microsoft ha emitido mitigaciones. La empresa declaró que para proteger a los clientes y las aplicaciones que pueden ser vulnerables a la escalada de privilegios, implementaron mitigaciones para omitir las reclamaciones de tokens de los propietarios de dominios no verificados para la mayoría de las aplicaciones.
Además, Microsoft recomienda encarecidamente a los desarrolladores que evalúen minuciosamente sus la lógica comercial de autorización de las aplicaciones y cumpla con estas pautas para protegerse contra el acceso no autorizado. También alentaron a los desarrolladores a adoptar las mejores prácticas recomendadas para la validación de tokens al utilizar la plataforma de identidad de Microsoft.
