Permisos delegados peligrosos que afectan a los datos

Microsoft expone las API a través de aplicaciones en Entra ID para permitir que las aplicaciones de terceros realicen acciones en Microsoft Entra ID, Microsoft 365 (O365) y servicios como SharePoint Online y Exchange Online. Los “permisos de API” protegen el acceso a estas API, que solo deben estar a disposición de las entidades de servicio que los necesitan. La aprobación de permisos se denomina “asignación del rol de aplicación” o “concesión de consentimiento”.

Ciertos permisos de algunas API de Microsoft pueden representar una amenaza para los datos confidenciales del entorno, ya que una entidad de servicio con estos permisos es capaz de acceder a información potencialmente confidencial, a la vez que es más discreta que un usuario con un rol de administrador potente, como un administrador global.

Cuando estos permisos son legítimos, aumentan el riesgo de vulneración de los datos. Cuando no son legítimos, pueden indicar un intento malintencionado de acceder a datos confidenciales, como correos electrónicos y proyectos, y robarlos.

Hay dos tipos de permisos de API en Microsoft Entra ID, como se describe en la documentación de Microsoft Información general sobre los permisos y el consentimiento:

• Permisos de aplicación: consulte el indicador de exposición relacionado “Permisos de aplicación peligrosos que afectan a los datos”.
• Permisos delegados: este indicador de exposición examina este segundo tipo, consulte el indicador de exposición relacionado “Permisos delegados peligrosos que afectan al inquilino” para ver las amenazas al inquilino de Microsoft Entra en su totalidad. El consentimiento proviene de los usuarios o administradores en nombre de toda la organización. Tenga en cuenta que estos permisos limitan la capacidad de la aplicación de realizar acciones en función del privilegio del usuario que inició sesión (es decir, la intersección del permiso con el nivel de privilegio del usuario). Por lo tanto, el nivel de peligrosidad de estos permisos delegados depende de los permisos reales del usuario de la aplicación, según se describe en Developing delegated permissions strategy (texto en inglés). Ejemplo: Si un usuario normal delegó el permiso “Group.ReadWrite.All”, en realidad permite que la aplicación modifique solo los grupos que el usuario puede editar, no todos los grupos. Microsoft los describe de la siguiente forma:

Los permisos delegados se usan por las aplicaciones que tienen un usuario que ha iniciado sesión y que, además, pueden recibir consentimiento del administrador o el usuario.

Este indicador de exposición (IoE) solo informa acerca de las entidades de servicio, ya que los permisos de API solo se aplican a las entidades de servicio, no a los usuarios.

Este IoE hace un seguimiento de una lista de permisos confidenciales, la mayoría de los cuales se explican por sí mismos. Sin embargo, el siguiente permiso exige mayor explicación:

• Group.Read.All (expuesto por Microsoft Graph API y Office 365 Exchange Online): este permiso es sorprendentemente de riesgo, ya que permite leer incluso el contenido “del calendario, las conversaciones, los archivos y otro contenido del grupo” de los grupos de M365. Tenga en cuenta las consecuencias para los grupos de M365 que Microsoft Teams utiliza.

Las aplicaciones legítimas con estos permisos confidenciales solicitan un acceso que puede ser excesivamente amplio. Esto también puede indicar un ataque de phishing denominado “concesión de consentimiento ilícito”, en el que un atacante logra obtener el consentimiento de un administrador.

De manera predeterminada, este IoE ignora las entidades de servicio deshabilitadas porque los atacantes no pueden usarlas de inmediato.

Referencias externas:

• Cloudbrothers - Azure Attack Paths (texto en inglés)
• Microsoft - Exchange Web Server API abuse (texto en inglés)
• Microsoft - Threat actors misuse OAuth applications to automate financially driven attacks (texto en inglés)

Para empezar, establezca si la entidad de servicio informada que tiene el permiso es legítima. Tenga en cuenta que, desde el punto de vista técnico, un ataque de phishing puede suplantar el nombre para mostrar. Si la entidad de servicio parece pertenecer a un proveedor de software conocido, pídale que confirme que el identificador de la aplicación informada le pertenece. Si la entidad de servicio es ilegítima y falsifica un nombre de aplicación conocido, debe llevar a cabo un análisis forense.

• Si la entidad de servicio es legítima:

  • Identifique el propietario y el rol para evaluar si realmente necesita estos permisos confidenciales.
    • Si se trata de una aplicación interna, evalúe sus funcionalidades y reduzca los permisos según el principio de privilegios mínimos, como se describe en la sección Consentimiento y autorización de la documentación de Microsoft Graph API. En esta guía se especifican los permisos mínimos necesarios para cada API.
    • Si se trata de una aplicación de terceros, valide que el acceso a los datos sea apropiado para esta aplicación (mismo perímetro). En caso contrario, solicite al proveedor que documente el motivo por el cual son necesarios esos permisos y si se pueden quitar de manera segura.
  • Como medida de defensa profunda, si tiene las licencias Premium de Identidades de carga de trabajo necesarias, considere usar Acceso condicional para las identidades de carga de trabajo. Esto le permite restringir las entidades de servicio de alto riesgo a ubicaciones de confianza conocidas y limitar el acceso en función de inicios de sesión de riesgo.

• De manera predeterminada, todos los usuarios pueden delegar permisos a cualquier aplicación, lo que les permite tomar decisiones de seguridad confidenciales. Consulte el indicador de exposición correspondiente “Consentimiento de usuario sin restricciones para aplicaciones”. Microsoft Entra ID brinda opciones que pueden habilitarse para configurar el consentimiento de los usuarios. Al habilitar las restricciones, los administradores de Microsoft Entra con ciertos roles tienen que administrar el consentimiento a las aplicaciones y evaluar las solicitudes de consentimiento. Consulte también cómo revisar las solicitudes de consentimiento del administrador.

• Capacite a los administradores para que detecten aplicaciones sospechosas y permisos confidenciales, incluidos los permisos delegados de usuarios privilegiados o confidenciales. Esto debe formar parte de un esfuerzo más amplio de gobierno de las aplicaciones.

• Quite un permiso si cree que es ilegítimo. Tenable recomienda guardar primero las pruebas, en caso de que tenga pensado llevar a cabo una investigación forense más exhaustiva. Siga las pautas de Microsoft para revisar los permisos concedidos a aplicaciones empresariales. Desafortunadamente, esta funcionalidad no está disponible en el portal de administración de Microsoft Entra:

No puede revocar permisos desde la pestaña “Consentimiento del usuario” mediante el portal de administración de Microsoft Entra. Sin embargo, puede revocar estos permisos mediante llamadas a Microsoft Graph API o cmdlets de PowerShell. Para obtener más información, consulte las secciones sobre PowerShell y Microsoft Graph de este artículo.

Además, Microsoft publicó dos guías sobre cómo llevar a cabo una investigación de la concesión de consentimiento de la aplicación y sobre la detección y corrección de concesiones de consentimiento ilícitas.

Asegúrese de quitar el permiso confidencial de la entidad de servicio (que se encuentra en el menú “Aplicaciones empresariales” del portal), en lugar de quitarlo de la aplicación (que se encuentra en el menú “Registros de aplicaciones”). Quitarlo de la aplicación solo elimina la solicitud de permiso y no afecta la asignación real del permiso.

Finalmente, habilite los registros de actividad de Graph API para capturar información detallada sobre los eventos de Graph API, lo que ayudará a su SOC o SIEM a detectar actividades sospechosas o llevar a cabo investigaciones forenses en caso de ataque. Además, supervise los inicios de sesión de las entidades de servicio y configure alertas para comportamientos sospechosos, en particular para las entidades de servicio confidenciales señaladas aquí.

Nombre: Permisos delegados peligrosos que afectan a los datos

Nombre en clave: DANGEROUS-DELEGATED-PERMISSIONS-AFFECTING-DATA

Gravedad: Medium

Tipo: Microsoft Entra ID Indicator of Exposure