Una parte importante de los mecanismos y protocolos de autenticación utilizados por Active Directory es Kerberos, que de manera resumida, establece un canal de autenticacion seguro entre hosts confiables en una red no confiable.
Se puede listar algunos de los objetivos que tiene un proceso de autenticación con Kerberos.
- Las passwords no se transmiten a traves de la red.
- Las passwords no se almacenan en los sistemas operativos de clientes y se deben descartar de manera inmediata despues de su uso.
- Las passwords no se almacenan en texto claro, aun en los servidores de autenticación.
- Una password se ingresa una sola ves por sesion, similar a un proceso de SSO (Single Sign-on), ya que se requiere la autenticación de un usuario una sola ves, permitiendole el acceso a los recursos autorizados para este.
- Toda la información de autenticación se centraliza en un servidor de autenticación. Los servidores de aplicaciónes no almacenan nada de información de autenticacion, permitiendo implementar las siguientes caracteristicas:
- Un administrador puede deshabilitar la autorizacion para un usuario sobre cualquier servidor de aplicaciones desde el servidor centralizado de autenticacion. El acceso a servidores individuales no es necesario para revocar la autorización.
- Una passwords de un usuario es suficiente para acceder a todos los servicios autenticados por Kerberos. Un usuario puede resetear su pass una sola ves, sin importar la cantidad de servicios en los que esta autenticado.
- Se simplifica la protección de la información de usuarios ya que toda la información de autenticacion se encuentra en un servidor centralizado en lugar de multiples servidores donde el usuario tiene acceso.
- Todas las partes, usuarios y servidores de aplicaciones, deben autenticarse entre ellos cuando se requiera. Los usuarios se autentican al iniciar una sesión, servicios de las aplicaciones pueden ser configurados para solicitar autenticación hacia el cliente.
- Kerberos provee un mecanismo para clientes y servidores que permite estableecer un circuito cifrado con el fin de que las comunicaciones en red sean privadas.
Con estos objetivos listados, se pueden identificar ciertos puntos interesantes, desde el punto de vista de un atacante:
- Comprometer una cuenta de dominio que tenga acceso a servicios autenticados por Kerberos nos da practicamente control sobre los servicios respectivos y posiblemente sus servidores.
- Un usuario puede tener acceso a múltiples servicios.
- Es posible que las cuentas utilizadas sean cuentas de servicios, por lo que existe la posibilidad de que las passwords utilizadas no hayan sido cambiadas en mucho tiempo o sean de baja complejidad.
- Son un protocolo distinto, por lo que es posible que procesos de monitoreo sobre intentos de autenticación en el active directory no esten monitoreando autenticaciones por Kerberos.
A continuación, se presentan algunas de las “vulnerabilidades” más conocidas sobre Kerberos, denominado Kerberoasting.
Más información sobre Kerberoasting en el siguiente enlace:
Tickets SPN
¿Que es SPN?
Service Principal Name (SPN), es un identificador unico de una instancia de un servicio especifico. Son utilizados por la autenticacion por Kerberos para asociar una instancia de servicio con una cuenta de domino de servicio.
Utilizando el Active Directory de pruebas que montamos en un anterior post, generaremos tickets SPN para 2 usuarios distintos y luego desde un equipo Kali consultaremos por los mismos y realizaremos el proceso de crackeo.
Accedemos al controlador de dominio como administrador de dominio y ejecutamos Powershell con privilegios administrativos.
El comando que utilizaremos es “SetSPN”, cmdlet propio de Powershell.
Tenemos multiples opciones, todas documentadas, pero para nuestro ejercicio, utilizaremos la opción “-A”, que nos permitira crear un ticket para un usuario en el dominio interno.
Comando: SetSPN -A MSSQLSvc/BD01.jsec.local:1433 JSEC\Administrator
De esta manera, creamos un SPN para el usuario “Administrator”, ahora crearemos otro para un nuevo usuario llamado “Service_BD”.
En la captura se obtuvo un error al ejecutar el comando “Duplicate SPN Found, aborting operation!”, esto se debe a que se intento crear un nuevo SPN para una instancia de servicio que ya tiene un SPN asignado, ya que los tickets SPN asocian una instancia de servicio a una cuenta de dominio de servicio, no se puede definir un nuevo ticket, seria como si le dijeramos al dominio que se esta iniciando una sola sesión en el servicio con dos usuarios distintos.
Con los tickets ya creados, utilizaremos “Impacket” para obtener los tickets respectivos y sus valores cifrados, que pueden ser crackeados para obtener contraseñas validas.
Cabe destacar que es necesario contar con una cuenta de dominio válida para poder comunicarse con el controlador de dominio y consultar los tickets respectivos.
Comando: impacket-GetUserSPNs DOMINIO/USUARIO:PASSWORD -dc-ip IP-Controlador-de-dominio
Utilizando una cuenta de bajos privilegios, se obtiene la lista de tickets registrados, para el usuario “Administrator” y “Service_BD”, sin embargo, no observamos ningun valor cifrado que podamos guardar en un archivo de texto y luego intentar crackear, para solicitar el valor del ticket respectivo agregamos el parametro “-request” al comando utilizado.
Nota: Si al ejecutar el comando obtienen un error similar a “clock_skew_too_great”, deben sincronizar la hora de su kali con la hora del controlador de dominio.
El comando que me soluciona el problema sin falla es “sudo rdate -n IP-DC”
De esta manera, ya tenemos los tickets TGS respectivos, por lo que podemos proceder al crackeo de los mismos.
La herramienta que utilizo mayormente es Hashcat, ya que permite utilizar la GPU de un equipo para crackear hashes de manera más rapida.
Utilizando un diccionario de palabras, realizamos el crackeo respectivo (Para agilizar las pruebas, se agrego la contraseña del usuario respectivo al fichero rockyou.txt).
Comando: hashcat -m TIPO-DE-HASH(*) FICHERO_HASHES DICCIONARIO
(*) Para obtener una lista de los tipos de hash aceptados por hashcat, se puede utilizar la flag “-h”.
Cabe destacar que los hashes deben estar en un formato especifico, en el siguiente enlace se encuentra una lista con hashes de ejemplo para cada valor de “-m” (documentación oficial de la herramienta).
https://hashcat.net/wiki/doku.php?id=example_hashes
Esperamos un par de segundos hasta que la herramienta termine el crackeo, obteniendo la contraseña del usuario “Service_BD” en texto claro.
El nombre indica que esta cuenta de dominio estaba asociada a una base de datos, por lo que podemos validar si la misma tiene acceso administrativo sobre el servidor “BD01”, identificado en posts anteriores.
De esta manera observamos que si tenemos acceso administrativo sobre el servidor, permitiendo realizar movimiento lateral y extracción de información del mismo.
Nota: Cabe destacar que la posibilidad de consultar los tickets SPN utilizando una cuenta de dominio de bajos privilegios no se considera una vulnerabilidad, ya que es el funcionamiento regular de un Active Directory, las vulnerabilidades principales en estos casos son:
- Uso de credenciales débiles, ya que se pudo crackear el TGS.
- El usuario de servicio cuenta con privilegios excesivos sobre el servidor de base de datos.
- Se utilizan usuarios administradores de dominio o con privilegios excesivos para generar los tickets y/o levantar servicios en el dominio, se deberian utilizar usuarios creados especificamente para los servicios internos, no se recomienda utilizar un administrador de dominio.
Pre-autenticacion Kerberos deshabilitada.
Existe la posibilidad de configurar el servicio de Kerberos para que, para una cuenta especifica, no se requiera realizar la pre-autenticacion antes de generar el TGS para el usuario respectivo, si se da este caso, un atacante podria solicitar el ticket de un usuario sin necesidad de conocer su contraseña, para luego intentar crackear el mismo y obtener control sobre la cuenta respectiva.
Para armar este escenario en nuestro Active Directory de pruebas, seguimos los siguientes pasos.
Accedemos al controlador de dominio, a la ventana de gestion de usuarios y computadoras del dominio.
Seleccionamos la cuenta utilizada para el ejemplo anterior “Service_BD”, click derecho y entramos a “Properties”.
Hacemos click en la pestaña “Account” y en la seccion “Account options” vamos al final de la lista y tickeamos la opción “Do not require Kerberos preauthentication”.
De esta manera podemos continuar con el ejercicio utilizando la cuenta “Service_BD”.
En un pentest, podemos obtener una lista de todos los usuarios del dominio utilizando una cuenta valida de dominio, se muestra el output de la herramienta “ldapdomaindump” como ejemplo.
Este dump fue realizado al momento de levantar el Active Directory, por lo que las cuentas creadas aun no son reflejadas acá, sin embargo, se puede observar en la columna “Flags” que los usuarios “jseclow” y “jsec” tienen la flag “DONT_REQ_PREAUTH”, la herramienta consulta al dominio por todos sus usuarios y sus flags respectivas, por lo que se puede obtener una lista de todos los usuarios que no tengan habilitada la pre-autenticacion por kerberos.
Conociendo algunas cuentas con la flag establecida, incluida la que acabamos de configurar, procedemos a la explotación utilizando “Impacket”.
Comando: impacket-GetNPUsers DOMINIO/Usuario
De esta manera, intentamos autenticarnos al controlador de dominio con la cuenta del usuario al que atacaremos, como no conocemos la contraseña, podemos apretar “Enter”, que ahi es donde entra en juego la flag “DONT_REQ_PREAUTH”, ya que la misma le indica al controlador de dominio que, para generar un TGS de este usuario, no necesita autenticarse de manera exitosa, basta con solicitar el ticket de manera directa.
Observamos que para las cuentas “jsec” y “jseclow” la password expiro, por lo que no se puede obtener su ticket, pero para la cuenta “Service_BD” si fue posible obtenerlo, por lo que realizaremos el crackeo del ticket respectivo.
Para identificar el valor de “-m” que necesitamos para crackear este ticket, utilizamos la ayuda de hashcat y grep.
Observamos que el ticket obtenido comienza con “$krb5asrep$”, por lo que el valor de “-m” que buscamos es el 18200, perteneciente a Kerberos 5 AS-REP, para el caso anterior de tickets SPN, el ticket comienza con “$krb5tgs$23$”, por lo que se utilizó el valor 13100.
Ejecutamos hashcat para crackear el ticket AS-REP.
Despues de un par de segundos, se obtiene la contraseña respectiva.
A partir de este punto, se puede replicar el paso detallado anteriormente para acceder al servidor de base de datos.
Estos son algunos ataques comunes sobre el protocolo de Kerberos que llegue a explotar de manera exitosa en múltiples evaluaciones, muchas veces un diccionario no es suficiente, por lo que se incorpora un juego de reglas para el crackeo respectivo, que sera mencionado en otro post.
La parte 2 de este post estara orientada a movimiento lateral y post-explotación, como por ejemplo ataques Pass-the-ticket y creación de Golden tickets para persistencia.