Constrained Delegation

Ahora me toca explicar Constrained Delegation (me quiero morir.) al menos esta es de las mas faciles

Configuración y Enumeración

En lugar de la bandera TRUSTED_FOR_DELEGATION, la delegación restringida se configura mediante el atributo msDS-AllowedToDelegateTo en el objeto de equipo. Este atributo contiene una lista de los SPN a los que este equipo tiene permitido delegar.

Podemos enumerar estos equipos usando ldapsearch:

beacon> ldapsearch (&(samAccountType=805306369)(msDS-AllowedToDelegateTo=*)) --attributes samAccountName,msDS-AllowedToDelegateTo
sAMAccountName: [SERVIDOR_FRONT_1]$
msDS-AllowedToDelegateTo: cifs/[SERVIDOR_BACK_1].[DOMINIO.COM], cifs/[SERVIDOR_BACK_1

Este resultado nos dice que el servidor [SERVIDOR_FRONT_1]$ puede delegar la autenticación al servicio cifs en [SERVIDOR_BACK_1].

Escenarios de Constrained Delegation

El flujo exacto depende de cómo se autentica el usuario en el servicio front-end.

1. Escenario "Solo Kerberos" (S4U2proxy)

Este es el flujo predeterminado y más simple.

  1. El usuario se autentica en el servicio front-end (ej. http/[SERVIDOR_FRONT_1]$) usando Kerberos y presenta un ticket de servicio.

  2. El servicio front-end almacena en caché este ticket.

  3. Cuando necesita acceder al back-end (ej. cifs/[SERVIDOR_BACK_1]), el front-end envía una solicitud TGS-REQ al KDC. Esta solicitud incluye su propia autenticación y una copia del ticket de servicio del usuario.

  4. El KDC verifica que cifs/[SERVIDOR_BACK_1] esté en la lista msDS-AllowedToDelegateTo de [SERVIDOR_FRONT_1]$.

  5. Si la comprobación es exitosa, el KDC devuelve un ticket de servicio para cifs/[SERVIDOR_BACK_1] a nombre del usuario.

  6. El front-end usa ese ticket para acceder al back-end como el usuario.

Esto es S4U2proxy en acción.

2. Escenario con Transición de Protocolo (S4U2self + S4U2proxy)

¿Qué pasa si el usuario se autentica en el front-end usando NTLM? El servidor front-end no tendrá un ticket de servicio del usuario para usar en la solicitud S4U2proxy.

Aquí es donde entra en juego la Transición de Protocolo.

Esta función debe habilitarse explícitamente estableciendo la bandera TRUSTED_TO_AUTH_FOR_DELEGATION (valor decimal 16777216) en el atributo UserAccountControl del equipo de front-end.

Primero, buscamos el valor UAC del equipo:

Luego, verificamos si la bandera está activa con una operación AND a nivel de bits (el valor predeterminado para un equipo es 4096).

Dado que es True, la transición de protocolo está habilitada. El flujo ahora es:

  1. El usuario se autentica en el front-end (ej. con NTLM).

  2. El front-end, al no tener ticket de usuario, realiza una solicitud S4U2self. Envía un TGS-REQ al KDC pidiendo un ticket para sí mismo ([SERVIDOR_FRONT_1]$) pero en nombre del usuario ([USUARIO_ADMIN], por ejemplo).

  3. El KDC devuelve un ticket de servicio para [USUARIO_ADMIN]@[SERVIDOR_FRONT_1]$. Este ticket está marcado como "reenviable" (forwardable).

  4. El front-end ahora usa este ticket reenviable para realizar la solicitud S4U2proxy que vimos antes, pidiendo un ticket para el back-end (cifs/[SERVIDOR_BACK_1]) como [USUARIO_ADMIN].

  5. El KDC lo aprueba y el front-end accede al back-end.

Atacando la Constrained Delegation (S4U)

Si un atacante compromete un servidor configurado para delegación restringida puede abusar de esta confianza. El método varía según si la transición de protocolo está habilitada.

Ataque con Transición de Protocolo

Este es el ataque más poderoso. Como la transición de protocolo está habilitada, el atacante puede suplantar a cualquier usuario que desee, incluido un Administrador de Dominio.

Solo necesitamos un TGT para la cuenta del equipo comprometido. Rubeus puede realizar los pasos S4U2self y S4U2proxy en un solo comando s4u:

  • /user: El principal configurado para la delegación.

  • /msdsspn: El servicio de destino al que podemos delegar.

  • /ticket: El TGT de la cuenta de equipo que controlamos.

  • /impersonateuser: El usuario que queremos suplantar (¡cualquiera!).

Paso 1: Rubeus realiza S4U2self

Rubeus usa el TGT de [SERVIDOR_FRONT_1]$ para solicitar un ticket para sí mismo en nombre de [USUARIO_ADMIN].

Este ticket devuelto es reenviable (forwardable).

Paso 2: Rubeus realiza S4U2proxy

Rubeus usa automáticamente ese ticket reenviable para solicitar un ticket al SPN de destino.

Paso 3: Usar el ticket

Ahora tenemos un ticket válido para el servicio CIFS en [SERVIDOR_BACK_1] como [USUARIO_ADMIN]. Podemos inyectarlo y acceder al recurso.

Ataque SIN Transición de Protocolo

Si la bandera TRUSTED_TO_AUTH_FOR_DELEGATION no está habilitada, el ataque es más difícil.

No podemos suplantar a un usuario arbitrario. El paso S4U2self seguirá funcionando, pero el ticket que devuelve no tendrá la bandera "reenviable". Si intentamos usarlo para S4U2proxy, fallará con el error KDC_ERR_BADOPTION.

En este escenario, el atacante debe obtener primero un ticket de servicio legítimo que un usuario haya solicitado para el servicio front-end (nuestro servidor comprometido, [SERVIDOR_FRONT_1]$). Estamos limitados a suplantar solo a los usuarios que se autentican en este servidor.

Supongamos que hemos capturado un ticket del usuario [USUARIO_EJEMPLO] para HTTP/[SERVIDOR_FRONT_1].

Ahora, modificamos nuestro comando Rubeus. En lugar de /impersonateuser, usamos el parámetro /tgs para proporcionar el ticket de servicio capturado de [USUARIO_EJEMPLO].

  • /tgs: El ticket de servicio capturado del usuario ([USUARIO_EJEMPLO]) al servicio front-end.

Rubeus usará este ticket para realizar directamente la solicitud S4U2proxy.

Obtenemos un ticket para cifs/[SERVIDOR_BACK_1] como [USUARIO_EJEMPLO]. Aunque no sea un Administrador de Dominio, [USUARIO_EJEMPLO] podría tener acceso a archivos interesantes en ese servidor. El resto del ataque (createnetonly, steal_token) es idéntico, pero ahora operamos como el usuario [USUARIO_EJEMPLO].

AnteriorRBCDSiguienteUnconstrained Delegation

Última actualización