En su charla de TROOPERS19 ("I'm in your cloud ... reading everyone's email"), Dirk-jan Mollema habló de un problema que descubrió que permitía el uso de SMTP matching (también llamado soft matching) para sincronizar usuarios de Active Directory (AD) con Azure AD, con el objetivo de secuestrar cuentas no sincronizadas. Jan declaró que Microsoft bloqueó la capacidad de sincronizar cuentas on-prem que tenían asignaciones activas a roles administrativos dentro de Azure AD.
Hemos investigado esta declaración. Malas noticias: Nuestra investigación muestra que cualquier persona con privilegios de creación de cuentas en un entorno AD puede modificar la contraseña de un usuario de Azure AD y -con unos pocos requisitos previos- obtener acceso privilegiado a través de asignaciones de roles elegibles.
¿Qué conduce a esta vulnerabilidad de Azure AD?
La mayoría de las organizaciones utilizan Active Directory para gestionar los permisos y el acceso a los recursos de red. Muchas de estas organizaciones también están empezando a utilizar Azure AD, un servicio de gestión de identidades y accesos basado en la nube, para gestionar las identidades de los usuarios y los privilegios de acceso a recursos como el portal de Azure y Office 365.
En las implementaciones de identidad híbrida, los objetos se sincronizan entre los entornos de AD locales y los inquilinos de Azure AD. En estos entornos, los usuarios pueden utilizar la misma identidad para AD local y Azure AD.
Azure AD Connect
Azure AD Connect es una aplicación de Microsoft diseñada para conseguir una identidad híbrida sincronizando objetos AD on-prem con objetos Azure AD. Azure AD Connect incluye muchas funciones, las más importantes de las cuales son la sincronización de hash de contraseñas, la autenticación PassThrough, la integración de la federación (con ADFS) y la sincronización (con Azure AD Connect Sync). La sincronización hash de contraseñas y la sincronización general son las más relevantes para este debate.
Durante una instalación de Azure AD Connect Express, se crean nuevas cuentas para admitir la sincronización.
- Cuenta del conector AD DS:
- Se utiliza para leer y escribir en AD
- Concedidos los permisos Replicar cambios de directorio y Replicar cambios de directorio todos para el uso de la Sincronización de hash de contraseñas.
- Con el prefijo MSOL_########
- Cuenta del servicio ADSync: Se utiliza para la sincronización y para acceder a la base de datos SQL
- Cuenta de Azure AD Connector:
- Se utiliza para escribir información en Azure AD
- Concedido el rol especial Cuentas de sincronización de director ios, que sólo tiene permisos para realizar tareas de sincronización de directorios.
- Prefijado con Sync_*
En una implementación de identidad híbrida, la integridad entre los entornos on-prem y los inquilinos de Azure AD es importante. Para lograr este objetivo, Azure AD Connect hace coincidir los objetos de usuario entre Azure AD y AD.
Durante la configuración y sincronización iniciales de Azure AD Connect, se elige un atributo de anclaje de origen. Este atributo identifica de forma exclusiva un objeto de usuario entre AD y Azure AD. Azure AD Connect realiza la coincidencia consultando este atributo y hace coincidir los objetos de usuario entre Azure AD y AD mediante una de estas dos técnicas:
- Emparejamiento duro
- Ajuste suave (SMTP)
Emparejamiento duro
Si permite que Azure gestione el anclaje de origen, Azure AD Connect busca uno de los dos atributos sourceAnchor posibles:
- Azure AD Connect versión 1.1.486.0 y anteriores utilizan objectGUID.
- Azure AD Connect versión 1.1.524.0 y posteriores utilizan mS-DS-ConsistencyGuid.
Cuando el atributo mS-DS-ConsistencyGuid está vacío, Azure AD Connect escribe el objectGUID del usuario en ese atributo. ImmutableID es el valor correspondiente en el objeto de Azure AD, es decir, el objectGUID codificado en base64. La figura 1 muestra un ejemplo de obtención del ImmutableID de un objeto de Azure AD a partir del objectGUID del usuario de on-prem AD.
Ajuste suave (SMTP)
La concordancia suave (SMTP) utiliza dos atributos que existen tanto en AD como en Azure AD:
- userPrincipalName
- proxyAddress
La concordancia suave tiene éxito cuando coinciden objetos de usuario, siempre que se den dos condiciones:
- El atributo userPrincipalName de Azure AD coincide con el de AD.
- El atributo proxyAddress primario en AD coincide con el proxyAddress en Azure AD.
Cuando una coincidencia dura o blanda tiene éxito, se actualiza el objeto de usuario coincidente. Si no existe ninguna coincidencia, se crea un objeto de usuario en el inquilino de Azure AD para que coincida con el objeto de usuario de AD local, utilizando los atributos de la cuenta.
Sincronización del hash de la contraseña
La sincronización del hash de la contraseña es un método de autenticación que se implementa en los entornos de identidad híbrida de Azure AD. Este método, que está activado de forma predeterminada, sincroniza el hash de la contraseña de AD local del usuario con Azure AD cada dos minutos. La sincronización del hash de la contraseña permite a los usuarios utilizar la misma contraseña para iniciar sesión tanto en AD como en Azure AD. (Para obtener una explicación más detallada de la sincronización del hash de la contraseña, consulte Semperis - Understanding Azure AD Password Hash Sync).
Funciones activas frente a funciones admisibles
A los usuarios de Azure AD se les pueden asignar roles que otorgan permisos para gestionar diversos recursos de Azure AD. Los roles pueden ser asignaciones activas o elegibles.
Las asignaciones elegibles requieren que el usuario active el rol. Para ello, el usuario debe realizar una acción MFA, proporcionar una justificación empresarial o solicitar la aprobación de los aprobadores designados. Los roles elegibles pueden asignarse de forma permanente o por un periodo específico(Figura 2). No hay límite de tiempo para la activación de un rol elegible asignado permanentemente.
Las asignaciones activas no requieren ninguna acción del usuario para el uso del rol. Los usuarios tienen los privilegios asociados a un rol mientras permanezcan asignados a ese rol(Figura 3).
Cómo la coincidencia SMTP se convierte en una vulnerabilidad de Azure AD
Un objeto de Azure AD puede gestionarse en Azure AD o en AD local. Cada objeto tiene un indicador que muestra si la cuenta se ha sincronizado con una cuenta local. El siguiente ejemplo muestra este indicador en el panel Usuarios de Azure. El usuario Lee Gu está sincronizado(Figura 4); el usuario Lynne Robbins no lo está(Figura 5).
Figura 5Tambiénpuedes ver esta configuración en el panel Usuarios activos de Office 365, en la columna Estado de sincronización(Figura 6 y Figura 7).
Gráfico 7
En ocasiones, es posible que desee transferir la fuente de autoridad de una cuenta de usuario gestionada desde la nube. Por ejemplo, supongamos que una cuenta de usuario se crea directamente desde Office 365, lo que hace que el usuario esté gestionado desde la nube. Pero desea administrar ese usuario a través de AD local, como hacemos con el resto de sus usuarios.
Para ello, puede utilizar la sincronización de directorios. Este método utiliza la coincidencia SMTP para sincronizar la cuenta de usuario de Office 365 con una cuenta de usuario on-prem, basándose en el atributo proxyAddress.
Para sincronizar cuentas utilizando la correspondencia SMTP, se requieren dos pasos:
- Cree una cuenta AD con el mismo userPrincipalName que la cuenta Azure AD.
- Configure el atributo proxyAddress para que coincida con el proxyAddress del usuario de Azure AD.
La figura 8 muestra las propiedades del usuario Lee Gu en AD local. Aquí se crea el usuario y se le asignan los mismos proxyAddress y userPrincipalName que al usuario Lee Gu gestionado en la nube.
La Figura 9 muestra las propiedades del usuario Lee Gu en Azure AD.
Si Azure AD Connect encuentra un objeto en Azure AD con los atributos userPrincipalName y proxyAddress coincidentes, se produce la coincidencia SMTP. Si la sincronización hash de contraseñas está configurada, como ocurre de forma predeterminada, este proceso sobrescribe la contraseña existente de la cuenta de Azure AD con la contraseña de la cuenta local.
Notas importantes sobre el proceso de emparejamiento SMTP:
- El usuario AD debe sincronizarse de nuevo.
- Dirk-jan descubrió que si el usuario de Azure AD es un usuario activo con privilegios elevados, la sincronización no funciona. Por ejemplo, no se puede sincronizar un usuario on-prem a un usuario activo Global Administrator Azure AD. (Este problema se solucionó después de que Dirk-jan lo descubriera).
- Si userPrincipalName del usuario local no coincide con el usuario basado en la nube, se crea un nuevo usuario en la nube. Este usuario se sincroniza con el usuario local y tiene una dirección de correo electrónico válida de Office 365, que se determina por su atributo userPrincipalName en lugar de por su proxyAddress.
Por ejemplo, si intenta sincronizar el usuario Megan Bowen utilizando el atributo proxyAddress pero un userPrincipalName diferente, el resultado es un nuevo usuario de Azure AD, aunque no tenga acceso ni permisos en Azure AD(Figura 10).
Si crea un nuevo usuario local con el mismo atributo proxyAddress pero un userPrincipalName diferente(Figura 11), tendrá dos objetos de usuario denominados Megan Bowen, cada uno con un userPrincipalName diferente. El objeto más nuevo está sincronizado y el objeto original está gestionado en la nube por Azure AD(Figura 12).
Gráfico 12
Puede iniciar sesión con la nueva cuenta de usuario en la nube y la contraseña on-prem y configurar MFA(Figura 13).
Cómo la correspondencia SMTP puede dar lugar a abusos
El equipo de investigación de Semperis descubrió que es posible utilizar el emparejamiento SMTP para sincronizar usuarios on-prem con usuarios de Azure AD que son elegibles para roles administrativos. Los atacantes que han obtenido acceso on-prem pueden utilizar este método para comprometer Azure AD.
El proceso de emparejamiento SMTP funciona para usuarios con privilegios elevados que son elegibles para un privilegio que no ha sido activado. El abuso es posible tanto si el rol administrativo se ha hecho elegible directamente al usuario como a través de un grupo de Azure que sea elegible para activar el rol.
Para abusar del emparejamiento SMTP, o bien MFA debe estar sin usar o la activación de roles no debe requerir una verificación MFA. Creamos una lista de todos los roles con privilegios elevados que no requieren verificación MFA para la activación de roles(Tabla 1).
Tabla 1. Funciones con privilegios elevados y requisitos de verificación MFA
| Exigir AMF | No requieren AMF |
| Administrador de Protección de Información Azure Administrador de facturación Administrador de aplicaciones en la nube Administrador de Cumplimiento Administrador de acceso condicional Aprobador de acceso a clientes LockBox Redactores de directorios Administrador de Dynamics 365 Administrador de Exchange Administrador global Administrador de Intune Soporte Partner Tier1 Soporte Partner Tier2 Administrador de Power BI Administrador de funciones privilegiadas Administrador de seguridad Administrador de SharePoint Administrador de Skype Empresarial Administrador de usuarios |
Usuario invitado Usuario invitado restringido Invitado invitado Administrador del servicio de asistencia Administrador del servicio de asistencia Usuario Lectores de directorio Usuarios de dispositivos Administrador local del dispositivo unido a Azure AD Dispositivo unido Dispositivo unido en el lugar de trabajo Cuentas de sincronización de directorios Administradores de dispositivos Administrador de aplicaciones Desarrollador de aplicaciones Lector de seguridad Lector de informes Lector del centro de mensajes Administrador de Desktop Analytics Administrador de licencias Administrador de dispositivos en la nube Administrador de autenticación Administrador de autenticación privilegiada Administrador de comunicaciones de Teams Ingeniero de soporte de Teams Communications Especialista en soporte de comunicaciones de equipos Administrador de equipos Administrador de Insights Lector de privacidad del centro de mensajes ID externo Administrador de flujo de usuarios Administrador de atributos de flujo de usuario de ID externo Administrador del conjunto de claves B2C IEF Administrador de políticas de IEF B2C Administrador de proveedores de identidad externos Administrador de datos de conformidad Operador de seguridad Administrador de Kaizala Lector global Administrador de búsqueda Editor de búsqueda Administrador de contraseñas Administrador de impresoras Técnico de impresoras Administrador de políticas de autenticación Administrador de grupos Administrador de Power Platform Administrador de Azure DevOps Administrador de Identidad Híbrida Administrador de Office Apps Administrador de redes Administrador de Insights Administrador de dispositivos Teams Administrador de simulación de ataques Autor de la carga útil del ataque Resumen de uso Informes Lector Administrador de conocimientos Administrador de conocimientos Administrador de nombres de dominio Administrador de definición de atributos Administrador de asignación de atributos Lector de definición de atributos Lector de asignación de atributos Administrador de destinatarios de Exchange Administrador de gobierno de identidades Administrador de seguridad de aplicaciones en la nube Administrador de despliegue de Windows Update Administrador de Windows 365 Administrador de Edge Administrador de Visitas Virtuales Analista de Insights |
Por ejemplo, supongamos que el usuario gestionado por la nube Lidia Holloway es elegible para el rol de Administrador Global(Figura 14).
Utilice la correspondencia SMTP para sincronizar este usuario con un nuevo usuario on-prem(Figura 15).
Después de utilizar la contraseña on-prem de Lidia para iniciar sesión en Azure AD, se puede activar el rol de Administrador Global(Figura 16). Para ello, es necesario utilizar MFA ("Additional verification required"). Si el usuario original de la nube no requería MFA, puede simplemente configurarlo y luego activar el rol(Figura 17).
Figura 17
Puedes activar un rol que no requiera verificación extra MFA pero que pueda ser elevado a Administrador Global, como Administrador de Aplicaciones. Y como Dirk-jan describe, ese rol puede entonces ser escalado directamente al rol de Administrador Global.
Utilización de Semperis DSP para detectar esta vulnerabilidad de Azure AD
Semperis Directory Services Protector ( DSP) recopila datos de cambios de Azure AD. Para detectar un intento de explotar esta vulnerabilidad, DSP busca el patrón de ataque específico, que incluye la sincronización de un usuario de AD con un usuario de Azure AD que es elegible para un rol de alto privilegio, seguido de la activación de ese rol. DSP indicador de seguridad (SI) "Activación de rol de Azure AD después de la sincronización" identifica este patrón. DSP también identifica el SI "AAD user eligible for a high privilege role that is not synced to AD", que indica los usuarios de Azure AD que son elegibles para un rol de alto privilegio y tienen el atributo proxyAddress pero no están sincronizados con una cuenta local, haciéndolos vulnerables a este ataque.
Otras detecciones de abuso de concordancia SMTP
Otra opción es utilizar los registros de auditoría de Azure para buscar cualquier sincronización y activación de roles en su entorno(Figura 18).
En este ejemplo, puede ver que el Nombre del cliente de acción es "DirectorySync" y que el Valor antiguo de LastDirSyncTime está vacío. Esta información indica que es la primera vez que el usuario se sincroniza con AD local.
El siguiente registro muestra la activación de un rol(Figura 19). Utilizando el atributo RoleDefinitionOriginId, puede buscar el rol activado.
Corrección de abusos de concordancia SMTP
Para evitar este exploit, Microsoft recomienda exigir MFA a todos los usuarios ("Harden your Azure AD Connect server"). La mitigación se consigue asegurándose de que los usuarios tienen MFA configurado antes de concederles un rol elegible. También puede deshabilitar la opción de utilizar soft matching para la sincronización.
Divulgación
Este problema se notificó a través del Centro de respuesta de seguridad de Microsoft (MSRC) el 10 de junio de 2022. Microsoft respondió el 13 de julio: "Según nuestra evaluación, existen controles mitigadores que un usuario puede utilizar para evitar esta vulnerabilidad. Hemos determinado que el comportamiento es por diseño".
Más información
Para obtener más información sobre la protección de su organización frente a las vulnerabilidades de AD y Azure AD, consulte los siguientes recursos:
