Kerberos (I): ¿Cómo funciona Kerberos? – Teoría

El objetivo con esta serie de posts es ayudar a esclarecer el funcionamiento de Kerberos, más allá de meramente presentar los ataques. Esto se debe a que muchas veces no queda claro cómo funciona kerberos y por qué funcionan o no dichas técnicas, o en qué se basan. Tener este conocimiento puede ayudar a la hora saber cuando utilizar cada una de ellas en un pentest interno.

Por tanto, tras mucho bucear en la documentación y diferentes posts sobre el tema, se ha intentado plasmar en este post todos los detalles importantes que se deben conocer para comprender como funciona y como un atacante se puede aprovechar del protocolo Kerberos.

En este primer post se tratará solamente lo que se considera el funcionamiento básico del protocolo. En los siguientes se verá como se pueden llevar a cabo los ataques y cómo funcionan algunos aspectos más complejos como la delegación.

Si tienes alguna duda sobre el tema que no veas bien resuelta en el post no dudes en dejar un comentario sobre ello. Y ahora al tema.

¿Qué es Kerberos?

En primer lugar, Kerberos es un protocolo de autenticación, pero no de autorización. Esto quiere decir que el protocolo se encarga de identificar a cada usuario, a través de una contraseña solo conocida por este, pero no determina a qué recursos o servicios puede acceder o no dicho usuario.

Kerberos es ampliamente utilizado en Active Directory. En esta plataforma Kerberos da información de los privilegios de cada usuario autenticado, pero queda a cargo de los servicios el verificar que dichos privilegios son suficientes para acceder a sus recursos.

Elementos que forman parte de Kerberos

Se verán en este apartado varios elementos que forman parte del ecosistema de Kerberos.

Capa de transporte

En este aspecto se debe resaltar que Kerberos utiliza UDP o TCP como protocolos de transporte, que transmiten la información en claro, por lo cual es necesario que se encargue él mismo de proporcionar la capa de cifrado.

El protocolo Kerberos utiliza los puertos UDP/88 y TCP/88, que se deben encontrar a la escucha en el KDC (explicado en la siguiente sección).

Agentes

En Kerberos intervienen varios servicios encargados de realizar la autenticación del usuario. Entre estos se encuentran los siguientes:

• El cliente o usuario que quiere acceder al servicio.
• El AP (Application Server) donde se expone el servicio al que el usuario quiere acceder.
• El KDC (Key Distribution Center), el servicio de Kerberos encargado de distribuir los tickets a los clientes, instalado en el DC (Controlador de dominio). Cuenta con el AS (Authentication Service), que se encarga de expedir los TGTs.

Claves de cifrado

Varias estructuras manejadas por Kerberos, como los tickets, se transmiten cifradas o firmadas. Esto evita que sean manipuladas por terceros. Las claves de cifrado utilizados por Kerberos, en Active Directory, son las siguientes:

• Clave del KDC o krbtgt: clave derivada del hash NTLM de la cuenta krbtgt.
• Clave de usuario: clave derivada del hash NTLM del propio usuario.
• Clave de servicio: clave derivada del hash NTLM del propietario del servicio, que puede ser una cuenta de usuario o del servidor.
• Clave de sesión: clave negociada por el cliente y el KDC.
• Clave de sesión de servicio: clave negociada para utilizar entre el cliente y el AP.

Tickets

Kerberos maneja unas estructuras llamadas “Tickets”, que son entregados a los usuarios autenticados para que estos puedan realizar ciertas acciones dentro del dominio de Kerberos. Se distinguen 2 tipos:

• El TGS (Ticket Granting Service) es el ticket que se presenta ante un servicio para poder acceder a sus recursos. Se cifra con la clave del servicio correspondiente.
• El TGT (Ticket Granting Ticket) es el ticket que se presenta ante el KDC para obtener los TGS. Se cifra con la clave del KDC.

PAC

El PAC (Privilege Attribute Certificate) es una estructura incluida en la mayoría los tickets. Esta estructura contiene los privilegios del usuario y está firmada con la clave del KDC.

Es posible para los servicios verificar el PAC comunicándose con el KDC, aunque esto no es común. No obstante, la verificación del PAC solo consiste en comprobar su firma, sin comprobar si los privilegios son correctos.

Por otra parte, un cliente puede evitar que se incluya el PAC especificándolo en el campo KERB-PA-PAC-REQUEST de la petición del ticket.

Mensajes

El protocolo Kerberos permite la comunicación de los diferentes agentes a través de diferentes tipos de mensajes. A continuación se enumeran los más interesantes:

• KRB_AS_REQ: Utilizado por el usuario para solicitar el TGT al KDC.
• KRB_AS_REP: Respuesta del KDC para enviar el TGT al usuario.
• KRB_TGS_REQ: Utilizado por el usuario para solicitar el TGS al KDC, utilizando el TGT.
• KRB_TGS_REP: Respuesta del KDC para enviar el TGS solicitado al usuario.
• KRB_AP_REQ: Utilizado por el usuario para identificarse contra el servicio deseado, utilizando el TGS del propio servicio.
• KRB_AP_REP: (Opcional) Utilizado por el servicio para autenticarse frente al usuario.
• KRB_ERROR: Utilizado por los diferentes agentes para notificar situaciones de error.

Además, aunque no es parte de Kerberos, sino de NRPC, el AP puede opcionalmente utilizar el mensaje KERB_VERIFY_PAC_REQUEST para enviar la firma del PAC al KDC, y verificar si ésta es correcta.

A continuación se muestra un resumen de los mensajes siguiendo la secuencia de autenticación:

Proceso de autenticación

Se estudiará en esta sección como se desarrolla el proceso de autenticación según el protocolo Kerberos, partiendo de un usuario que no posee ningún ticket, hasta que el mismo se autentica contra un servicio deseado.

KRB_AS_REQ

Por tanto, lo primero que un usuario debe conseguir es un TGT del KDC, para ello se envía un mensaje KRB_AS_REQ:

En KRB_AS_REQ se encuentran, entre otros, los siguientes campos:

• Un timestamp cifrado con la clave del cliente, para autenticar al usuario y prevenir ataques de replay
• El nombre del usuario que se está autenticando
• El SPN del servicio asociado a la cuenta krbtgt
• Un nonce generado por el usuario

Nota: el timestamp cifrado solo es necesario si el usuario requiere preautenticación, lo cual se da en la mayoría de los casos, salvo que el usuario tenga activado el flag DONT_REQ_PREAUTH.

KRB_AS_REP

Al recibir el mensaje el KDC verifica la identidad del usuario descifrando el timestamp. Si el mensaje recibido es correcto entonces responde con un KRB_AS_REP:

En KRB_AS_REP se envía la siguiente información:

• Nombre de usuario
• El TGT, que incluye:
  • Nombre de usuario
  • Clave de sesión
  • Fecha de expiración del TGT
  • PAC con los privilegios del usuario, firmado por el KDC
• Una serie de datos cifrados con la clave del usuario, que incluyen:
  • Clave de sesión
  • Fecha de expiración del TGT
  • Nonce del cliente, para evitar ataques de replay

Una vez terminado este proceso el usuario ya posee un TGT que podrá ser usado para solicitar los TGS, y acceder a los servicios del dominio ligados a Kerberos.

KRB_TGS_REQ

Para solicitar un TGS se debe enviar al KDC un mensaje KRB_TGS_REQ:

En KRB_TGS_REQ se pueden apreciar estos apartados, entre otros:

• Datos cifrados con la clave de sesión:
  • Nombre de usuario
  • Timestamp
• TGT
• SPN del servicio solicitado
• Nonce generado por el usuario

KRB_TGS_REP

Cuando el KDC recibe este mensaje devuelve un TGS en el mensaje KRB_TGS_REP:

KRB_TGS_REP incluye, entre otras, las siguientes partes:

• Nombre de usuario
• TGS, que contiene:
  • Clave de sesión de servicio
  • Nombre de usuario
  • Fecha de expiración del TGS
  • PAC con los privilegios del usuario, firmado por el KDC
• Datos cifrados con la clave de sesión:
  • Clave de sesión de servicio
  • Fecha de expiración del TGS
  • Nonce del cliente, para evitar ataques de replay

KRB_AP_REQ

Y si todo ha salido bien, el usuario ya tiene el TGS que le permite acceder al servicio deseado. Para utilizarlo debe enviar al AP un mensaje KRB_AP_REQ:

En KRB_AP_REQ se especifica:

• TGS
• Datos cifrados con la clave de sesión del servicio:
  • Nombre de usuario
  • Timestamp, para evitar ataques de replay

Tras esto, si los permisos del usuario son correctos, este ya puede acceder al servicio. Para esto, si está configurado, el AP verificará contra el KDC el PAC. Y en caso de requerir autenticación mutua, responderá con un mensaje KRB_AP_REP al usuario.

Ataques de Kerberos

Basándose en el procedimiento de autenticación anteriormente explicado se exponen cómo funcionan los ataques orientados a Kerberos en un Active Directory.

Overpass The Hash/Pass The Key (PTK)

La definición general del ataque Pass The Hash (PTH) es la de ataque que utiliza el hash del usuario para conseguir suplantar al mismo. Llevado al campo de los tickets Kerberos se denomina Overpass The Hash o Pass The Key.

Si un atacante consigue obtener el hash de un usuario podría suplantar a este frente al KDC, y acceder a los servicios del dominio disponibles para dicho usuario.

Los hashes de usuario se pueden extraer de los ficheros SAM de las estaciones de trabajo, del fichero NTDS.DIT de los DC, o de la memoria del proceso lsass (utilizando la herramienta Mimikatz) donde también es posible obtener las contraseñas en texto claro.

Pass The Ticket (PTT)

El Pass The Ticket se trata de obtener un ticket de usuario y utilizarlo para ganar acceso a los recursos para los que el usuario tenga permisos. Sin embargo, además del ticket, es necesario conseguir también la clave de sesión respectiva, para poder usar este en las comunicaciones con el servicio.

Se pueden obtener los tickets mediante un ataque de Man-In-The-Middle, ya que estos viajan sobre UDP o TCP. No obstante, mediante este técnica no se consigue acceso a la clave de sesión.

El otro método, ampliamente utilizado, es extraer dichos tickets de la memoria del proceso lsass, donde también se pueden encontrar las claves de sesión. Este procedimiento se puede realizar con la herramienta Mimikatz.

Es preferible obtener un TGT, debido a que el TGS cuenta con la limitación de que solamente se puede utilizar contra un servicio, pero ambos pueden ser utilizados para este tipo de ataque.

Se debe tener en cuenta que el tiempo por defecto de vida de los tickets es de 10 horas, tras lo cual no podrán ser utilizados.

Golden Ticket y Silver Ticket

El objetivo del ataque del Golden Ticket es construir un TGT, para lo cual se necesita la clave del krbtgt. Por tanto si se obtiene el hash NTLM de la cuenta krbtgt, es posible construir un TGT. Dicho TGT puede contar con la caducidad y permisos que se desee, consiguiendo incluso privilegios de administrador de dominio.

El ticket continuará siendo válido aunque el usuario incluido cambie su contraseña. El TGT solo podrá ser invalidado si expira o cambia la contraseña de la cuenta krbtgt.

El Silver Ticket es similar, pero esta vez se construye un TGS y lo que se requiere es la clave del servicio al que se quiere acceder. Esta clave se deriva del hash NTLM de la cuenta propietaria del servicio. Esta técnica no funcionará si el servicio verifica el PAC, ya que al no conocer la clave de krbtgt, no es posible firmarlo correctamente.

Kerberoasting

El Kerberoasting trata de usar los TGS para realizar cracking de las contraseñas de los usuarios offline.

Como se ha visto anteriormente, los TGS vienen cifrados con la clave del servicio, que se deriva del hash NTLM de la cuenta propietaria del servicio. Normalmente los servicios son propiedad de las cuentas de ordenador en que se ejecutan. No obstante, estas contraseñas son demasiado complejas como para ser crackeadas. Esto también aplica a la cuenta krbtgt, haciendo que tampoco se pueda crackear el TGT.

Pese a todo, en algunas ocasiones los propietarios de los servicios son cuentas de usuario normal. En estos casos es más factible crackear las contraseñas. Además, este tipo de cuentas suelen ser privilegiadas. Se debe tener en cuenta que con cualquier usuario de dominio es posible obtener un TGS para cualquier servicio, debido a que Kerberos no se encarga de la autorización.

ASREPRoast

El ASREPRoast es una técnica similar al Kerberoasting, que también busca el crackeo offline de las credenciales.

Cuando un usuario está configurado con el atributo DONT_REQ_PREAUTH, no necesita preautenticación, con lo que es posible construir un mensaje KRB_AS_REQ sin conocer las credenciales del mismo.

Una vez construido y enviado, el KDC responderá con un mensaje KRB_AS_REP que contiene datos cifrados con el hash de este usuario, pudiendo ser utilizados para el crackeo offline.

Conclusión

En este primer post se ha visto cómo funciona el proceso de autenticación de Kerberos y cómo funcionan sus ataques. Esperamos que este post ayude a entender algunos de los conceptos más abstractos de Kerberos. En los siguientes posts se mostrará cómo realizar estos ataques de forma práctica y cómo funciona la delegación.

Referencias

• Kerberos v5 RFC: https://tools.ietf.org/html/rfc4120
• [MS-KILE] – Kerberos extension: https://msdn.microsoft.com/en-us/library/cc233855.aspx
• [MS-APDS] – Authentication Protocol Domain Support: https://msdn.microsoft.com/en-us/library/cc223948.aspx
• Mimikatz and Active Directory Kerberos Attacks: https://adsecurity.org/?p=556
• Explain like I’m 5: Kerberos: https://www.roguelynn.com/words/explain-like-im-5-kerberos/
• Kerberos & KRBTGT: https://adsecurity.org/?p=483
• Mastering Windows Network Forensics and Investigation, 2 Edition .  Autores: S. Anson , S. Bunting, R. Johnson y S. Pearson. Editorial Sibex.
• Active Directory , 5 Edition. Autores: B. Desmond, J. Richards, R. Allen y A.G. Lowe-Norris
• Service Principal Names: https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx
• Niveles funcionales de Active Directory: https://technet.microsoft.com/en-us/library/dbf0cdec-d72f-4ba3-bc7a-46410e02abb0
• OverPass The Hash – Gentilkiwi Blog: https://blog.gentilkiwi.com/securite/mimikatz/overpass-the-hash
• Pass The Ticket – Gentilkiwi Blog: https://blog.gentilkiwi.com/securite/mimikatz/pass-the-ticket-kerberos
• Golden Ticket – Gentilkiwi Blog: https://blog.gentilkiwi.com/securite/mimikatz/golden-ticket-kerberos
• Mimikatz Golden Ticket Walkthrough: https://www.beneaththewaves.net/Projects/Mimikatz_20_-_Golden_Ticket_Walkthrough.html
• Attacking Kerberos: Kicking the Guard Dog of Hades: https://files.sans.org/summit/hackfest2014/PDFs/Kicking%20the%20Guard%20Dog%20of%20Hades%20-%20Attacking%20Microsoft%20Kerberos%20%20-%20Tim%20Medin(1).pdf
• Kerberoasting – Part 1: https://room362.com/post/2016/kerberoast-pt1/
• Kerberoasting – Part 2: https://room362.com/post/2016/kerberoast-pt2/
• Roasting AS-REPs: https://www.harmj0y.net/blog/activedirectory/roasting-as-reps/
• PAC Validation: https://passing-the-hash.blogspot.com.es/2014/09/pac-validation-20-minute-rule-and.html
• Understanding PAC Validation: https://blogs.msdn.microsoft.com/openspecification/2009/04/24/understanding-microsoft-kerberos-pac-validation/
• Reset the krbtgt acoount password/keys: https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51
• Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft: https://www.microsoft.com/en-us/download/details.aspx?id=36036
• Fun with LDAP, Kerberos (and MSRPC) in AD Environments: https://speakerdeck.com/ropnop/fun-with-ldap-kerberos-and-msrpc-in-ad-environments?slide=58

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/

En TarlogicTeo y en TarlogicMadrid.