Sin autorización: Elevación de privilegios a través de aplicaciones de Microsoft

Este artículo detalla una serie de descubrimientos del equipo de investigación de seguridad de Semperis que resultaron en la capacidad de realizar acciones en Entra ID más allá de los controles de autorización esperados, basados en el análisis del alcance de OAuth 2.0 (permisos). Nuestro descubrimiento más preocupante involucró la habilidad de agregar y remover usuarios de roles privilegiados, incluyendo el rol más poderoso en Entra ID: Administrador Global. Informamos de nuestros hallazgos al Centro de Respuesta de Seguridad de Microsoft (MSRC), y hemos trabajado con Microsoft para asegurar que estos descubrimientos han sido resueltos.

Aunque se desconoce si alguna organización fue comprometida previamente a través de este hallazgo en la naturaleza, un actor de amenaza podría haber utilizado dicho acceso para realizar la elevación de privilegios a Administrador Global e instalar más medios de persistencia en un inquilino. Un atacante también podría utilizar este acceso para realizar un movimiento lateral en cualquier sistema de Microsoft 365 o Azure, así como en cualquier aplicación SaaS conectada a Entra ID.

El descubrimiento requiere que el iniciador tenga el rol de Administrador de Aplicaciones o Administrador de Aplicaciones en la Nube en Entra ID, que se considera privilegiado. En muchas empresas, la desafortunada realidad es que los usuarios a los que se asignan estos roles no son tratados como privilegiados, lo que los convierte en objetivos principales para un atacante.

Las organizaciones afectadas deben saber cómo detectar si sus aplicaciones de Microsoft pueden haber sido atacadas, como se explica más adelante en este artículo.

Manual de integración de aplicaciones

Para entender este vector de ataque, es necesario comprender los componentes fundamentales implicados.

Es posible que los clientes de Microsoft 365 y Azure estén familiarizados con los sistemas y servicios con los que interactúan, incluidos Microsoft Teams, SharePoint Online, Exchange Online, Azure Key Vault y portales de administración como el portal de Azure y Microsoft 365 Admin Center, así como el conjunto de otros servicios de Microsoft. De lo que quizá no sea consciente es de los cientos de aplicaciones de Microsoft que mantienen su estado de Microsoft en funcionamiento. Fuera de la propia Microsoft, estas aplicaciones podrían denominarse aplicaciones de origen, ya que no son proporcionadas por un ISV de terceros.

Entra ID es la plataforma de identidad y el motor de autorización de cada entorno de Microsoft 365 y Azure. Los clientes que federan la autenticación a Okta, Ping Identity u otros proveedores de identidad con los servicios de Microsoft aún deben gestionar el modelo de autorización que existe dentro de su entorno Microsoft. Entra ID es el mecanismo de autorización subyacente que permite que estas aplicaciones de Microsoft interactúen y operen entre sí, utilizando estándares de la industria para autenticación y autorización modernas: OpenID Connect y OAuth 2.0.

Cada cliente de Microsoft tiene su propio tenant Entra (anteriormente conocido como Azure AD). En cada tenant, cada aplicación de Microsoft está representada por un objeto de seguridad principal conocido como service principal. Los usuarios y grupos son los principales de seguridad con los que todos estamos más familiarizados; puedes asignar roles y permisos a estos principales. Al igual que los usuarios y los grupos, las funciones y los permisos se pueden asignar a las aplicaciones a través de sus service principals. Estos roles y permisos se evalúan cuando se interactúa con Entra ID u otros servicios de Microsoft 365.

Aplicaciones multiusuario en Entra ID

Entra ID suele considerar que todas las aplicaciones de Microsoft, incluso las que tienen propiedades únicas, son aplicaciones multiusuario.

Con las aplicaciones multitenant, el desarrollador define cómo debe funcionar la aplicación en el registro de aplicaciones. Esto incluye acciones como la definición de los permisos de la API de Microsoft Graph que la aplicación necesita, así como la credencial utilizada por la aplicación para acceder a Microsoft Graph. Microsoft Graph es el punto final de la API unificada para varios servicios de Microsoft, incluido Entra ID.

Cuando una organización consume una aplicación multitenant, la aplicación está representada en el tenant consumidor por un principal de servicio(Figura 1).

El caso de las credenciales múltiples

Entra ID permite asignar y utilizar dos tipos de credenciales para la autenticación: secretos (contraseñas) y claves (certificados). Cualquiera de los dos tipos de credenciales funcionaba en el contexto de nuestro descubrimiento. En adelante, me referiré colectivamente tanto a los secretos como a las claves simplemente como credenciales.

Donde las cosas se ponen interesantes es que Entra ID permite el almacenamiento de credenciales en dos lugares: en el registro de la aplicación (que, como se ha mencionado, gestiona el desarrollador) y en el principal del servicio. En el caso de las aplicaciones multitenant, el service principal está en el tenant del cliente y bajo el control del cliente, que puede asignar credenciales al service principal(Figura 2).

Para proteger contra la asignación o uso de secretos en los principales de servicio, los desarrolladores de aplicaciones pueden utilizar un mecanismo en Entra ID llamado bloqueo de propiedades de instancia de aplicación. De nuestra investigación y discusión con Microsoft, Microsoft aprovecha un mecanismo diferente que puede proporcionar el mismo resultado final: no permitir la autenticación utilizando una credencial en un principal de servicio.

Tanto si una credencial se asigna a un registro de aplicación como a un servicio principal, ambos pueden utilizarse para realizar un flujo de concesión de credenciales de cliente OAuth 2.0 para actuar como esa aplicación en Microsoft Graph(Figura 3).

Durante un flujo de concesión de credenciales de cliente, se producen los siguientes pasos:

1. La aplicación utiliza su ID de cliente y credencial para autenticarse en Entra ID. Una aplicación es efectivamente cualquier cosa que conozca el ID de cliente, ID de inquilino y credencial. Así que para los propósitos de este abuso, aunque la aplicación nombrada podría ser una aplicación de Microsoft, la aplicación actuante es el atacante.
2. Entra ID valida el ID y la credencial del cliente y responde con un token de acceso.
3. La aplicación solicita datos a Microsoft Graph, pasando el token.
4. Microsoft Graph valida el token de acceso.
5. Si el token es válido, Microsoft Graph proporciona los datos o la acción solicitados.

Encontrará todos los detalles sobre este flujo en la documentación de Microsoft "Microsoft identity platform and the OAuth 2.0 client credentials flow".

Dado que Microsoft Graph es una API REST, acciones como GET pueden utilizarse para solicitar datos de Entra ID, y acciones como POST y PATCH pueden utilizarse para crear o modificar datos en Entra ID.

Si una aplicación tiene asignado el permiso de aplicación Group.Create y usted tiene la credencial para esa aplicación, puede crear un grupo, y los registros de auditoría de Entra ID mostrarían que el grupo fue creado por el principal de servicio para esa aplicación.

Como ejemplo, supongamos que tiene una aplicación de terceros llamada Custom Application, que utiliza para acceder a Microsoft Graph a través de Microsoft Graph PowerShell SDK. Las credenciales que se pasan como $creds contienen el ID de la aplicación y la credencial(Figura 4).

Si usted realizara acciones utilizando permisos consentidos para esta aplicación-en este caso, Group.Create-esasacciones aparecen en los registros de auditoría de Entra ID como realizadas por la aplicación. Como puede ver en la Figura 5, la aplicación es la entidad de seguridad principal responsable de la operación "Agregar grupo".

Actuar como aplicaciones de Microsoft

En Entra ID, Microsoft históricamente ha permitido a los clientes asignar credenciales a casi todos los principales de servicios de aplicaciones Microsoft. En instancias limitadas, estas credenciales pueden ser usadas en flujos de concesión de credenciales de cliente OAuth 2.0 para acceder a Microsoft Graph, actuando como la aplicación Microsoft dentro del propio tenant del cliente.

Al igual que con la aplicación personalizada del ejemplo anterior, asignamos una credencial al service principal para la aplicación de Microsoft Device Registration Service. A continuación, pudimos autenticarnos y acceder a Microsoft Graph como Device Registration Service(Figura 6).

Elevación de privilegios a través de aplicaciones de Microsoft

A través de nuestra investigación, descubrimos que a determinados principales de servicios de aplicaciones de Microsoft se les permitía realizar ciertas acciones que no estaban definidas en la lista de permisos autorizados. Es decir, se nos permitía realizar ciertas acciones privilegiadas aunque no pareciera que tuviéramos permiso para ello.

Dentro de Microsoft Graph, los permisos disponibles pueden determinarse examinando los ámbitosasignados , eltérmino OAuth 2.0 para los permisos.

En nuestro ejemplo que muestra la Figura 6, puedes ver que los ámbitos están vacíos para el Servicio de Registro de Dispositivos (Figura 7). Eso debería significar que esta aplicación no tiene permiso para hacer nada a través de la Graph API, y deberíamos haber recibido una respuesta 403 no autorizado al intentar una acción no autorizada.

Sin embargo, cuando intentamos realizar ciertas acciones privilegiadas, pudimos hacerlo. En este ejemplo, la Figura 8 y la Figura 9 muestran un intento exitoso de agregar un usuario al rol de Administrador Global como Servicio de Registro de Dispositivos.

Nuestras conclusiones

A través de nuestra investigación, hemos descubierto las siguientes capacidades para cada uno de los servicios especificados. El alcance del impacto está dentro del inquilino Entra objetivo.

Viva Engage (Yammer)

La habilidad de borrar y eliminar permanentemente usuarios, incluyendo usuarios privilegiados como Administradores Globales. MSRC clasificó esta capacidad como una vulnerabilidad de gravedad media.

Servicio de gestión de derechos de Microsoft

La capacidad de crear usuarios. El MSRC clasificó esta capacidad como de gravedad baja. La explicación de la gravedad baja se debió a que los objetos de usuario creados no tenían privilegios.

Servicio de registro de dispositivos

La habilidad de modificar la membresía de roles privilegiados, incluyendo el rol de Administrador Global. El MSRC clasificó esta capacidad como de gravedad importante, elevación de privilegios bajo Identidad (Entra ID).

Utilización del mecanismo de elevación y persistencia de privilegios

Todos nuestros hallazgos son preocupantes en el sentido de que eluden los controles de autorización conocidos. Sin embargo, el hallazgo del Servicio de Registro de Dispositivos es el punto focal para la elevación de privilegios y la persistencia potencial de un atacante.

En un tenant Entra, los Administradores de Aplicaciones, Administradores de Aplicaciones en la Nube, Administradores Globales y usuarios asignados como Propietarios de una aplicación pueden asignar credenciales al principal del servicio.

El Administrador de Aplicaciones y el Administrador de Aplicaciones en la Nube son considerados roles privilegiados por Microsoft, como se indica en su documentación "Microsoft Entra built-in roles". En muchas empresas, las integraciones de aplicaciones de terceros podrían proporcionar otras vías de elevación de privilegios y abuso si un Administrador de Aplicaciones o Administrador de Aplicaciones en la Nube se viera comprometido, sea o no la organización consciente de que están estableciendo estas vías.

Sin embargo, en un inquilino Entra greenfield (nuevo), ni el Administrador de Aplicaciones ni el Administrador de Aplicaciones Cloud tienen los derechos en un inquilino Entra para gestionar la asignación de roles privilegiados.

También es importante tener en cuenta que estos roles no tienen la capacidad de consentir permisos de Microsoft Graph API, lo cual es un malentendido común entre aquellos que trabajan con Entra ID.

Si un atacante consciente del fallo en el Servicio de Registro de Dispositivos comprometiera a un usuario asignado al rol de Administrador de Aplicaciones o Administrador de Aplicaciones en la Nube, el atacante podría usar ese acceso para obtener el rol de Administrador Global o cualquier otro rol deseado.

Aunque pueda parecer un poco contundente que un atacante persista con el rol de Administrador Global, la persistencia podría instalarse con estos privilegios creando un nuevo registro de aplicación y principal de servicio con permisos de aplicación privilegiados. Del mismo modo, un atacante podría instalar nuevos permisos de aplicación privilegiada en una aplicación de inquilino único existente o encontrar una aplicación privilegiada existente e instalar credenciales adicionales. Las organizaciones que no están continuamente monitoreando este tipo de cambios y que no tienen la madurez para determinar las operaciones conocidas de las maliciosas en Entra ID probablemente permanecerían inconscientes de la instalación de acceso persistente o la modificación temporal de la asignación de roles en Entra ID.

La solución y el eslabón perdido oculto

Agradecemos las conversaciones que mantuvimos con MSRC y el equipo de Microsoft Identity durante la resolución de nuestros hallazgos. Nuestra preocupación giraba principalmente en torno a la falta de alcance (permiso) dentro de nuestro acceso a Microsoft Graph.

Durante nuestra conversación, Microsoft señaló que dispone de otros mecanismos de autorización que existen entre bastidores para las aplicaciones de Microsoft. Estos mecanismos nos permitieron realizar las acciones descritas en este artículo.

Microsoft destacó acertadamente que esta capacidad no es, por tanto, un defecto material dentro de ninguno de sus modelos de autorización. Sin embargo, reconoció que externamente, basándose en lo que podemos ver y a lo que tenemos acceso, las capacidades podrían parecer erróneas. Externamente a Microsoft, los ámbitos de OAuth 2.0 son absolutos cuando se interactúa con Microsoft Graph, por lo que sin conocimiento de otros sistemas de autorización, sólo podemos inferir.

Además, nuestra investigación ha dado lugar a muchos cambios por parte de Microsoft para restringir aún más la capacidad de utilizar credenciales en las aplicaciones de Microsoft. Microsoft ha seguido implementando controles que restringen la capacidad de utilizar credenciales en los servicios principales. Hemos observado que la lista de principales de servicio con los que podemos autenticarnos ha disminuido continuamente.

Cuando ahora intentamos autenticarnos como Device Registration Service, recibimos un error de Microsoft Graph(Figura 10).

Detección de abusos anteriores

Es probable que las aplicaciones que constituyen el núcleo de nuestros hallazgos existan en la mayoría de las propiedades de los clientes de Microsoft. Estamos convencidos de que este fallo existe desde hace al menos el mismo tiempo que estas aplicaciones, es decir, desde hace varios años.

Los dos métodos de detección de este abuso son los registros de auditoría de Entra ID y las credenciales persistentes en las aplicaciones abusadas. Desafortunadamente, ambos métodos tienen sus límites. Los registros de auditoría proporcionan valor sólo durante el tiempo que se conservan, y un atacante podría haber eliminado la credencial en las aplicaciones abusadas iniciales después de instalar más persistencia.

Si una organización encuentra datos que indican que se han asignado credenciales al Servicio de Registro de Dispositivos o descubre datos de auditoría para el Servicio de Registro de Dispositivos, debería tener un alto nivel de preocupación. No conocemos ninguna razón válida para que el Servicio de Registro de Dispositivos tenga una credencial asignada.

Credenciales persistentes

Puede utilizar Microsoft Graph para inspeccionar los principales de servicio afectados, de modo que pueda determinar si se les han añadido credenciales adicionales.

Para estas consultas de Graph, inspeccione la salida para determinar si se han establecido valores o si la credencial se devuelve como nula.

El ID de aplicación es un valor único global. Estos comandos PowerShell y la consulta Microsoft Graph funcionarán en cualquier tenant Entra.

Servicio de registro de dispositivos

SDK Microsoft Graph PowerShell

((Get-MGServicePrincipal -Filter "AppId eq '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'").KeyCredentials).count

((Get-MGServicePrincipal -Filter "AppId eq '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'").PasswordCredentials).count

Consulta Microsoft Graph

https://graph.microsoft.com/v1.0/servicePrincipals(appId='01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9')?$select=keyCredentials,passwordCredentials

Entradas del registro de auditoría

Las organizaciones pueden examinar los datos de registro de auditoría del Entra ID que coincidan con ciertos patrones. Tenga en cuenta que la capacidad de buscar datos de registro de auditoría sólo será factible en la medida en que la organización haya almacenado dichos registros.

Búsqueda de acciones por el Servicio de Registro de Dispositivos

AuditLogs

| where parse_json(tostring(InitiatedBy.app)).displayName == "Device Registration Service"

Caza para la asignación de secretos al Servicio de Registro de Dispositivos

AuditLogs

| where OperationName == "Add service principal credentials"

| where TargetResources[0].displayName == " Device Registration Service"

Protección de los clientes de Semperis

Para los usuarios de Semperis Directory Services Protector ( DSP) o Purple Knightestamos lanzando un indicador de seguridad, Credenciales sospechosas en el servicio principal de Microsoft, que comprobará y notificará las credenciales asignadas a Device Registration Services y Viva Engage. Desde un enfoque de seguridad de identidad por capas, las organizaciones también pueden comprobar sus registros de auditoría SIEM en busca de marcadores.

Detener los ataques dirigidos a aplicaciones privilegiadas

Las aplicaciones con privilegios y sus principales de servicio en Entra ID son uno de los medios más comunes que tienen los atacantes para afianzarse y mantener la persistencia en Entra ID y para pasar a otros patrimonios en la nube como Microsoft 365, Azure y aplicaciones multicloud y SaaS que se integran con Entra ID.

Una de las mejores defensas que pueden adoptar las organizaciones es asegurarse de que el administrador de aplicaciones y el administrador de aplicaciones en la nube reciban el mismo trato privilegiado que los administradores globales, y que las mejores prácticas, como la separación de privilegios, las estaciones de trabajo con acceso privilegiado y la autenticación sólida resistente al phishing, se consideren requisitos y no opciones.

Investigación relacionada y agradecimientos

La investigación en el espacio de las aplicaciones Entra ID y los principales de servicio no es un concepto novedoso. Nuestra investigación se solapa con otra similar realizada en 2019 por Dirk-jan Mollema, que exploró la asignación de credenciales a los principales de servicio y el aprovechamiento de los permisos de aplicación de OAuth 2.0 para realizar funciones que un administrador de aplicaciones no debería poder llevar a cabo. Desde entonces, la lista de aplicaciones que se pueden utilizar ha disminuido y se redujo aún más en julio de 2024 como resultado de la respuesta de Microsoft a nuestros hallazgos.

Divulgación y calendario

Los descubrimientos descritos en este post se comunicaron al MSRC tal y como se documenta en la siguiente cronología. Al tratarse de un descubrimiento complejo, llevó algún tiempo analizar los hallazgos con el MSRC. Apreciamos la rapidez con la que se resolvió el hallazgo del Servicio de Registro de Dispositivos y el compromiso por parte de Microsoft para asegurar aún más sus aplicaciones basadas en nuestro trabajo de colaboración.

• 11 de enero de 2024: Creación de los casos MSRC
• 30 de enero de 2024: MSRC proporcionó una respuesta inicial de baja gravedad
• 6 de febrero de 2024: Respuesta al MSRC sobre la asignación de severidad
• 4 de marzo de 2024: Servicio de Registro de Dispositivos reclasificado como gravedad importante
• 4 de marzo de 2024: Viva Engage clasificado como de gravedad baja
• 4 de marzo de 2024: Microsoft Rights Management Services clasificado como de gravedad baja
• 4 de marzo de 2024: Caso de Microsoft Rights Management Services resuelto y cerrado
• 4 de marzo de 2024: Caso del Servicio de Registro de Dispositivos resuelto y cerrado
• 1 de abril de 2024: Viva Engage reclasificado como de gravedad media
• 17 de abril de 2024: Notificación inicial a MSRC en relación con la divulgación.
• 19 de abril de 2024: Caso Viva Engage resuelto y cerrado
• 5 de junio de 2024: Envío del borrador del artículo de divulgación al MSRC
• 13 de junio de 2024: Reunión con el MSRC sobre casos y divulgación
• 7 de agosto de 2024: Divulgación pública