Llegamos a ustedes gracias a:



Reportajes y análisis

Cómo Azure Active Directory abre nuevos riesgos de autenticación

[11/09/2022] Hace años que se sabe que las redes locales de Windows Active Directory son vulnerables a los ataques de retransmisión NTLM y pass-the-hash que pueden permitir a los atacantes moverse lateralmente por las redes y acceder a máquinas y recursos adicionales. Dado que algunos de estos ataques se aprovechan de las decisiones de diseño en los protocolos de autenticación utilizados dentro de las redes de Windows, no pueden ser simplemente parcheados por Microsoft con cambios en el software. Las organizaciones deben adoptar medidas de defensa en profundidad que impliquen configuraciones más estrictas y controles adicionales para protegerse.

[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]

Con la adopción de redes híbridas, en las que parte de las redes son locales y parte están en la nube, las empresas dependen ahora de servicios como Azure Active Directory (Azure AD) para permitir que sus distintas máquinas se autentiquen entre sí. Pero Azure AD es bastante diferente del AD local, ya que utiliza protocolos diferentes y tiene nuevas características que amplían las posibilidades de conexión en red de las organizaciones. Sin embargo, según las presentaciones realizadas el mes pasado en la conferencia de seguridad Black Hat USA, también ofrece nuevas posibilidades a los atacantes.

Del pass-the-hash al pass-the-certificate

Pass-the-hash es un ataque que consiste en que los hackers extraen versiones hash de las credenciales almacenadas localmente en una máquina comprometida y las utilizan para autenticarse en otras máquinas. La retransmisión NTLM es un método que consiste en interceptar las solicitudes de autenticación entre un cliente y un servidor, y retransmitir los retos y las respuestas entre ambos para que el atacante se autentique en lugar del cliente. Estos métodos de ataque son comúnmente utilizados por sofisticados grupos de hackers en ataques dirigidos.

En Azure AD, sin embargo, los ataques tradicionales de pass-the-hash y relay no funcionan porque Azure AD no utiliza NTLM o Kerberos, que son los protocolos de autenticación estándar en las redes de Windows. En su lugar, utiliza OAuth, SAML, OpenID y un nuevo protocolo llamado NegoEx, que es una extensión de la Interfaz de Programa de Aplicación de Servicios de Seguridad Genéricos (GSSAPI, por sus siglas en inglés) estandarizada en la que se basa Kerberos.

Según el investigador de Microsoft, Mor Rubin, NegoEx estará habilitado en cualquier dispositivo que se una a Azure AD, y es el mecanismo a través del cual los diferentes dispositivos unidos a Azure AD se autenticarán entre sí. El handshake de autenticación NegoEx se basa en un certificado de cliente que es único para cada usuario y es emitido por Azure AD con una validez de una hora.

En Black Hat, Rubin demostró cómo se puede realizar con éxito un ataque de retransmisión en el handshake de NegoEx, de forma similar a como se puede realizar contra NTLM. A continuación, mostró cómo un atacante puede obtener el certificado de cliente peer-to-peer utilizando un método similar, y luego utilizar ese certificado para autenticarse en otras máquinas. En otras palabras, se trata de los equivalentes a NTML relay y pass-the-hash, pero en el contexto de los dispositivos unidos a Azure AD a pesar de la diferencia en los protocolos utilizados.

También sugirió que las empresas supervisen sus registros en las máquinas de Azure AD en busca de solicitudes de autenticación procedentes de nombres de clientes con direcciones IP que no coinciden, o de solicitudes de autenticación a través de certificados emitidos a usuarios que no están asociados con las máquinas a las que llegan las solicitudes. La presentación de Rubin fue la culminación de la investigación que comenzó el año pasado, y también incluyó el lanzamiento de una herramienta de retransmisión NegoEx de código abierto llamada Negoexrelayx.

Abusando de las identidades externas en Azure Active Directory

En una presentación separada de Black Hat que destacó las amenazas exclusivas de Azure AD que no existen en el despliegue local de Active Directory, el investigador holandés Dirk-jan Mollema de Outsider Security demostró cómo encontró una manera de abusar de la característica de identidades externas para hacer backdoor en las cuentas de Azure AD.

Las identidades externas son una característica de Azure AD donde las organizaciones pueden dar a los usuarios externos acceso a ciertos recursos. Estos usuarios pueden ser parte de un tenant de Azure AD diferente, o pueden ser autenticados a través de un proveedor de identidades externo e identificados solo a través de una dirección de correo electrónico. Esta funcionalidad es popular para las organizaciones que trabajan con contratistas externos, así como para conceder acceso a los proveedores de servicios gestionados que administran las suscripciones.

Los usuarios externos pueden ser invitados por alguien con privilegios de administrador a través de la interfaz de Azure AD, y esto hará que se genere un enlace de invitación que se enviará por correo electrónico al usuario externo. El problema, según descubrió Mollema, es que las invitaciones también pueden generarse y aceptarse de forma programática a través de la API de Azure AD llamada AAD Graph.

Además, resultó que, al interactuar con esta función a través de la API, no se realizaban muchas comprobaciones. En primer lugar, cualquier usuario dentro del tenant de Azure AD podía consultar la API y ver las invitaciones que aún no habían sido reclamadas. En segundo lugar, cualquier invitación podía ser canjeada a través de la API sin ninguna validación, y podía estar vinculada a una cuenta externa diferente a la que estaba destinada. En tercer lugar, los administradores no tenían forma de saber que una invitación había sido secuestrada a través de la interfaz.

El ataque también podía eludir la lista de nombres de dominio permitidos para la colaboración externa en el tenant Azure AD, ya que la invitación podía generarse para una dirección de correo electrónico en un dominio, pero luego ser secuestrada y vinculada a una cuenta en un dominio no incluido en la lista blanca. Además, puede haber reglas automatizadas para dar a una cuenta que canjea una determinada invitación privilegios automatizados, lo que lleva a la escalada de privilegios.

Mollema llevó el ataque aún más lejos. Al analizar el aspecto de las identidades externas en Microsoft Graph, una API de Microsoft para desarrolladores, en lugar de en AAD Graph, se dio cuenta de que algunas de las propiedades asociadas a una identidad podían modificarse a través de MS Graph si se disponía de los privilegios adecuados. Uno de estos atributos es la propiedad del emisor que define el proveedor de identidad, y una de las opciones disponibles es simplemente "correo". Esto se utiliza para los usuarios externos que solo se identifican por correo electrónico y aún no tienen una cuenta de Microsoft o Azure AD.

A continuación, analizó quién puede modificar estos atributos y descubrió que, además de los administradores, las aplicaciones en las que los usuarios inician sesión y tienen los privilegios adecuados, también pueden modificar las identidades y los usuarios pueden modificar su propia identidad a través del gráfico de MS. Esto abrió la puerta a interesantes ataques como el backdooring de cuentas existentes si un atacante consigue acceso temporal a ellas robando un token de acceso o consiguiendo el control temporal de una computadora en el que tienen una sesión activa.

Además, si la cuenta resulta ser un administrador de usuarios, podrían hacer backdooring de todas las cuentas añadiendo identidades externas a las mismas, y vinculándolas a direcciones de correo electrónico bajo el control de los atacantes. También podrían hacer esto para los administradores globales, ya que tienen el permiso para modificar sus identidades a través del MS Graph.

El problema con esto es que modificar una identidad de esta manera solo cambia su método de autenticación principal, de un nombre de usuario y contraseña a la autenticación a través de un correo electrónico externo. Sin embargo, si la cuenta también tiene configurada la autenticación multifactor (MFA), el atacante seguiría sin poder iniciar la sesión.

Mollema también encontró un bypass para esto. Primero, utilizó la cuenta de la víctima temporalmente comprometida para generar una invitación para la cuenta externa del atacante. El atacante aceptó la invitación, lo que hizo que se creara una cuenta de invitado para él en el tenant de la víctima. A continuación, el atacante inició sesión en la cuenta de invitado y configuró la MFA para él.

A continuación, utilizando la cuenta de la víctima, eliminó la cuenta de invitado. Aunque esto elimina la cuenta de invitado asociada a la cuenta externa del atacante, no borra el token de MFA, que está almacenado en la caché. Así, la cuenta externa del atacante sigue teniendo un token MFA activo en el tenant Azure AD de la víctima, aunque la cuenta de invitado asociada haya desaparecido. El atacante puede entonces hacer una puerta trasera en la cuenta de la víctima y añadir su cuenta externa como una identidad y entonces ya no se le pedirá la autenticación MFA. Esto evita la protección MFA de la víctima.

Mitigación de Azure AD y otras vulnerabilidades de autenticación en la nube

Microsoft ya ha corregido la mayoría de los problemas que Mollema descubrió, por lo que los ataques que describió ya no funcionan. Sin embargo, sus descubrimientos muestran lo compleja que puede ser la autenticación en los nuevos entornos en la nube. La introducción de nuevas características, como permitir el uso de la OTP del correo electrónico como proveedor de identidad o de identidades externas, siempre puede dar lugar a fallas lógicas que podrían permitir la evasión.

Mollema aconseja a las organizaciones que eliminen con regularidad todas las cuentas de invitados con invitaciones no canjeadas, que bloqueen los derechos de invitación y la configuración de acceso de los invitados, que restrinjan los inquilinos autorizados para la colaboración externa, que apliquen la MFA en todas las aplicaciones, y que busquen en los registros de acceso indicios de posibles abusos de las cuentas de invitados.