¿Nuevas rutas de ataque? Boletos de servicio solicitados por AS

Jul 18, 2023

Inicio » Ciberseguridad » Noticias SBN » ¿Nuevas rutas de ataque? Boletos de servicio solicitados por AS

Mientras ayudaba a Andrew Schwartz con su publicación Kerberos FAST (que tiene más información sobre qué es FAST y cómo funciona, así que lea), noté algo interesante. Los AS-REQ para cuentas de máquina no están protegidos. Esto es descrito por Microsoft aquí:

El blindaje de Kerberos utiliza un vale de otorgamiento de vales (TGT) para que el dispositivo proteja los intercambios de servicios de autenticación con el KDC, por lo que el intercambio de servicios de autenticación de la computadora no está blindado. El TGT del usuario se utiliza para proteger sus intercambios de TGS con el KDC.

Esto me hizo preguntarme si era posible solicitar tickets de servicio (ST) desde el servicio de autenticación (AS). La capacidad de solicitar ST del AS tiene varias consecuencias, incluidas nuevas rutas de ataque, desvíos de detección y posible debilitamiento de los controles de seguridad. Todos los problemas discutidos en esta publicación se informaron a Microsoft y se "consideraron que eran por diseño" (Figura 1).

Primero, aquí hay una descripción general de alto nivel del flujo típico de Kerberos (Figura 2, procedente de ADSecurity):

El hecho de que se emita una clave de sesión para cada ticket es una característica importante para la siguiente investigación. Esta clave de sesión se devuelve a la cuenta solicitante dentro de una sección cifrada de la respuesta; el solicitante ya conoce la clave de cifrado.

Por ejemplo, la clave de sesión de TGT se almacena dentro de una sección que se cifra con la clave utilizada para probar la identidad del solicitante al solicitar un TGT. Esta clave es normalmente la clave a largo plazo (hash de contraseña) de la cuenta. Pero en el caso de la criptografía de clave pública para la autenticación inicial (PKINIT) en el protocolo Kerberos, la clave se deriva del certificado. La clave de sesión ST se almacena dentro de una sección que está encriptada con la clave de sesión TGT.

La clave de sesión del ticket es necesaria para utilizar el ticket en el siguiente paso del flujo de Kerberos.

Una solicitud de Kerberos tiene dos secciones principales:

El cuerpo del requerimiento se envía principalmente en texto sin formato y contiene varios datos:

Una respuesta de Kerberos tiene varias secciones y contiene una parte cifrada:

La parte del flujo de Kerberos en la que se centra esta publicación es AS-REQ/AS-REP, que generalmente se usa para solicitar un TGT. En operaciones normales, un AS-REQ tiene uno de dos valores dentro de sudespegacampo dentro del cuerpo del requisito:

Noté que con Kerberos Flexible Authentication Secure Tunneling (FAST) aplicado, las cuentas de máquina aún enviaban sus AS-REQ sin protección. Me preguntaba si se podría usar un AS-REQ para solicitar un ST directamente, en lugar de un TGT. Esto me hizo modificar Rubeus para determinar si especificar otro SPN dentro deldespega de un AS-REQ haría que el DC respondiera con un ST para ese SPN. Resulta que la respuesta fue "sí" (Figura 3).

Al usar una cuenta de máquina, puedo solicitar un ST sin usar blindaje cuando se aplica FAST. ¿Qué más es posible?

Kerberoasting, descubierto por Tim Medin, es un método para recuperar la contraseña de texto sin formato o hash NT para una cuenta de servicio, generalmente una cuenta de usuario con un SPN. Kerberoasting es posible porque parte de un ST está encriptado con la clave a largo plazo de la cuenta de servicio (hash de contraseña). Al extraer la parte cifrada del ticket, es posible formar un hash a partir de varias contraseñas de texto claro e intentar descifrar la parte cifrada. Si el descifrado es exitoso, entonces el hash utilizado es la clave a largo plazo utilizada para cifrar el ticket. Esa clave se puede usar en última instancia para autenticarse como la cuenta de servicio.

Además, cualquier cuenta puede solicitar un ST para cualquier servicio. Por lo tanto, se requiere la capacidad de autenticarse en Active Directory (AD) para realizar el ataque. Al menos, eso solía ser cierto.

Primero, traté de usar una cuenta que no requería autenticación previa (DONT_REQ_PREAUTH) para solicitar una ST. Cuando una cuenta no requiere autenticación previa para autenticarse, se puede solicitar un TGT sin requerir datos de autenticación previa, que se cifra con algún tipo de credencial (por ejemplo, hash de contraseña, certificado). Si un atacante no ha obtenido una credencial válida para una cuenta, no se puede generar una autenticación previa válida. Si no se requiere autenticación previa, esto no es un problema.

Cuando se solicita un ticket sin autenticación previa, el resultado aún incluye una parte cifrada. Esta parte cifrada está cifrada con la clave de credencial utilizada para la autenticación y contiene la clave de sesión del ticket incluida en la respuesta. Estos son los datos cifrados utilizados en el ataque ASREPRoast de Will Schroeder. El TGT resultante solo se puede usar con acceso a la clave de cuentas solicitante, ya que se requiere la clave de sesión de TGT.

Sin embargo, para Kerberoasting, no se requiere acceso a la clave de sesión. Solo se requiere el ST resultante, o más exactamente, la parte cifrada del ST, que no está protegida con la clave de la cuenta solicitante. Por lo tanto, si alguna cuenta está configurada para no requerir autenticación previa, es posible Kerberoast sincualquier cartas credenciales. Este método de Kerberoasting se ha implementado en Rubeus dentro de este PR.

Debido a que aún no se logró el acceso a una cuenta válida, no se puede consultar LDAP. En su lugar, se requiere una lista de posibles cuentas de servicio. La investigación anterior de Arseniy Sharoglazov muestra que los ST se pueden solicitar utilizando solo el nombre de usuario de la cuenta de servicio en lugar de requerir el SPN real, muy útil para esta investigación.

Se puede generar una lista de nombres de usuario de varias maneras, incluida la enumeración de usuarios mediante sesiones nulas en un controlador de dominio, la generación de una lista de nombres de usuario mediante inteligencia de código abierto (OSINT) o la adivinación de posibles nombres de usuario. Cualquier lista de posibles nombres de usuario se puede verificar fácilmente enviando un AS-REQ sin autenticación previa. Un nombre de usuario válido que requiere autenticación previa recibe unKDC_ERR_PREAUTH_REQUIREDerror (Figura 4).

Un nombre de usuario válido que no requiere autenticación previa recibe un TGT (Figura 5).

Un nombre de usuario inválido recibe unKDC_ERR_C_PRINCIPAL_UNKNOWNerror (Figura 6).

Para fines de demostración, se genera una lista usando una sesión nula en el DC, usando el método de ciclo RID de enum4linux-ng (-R), como muestra la Figura 7.

Usando esta lista de nombres de usuario, determinar las cuentas que no requieren autenticación previa es fácil en AD (Figura 8).

Tenga en cuenta que los AS-REQ sin autenticación previa no se registran como un evento de Windows a menos que la cuenta no requiera autenticación previa.

Con la lista de nombres de usuario y el nombre de usuario de una cuenta que no requiere autenticación previa, se puede lanzar el ataque (Figura 9).

La salida resultante se puede usar para intentar descifrar contraseñas sin conexión.

Otra consecuencia interesante es la capacidad de Kerberoast desde una posición Man-in-the-Middle (MitM). Este tipo de ataque generalmente no es posible con TGS-REQ porque el opcionalcksum El campo dentro del autenticador dentro de AP-REQ protege el cuerpo de solicitud de la solicitud y, con frecuencia, lo incluyen los clientes Windows Kerberos originales. Por lo tanto, modificando ladespegade un TGS-REQ sin actualizar la suma de verificación dentro del autenticador invalida la suma de verificación del autenticador y devuelve unKRB_AP_ERR_MODIFIED error. Pero esto no es un problema para AS-REQ porque elreq-cuerpo, y en consecuencia ladespegacampo, no están protegidos.

Mientras probaba este enfoque, descubrí que los AS-REQ se pueden reproducir muchas veces. Un atacante necesita capturar solo un AS-REQ para enviar muchos AS-REQ con diferentesdespegavalores.

Para demostrar este enfoque, escribí una prueba de concepto aproximada (POC). Este POC, RoastInTheMiddle, implementa una suplantación de ARP entre los DC y los sistemas de las víctimas para realizar un ataque MitM. Luego, el POC pasa el tráfico mientras escucha los AS-REQ. Cuando se encuentra un AS-REQ, el POC realiza un Kerberoast. El POC no está preparado para un ataque, pero demuestra que un ataque es posible.

Primero, el POC inicia cuatro subprocesos, un sniffer, un suplantador de ARP, un reensamblador (para solicitudes que se dividen en varios paquetes) y el tostador (Figura 10).

Cuando ve un AS-REQ, el POC comienza a intentar Kerberoast en la lista proporcionada, que puede contener nombres de usuario o SPN (Figura 11).

Como muestra la Figura 11, este intento da como resultado que cualquier ST recibido se emita en formato hashcat, listo para descifrar la contraseña sin conexión.

La capacidad de MitM AS-REQ, luego modificarlos y reproducirlos, también podría ser útil para desarrollar otros ataques. Intenté modificar las opciones de kdc para incluir elproxyablebandera, lo que resulta en un boleto con elproxyable conjunto de banderas Sin embargo, no pude encontrar una ruta de ataque usando ese boleto y bandera. Este comportamiento también podría permitir el uso de otras cuentas para realizar un Kerberoast, lo que permite a los atacantes evitar quemar una cuenta comprometida.

Algunas mejoras podrían ser posibles para este proceso. Primero, es posible forzar un AS-REQ desde un TGS-REQ al interceptarlo y responder con unKRB_AP_ERR_BAD_INTEGRIDAD error. Hacerlo obliga al cliente a volver a autenticarse enviando un AS-REQ.

También debería ser posible realizar este ataque mediante la inyección de servidor de nombres DHCPv6 (como mitm6 de Dirk-jan Mollema o Inveigh de Kevin Robertson), respondiendo a consultas SRV DNS para el servicio LDAP y luego tratando con la siguiente conexión LDAP.

Soporte para modificar eletiposdentro de la solicitud permite ataques de degradación de tipo de cifrado cuando el entorno lo permite, como lo describe Will Schroeder aquí.

Por último, el POC requiere la instalación de Npcap en el sistema que ejecuta el POC (que usa sharppcap), principalmente para la suplantación de identidad de ARP. Si toma la ruta IPv6 o implementa las respuestas ARP mediante sockets sin formato, puede eliminar esta dependencia.

Muchas detecciones de Kerberos se basan en eventos 4769 (se solicitó un ticket de servicio de Kerberos). Sin embargo, solicitar un ticket de servicio mediante un AS-REQ no produce 4769 eventos sino 4768 eventos (se solicitó un ticket de autenticación Kerberos (TGT)).

La Figura 12 muestra un evento 4768 cuando se solicita un ST utilizando un AS-REQ.

Por lo tanto, los atacantes que usan este método pueden eludir fácilmente muchas detecciones que se basan en eventos 4769.

Aunque no pude solicitar boletos de S4U2self del AS, los ST recuperados del AS carecen de la suma de verificación del boleto (traído para proteger los boletos de S4U2self contra el ataque de broca de bronce de Jake Karnes).

Por último, un ST solicitado al TGS generalmente se devuelve con un PAC (Figura 13).

Es posible solicitar un ST sin PAC al TGS, pero hacerlo requiere cambiar las cuentas de servicioNO_AUTH_DATA_REQUIREDbit en el atributo useraccountcontrol (Figura 14).

Cuando esta configuración está en su lugar, el ST devuelto carece de un PAC, como lo muestra la diferencia en el tamaño del boleto devuelto (Figura 15).

Se puede solicitar un ST sin PAC desde el AS simplemente configurando la sección de datos PA-PAC-OPTIONS PA en falso agregando el/nopaccambie a Rubeus (Figura 16).

Este enfoque podría usarse como una alternativa a la creación de boletos plateados, solicitando un ST sin un PAC, luego inyectando otro PAC incluyéndolo dentro delenc-autorización-datos sección de la solicitud. También podría proporcionar otras posibles rutas de ataque.

Debido a que aparentemente Microsoft no considera que valga la pena solucionar estos problemas, la única opción es la detección dentro de su organización. Como se mostró anteriormente, cuando se solicita un ST desde el AS, se registra el evento 4768 (Figura 17).

En este caso, puede ver que el Nombre del servicio y la ID del servicio no sonkrbtgt.Todas las entradas genuinas solicitadas al AS, incluidaskadmin/cambiar contraseñaboletos, tener un Nombre de servicio y una ID de servicio dekrbtgt(Figura 18).

Comprobación del tráfico de red en busca de AS-REQ que no sean para elkrbtgt/dominiookadmin/cambiar contraseñatambién debería detectar estas solicitudes (Figura 19).

Esta investigación, junto con la respuesta de Microsoft, demuestra la necesidad de una supervisión continua y medidas de protección adecuadas. La capacidad de eludir las detecciones actuales y realizar ataques efectivos, como Kerberoasting, desde una posición no autenticada es un problema grave que no debe ignorarse. La investigación descrita aquí podría conducir a más ataques novedosos, lo que podría poner a las organizaciones en mayor riesgo.

Asegúrese de que haya detecciones cuando se realicen este tipo de solicitudes de tickets.

Me gustaría que las siguientes personas por sus contribuciones a esta investigación:

El post ¿Nuevas rutas de ataque? AS Requested Service Tickets apareció primero en Semperis.

*** Este es un blog sindicado de Security Bloggers Network de Semperis escrito por Charlie Clark. Lea la publicación original en: https://www.semperis.com/blog/new-attack-paths-as-requested-sts/