Escalada de privilegios en Entra ID (anteriormente Azure AD)

Los ataques de escalada de privilegios son uno de los problemas más urgentes para los equipos de seguridad de todo el mundo y se utilizan habitualmente como parte de movimiento lateral. Los actores de amenazas saben que las cuentas privilegiadas son más difíciles de comprometer porque normalmente están monitoreadas y protegidas. Sin embargo, los atacantes pueden emplear vulnerabilidades de escalada de privilegios para tomar el control de cuentas menos monitoreadas y posteriormente darse un alto nivel de acceso, todo ello mientras permanecen fuera del radar del equipo de seguridad.

En el entorno híbrido actual, las empresas están trasladando cada vez más sus recursos sensibles a aplicaciones SaaS. Azur Active Directory es uno de los principales proveedores de identidades en la nube que permite a las empresas gestionar de forma centralizada el acceso y el uso de dichas aplicaciones.

Recientemente hemos descubierto un problema de escalada de privilegios dentro Entra ID (antes Azure AD) que podría permitir a un atacante eludir una protección de restablecimiento de contraseña, permitiendo a los administradores de nivel inferior convertirse en administradores con plenos privilegios. Informamos este problema al Centro de respuesta de seguridad de Microsoft (MSRC), que lo validó y aplicó una solución. Si bien ya no representa un riesgo para Entra ID (anteriormente Azure AD), creemos que la comunidad de seguridad en general puede beneficiarse al ver nuestros análisis y hallazgos.

Análisis técnico

La Entra ID (anteriormente Azure AD) el sistema de roles privilegiados funciona como una jerarquía, lo que impide que los administradores con privilegios más bajos restablezcan la contraseña de los administradores con privilegios más altos. Además de la lógica operativa, esto también protege contra un escenario en el que una cuenta de administrador con privilegios más bajos se ve comprometida al garantizar que el atacante no pueda modificar aquellas con privilegios más altos.

Esta protección se aplica cuando el rol del usuario está configurado como "elegible" o "activo". Sin embargo, Entra ID (anteriormente Azure AD) también permite cuentas de usuario ser asignado para un uso futuro; es decir, los privilegios de nivel superior se otorgan en una fecha y hora predefinidas.

Descubrimos que en este caso, la protección de contraseña no se aplica. Esto expone Entra ID (anteriormente Azure AD) al siguiente escenario:

1. Compromiso inicial: un atacante compromete una cuenta de administrador con privilegios bajos.
2. Descubrimiento de asignaciones de roles futuras: El atacante escanea Entra ID (anteriormente Azure AD) para buscar cuentas programadas para convertirse en administradores con privilegios elevados en el futuro.
3. De restablecimiento de contraseña: El atacante ahora restablece la contraseña de estas cuentas, comprometiéndolas antes de que se realice la asignación de roles. Lo ideal sería que el atacante realizara este reinicio lo más cerca posible del momento del cambio de rol.
4. Escalada de privilegios: Se produce el cambio de rol, lo que proporciona al atacante control total sobre una cuenta de administrador activa con privilegios elevados.

Repasemos estas etapas una por una:

Compromiso inicial

A los efectos de este análisis, supongamos que esto ya ha ocurrido. El atacante ha comprometido la cuenta de "Shay Katz", que tiene una asignación activa de "Administrador del servicio de asistencia".

Captura de pantalla 1: Pantalla de roles asignados de Shay Katz

La siguiente tabla, tomada de Entra IDLa página web de roles integrada de (anteriormente Azure AD) muestra los derechos de restablecimiento de contraseña de varios roles dentro Entra ID (anteriormente Azure AD). Podemos ver que el “Administrador del servicio de asistencia” no puede restablecer las contraseñas de los roles “Administrador de autenticación” y “Administrador de contraseñas”.

Captura de pantalla 2: Entra ID (anteriormente Azure AD) tabla de permisos de restablecimiento de contraseña

El atacante ahora ha iniciado sesión en Entra ID (anteriormente Azure AD) como el usuario "Shay Katz".

Descubrimiento de asignación de roles futuros

Antes de la solución de Microsoft, había dos opciones para descubrir futuras asignaciones de administrador por menos usuarios privilegiados:

1. A través de esta formación, el personal docente y administrativo de escuelas y universidades estará preparado para manejar los recursos disponibles que derivan de la diversidad cultural de sus estudiantes. Además, un mejor y mayor entendimiento sobre estas diferencias y similitudes culturales permitirá alcanzar los objetivos de inclusión previstos. Entra ID (anteriormente Azure AD), consultando la página "solicitud pendiente" para una futura asignación de roles de un administrador de nivel superior.
2. A través de un script, utilizando Resource Graph.

a) Permisos requeridos:

Enumerar las solicitudes de elegibilidad de roles programadas: Requiere: ReadWrite.AzureAD

Una lista con:

1. DeviceManagementApps.Read.All
2. DeviceManagementApps.ReadWrite.All
3. Directorio.Leer.todos
4. Directorio.ReadWrite.All
5. Usuario.Leer.todo
6. Usuario.ReadBasic.All
7. Usuario.LeerEscribir.Todo

b) Ejecute la consulta "https://graph.microsoft.com/beta/roleManagement/directory/roleEligibilityScheduleRequests" para obtener la solicitud programada.
Filtrar por estado = 'aprovisionado' Y agendaInfo['startDateTime'] > horaactual Y rolDefiniciónId en protectedRoleIdList.

c) Ejecute la consulta “https://graph.microsoft.com/beta/users?$select=displayName,id” para obtener el nombre para mostrar del usuario usando la clave principalId.

Usando el Entra ID (anteriormente Azure AD) (opción A), el atacante descubre una cuenta de prueba de muestra que actualmente no tiene asignaciones de roles "Activo" o "Elegible".

Captura de pantalla 3: Cuenta de "prueba" sin asignaciones "elegibles" o "activas"

Sin embargo, los campos "Hora de solicitud" y "Hora de inicio" nos muestran que esta cuenta de prueba tiene una solicitud pendiente para ser agregada como Administrador Global en el futuro.

Captura de pantalla 4: Solicitud pendiente para que la cuenta de prueba se convierta en Administrador Global

El atacante ahora ha encontrado un objetivo digno: una cuenta con pocos privilegios con una futura asignación de funciones. Ahora podemos pasar a la siguiente etapa.

Restablecimiento de contraseña

El atacante ahora puede restablecer la contraseña de la cuenta de prueba usando el Entra ID (anteriormente Azure AD):

Captura de pantalla 5: Restablecimiento de contraseña para la cuenta de prueba

Escalada de privilegios

Misión cumplida. Cuando llegue la hora de inicio definida, la cuenta de prueba se actualizará a una cuenta de Administrador global y el atacante tendrá control total.

La solución de Microsoft

Microsoft ha solucionado el problema implementando los siguientes controles:

• Un administrador con pocos privilegios ya no puede ver las solicitudes pendientes en el portal.
• Si intenta restablecer la contraseña para una futura asignación de roles privilegiados, recibirá un error. (Por lo general, si no se le permite restablecer una contraseña, el botón de restablecer contraseña está bloqueado).

Conclusión

Como se indicó, Microsoft ha solucionado este problema, por lo que esta técnica de ataque ya no es efectiva. Sin embargo, cabe señalar que se sabe que este tipo de problemas dentro de las salvaguardas de acceso Just-in-Time atraen a los atacantes. En este caso, hubo una brecha entre la asignación de privilegios y la habilitación real de una medida de seguridad creada para protegerlo. A medida que las empresas se orientan más hacia la nube, aumenta el deseo de los actores de amenazas de buscar tales debilidades en la infraestructura de gestión de SaaS. Nos complace haber tenido esta oportunidad de mitigar una exposición en el superficie de ataque y deseamos agradecer nuestro agradecimiento a Microsoft por su respuesta rápida y eficiente.